Software Configuration Management

1
Administración de Configuraciones - Introducción
La facilidad de cambio en el software pone en riesgo la integridad de los productos. Cambios
sin control, despliegue de componentes inconsistentes entre sí, o la falta de disponibilidad del
componente adecuado en una determinada etapa del ciclo de vida, pueden desestabilizar la
calidad de mi aplicación.
Es de la sensibilidad al cambio presente en la disciplina de ingeniería de software que se
desprenden las radicales diferencias que tiene esta actividad de la ingeniería con otras
actividades de la industria. El dinamismo intrínseco del software genera la necesidad de
contar con un framework para el control de cambios y estados de la configuración, es desde
esta necesidad que surge CM (Configuration Management).
Paradójicamente, la naturaleza sensitiva al cambio presente en el software hace que la
“
b
u
r
o
c
r
a
c
i
a
”
e
nl
o
s
c
o
n
t
r
o
l
e
s
d
ec
a
m
b
i
o
s
e
aa
l
g
op
o
s
i
t
i
v
od
e
n
t
r
o
d
ee
s
t
ec
o
n
t
e
x
t
o
.
CM colabora con el proceso a través de la implementación de políticas de tracking,
seguridad, integración y administración de cambios.
2
Entropía vs Actividad de Cambio
La entropía aumenta en el software en forma continua a menos que acciones de control
sean aplicadas sobre los cambios.
Los casos patológicos de ejemplo son los legacy systems donde existen, en algunos casos,
décadas de cambios sin documentar por lo que debe interpretarse las reglas del negocio a
través de ingeniería inversa sobre el código.
3
Misión de CM (Configuration Management)
La misión de la Administración de Configuraciones es custodiar la integridad de los productos
a medida que evolucionan desde la especificación, pasando a través del diseño, el
desarrollo, el despliegue a producción y el posterior mantenimiento. Su existencia tiene
sentido como actividad de soporte que acompaña a los productos en la actividad de cambio
a lo largo del ciclo de vida.
El valor invertido en CM está relacionado con el costo del producto vs la exposición al riesgo
de obtener un producto inestable. Entonces, ¿cuál es el equilibrio entre el gasto en CM y
exposición a dicho riesgo?, ¿cómo mido dicho riesgo?
4
Software Configuration Management - Introducción
Según el SEI, nos centramos en actividades específicas de SCM que, de ser
cumplimentadas, pueden al menos garantizar ciertos niveles de calidad en la configuración.
Nuestro enfoque partirá de observar a SCM también como un proceso, o sea que nos
centraremos en sus actividades como propone el SEI.
5
Cambio - Incrementando la complejidad del Software
Con este tipo de cambio nos referimos a modificaciones que sufre directamente el producto
de software en sí sin incluir consideraciones del entorno.
- Size
Líneas de código
Nuevos Módulos (Cambio de arquitectura)
- Inclusión de componentes de terceras partes
Controlar versiones de componentes por terceras partes.
Grabar versiones que conforman el baseline del sistema de software
- Incrementando el número de plataformas sobre las cuales el sistema opera
La organización de test se ve afectada.
SCM tool debería ejecutarse en todas las plataformas que el producto “
c
o
r
r
e
”
6
Cambio - Incrementando la complejidad del Entorno
- Team Size
Incrementar el tamaño del team significa aumentar la cantidad de líneas de comunicación.
Por Ejemplo:
2 personas = 1 línea
3 personas = 3 líneas
n personas = n* (n-1)/2
Acceso concurrente a los componentes aumenta.
Complejidad en el merge de los cambios en paralelo.
- Distribución geográfica del team
Comunicación más compleja.
Merge integration se hace imposible sobre los niveles superiores de integración.
- Frecuencia de los Releases o cantidad de variantes
Aumenta la cantidad de releases mantenidos al mismo tiempo.
Los bug fixes son mas difíciles de distribuir.
Los arreglos sobre versiones existentes colisionan con mayor número de versiones funcionando.
- Cambio en plataformas de SO y Hardware
Muchas veces no atendido, las partes de la configuración que no son software (como firmware y hardware) no son
tenidas en cuenta como parte de la configuración con la consecuente desatención durante el mantenimiento.
El SO, el hardware sobre el cual este funciona, como así también la versión de Firmware instalada en el Hardware son
elementos de terceros que deben sr mantenidos bajo control de configuración.
7
Cambio - Cambiando el ciclo de vida
El ciclo de vida determina dos aspectos que influyen sobre el plan de SCM: cantidad de
versiones que deberé administrar y etapas durante las cuales aceptaré sean efectuados
cambios sobre el producto en sí.
La rigidez de los controles será directamente proporcional al avance del proyecto en la fase.
A medida que me acerco al final de la fase, debo estar acercándome a tener algún
entregable listo (versión). Esto hace que las restricciones para modificar el software sean
incrementadas para asegurar que no existan desvíos, solo los cambios de urgencia o muy
bien justificados tendrán lugar en esta etapa.
De la misma manera, en ciclos de vida con un alto grado de prototipación, se hará énfasis en
la auditoría en lugar de restringir que el team pueda modificar el producto.
8
Definiciones:
Artifact: Cualquier elemento de un producto de software que esté sujeto a cambios.
Esto incluye código fuente, documentación, planes de prueba, datos de prueba, librerías, código objeto, etc.
T
a
mb
i
é
n
e
s
c
o
n
o
c
i
d
oe
n
l
a
t
e
r
mi
n
o
l
o
g
í
at
r
a
d
u
c
i
d
aq
u
e
e
n
c
o
n
t
r
a
m
o
s
c
o
mo“
í
t
e
md
e
c
o
n
f
i
g
u
r
a
c
i
ó
n
”
.
Baseline:
Todo artifact s
e
e
n
c
u
e
n
t
r
a
s
u
j
e
t
oa
u
n
ap
o
l
í
t
i
c
a
d
e“
v
e
r
s
i
o
n
a
d
o
”
.
Un producto de software está compuesto por un conjunto de artifacts cada uno de los cuales pertenezca a una versión
específica.
La idea de baseline entonces es establecer qué versión de cada artifact corresponde a cada versión producto de
software.
El baseline no contendrá ningún producto sino que será simplemente un conjunto de pares <artifact, version number>
que servirá para determinar que ítems de configuración debe seleccionar la herramienta SCM para poder reproducir
una versión determinada de mi producto.
Variante: Una instancia del sistema que es funcionalmente idéntica pero que a nivel no funcional distinta de las otras
instancias del sistema.
Un ejemplo de esto es tener una variante distinta para cada plataforma de software y hardware. Cambios en el look and
view del producto son otros motivos para generar nuevas variantes.
Versión: Una instancia del sistema funcionalmente distinta de las otras instancias del mismo sistema.
Release: Una instancia del sistema que es distribuida a los usuarios fuera del equipo de desarrollo.
9
Entorno CM
Products
Los productos sujetos a control de configuracion son todos aquellos que, al ser afectados por
un cambio, pudieran afectar la integridad de la aplicacion.
Implementation Processes
La necesidad de operar sobre diversos ambientes nos obliga a conservar, al menos,
entornos de produccion y desarrollo por separado. La actividad de cambio en ambos
entornos tendra diferente volatilidad y por ende, debera poder ser aislada.
CM Processes
La integridad de los productos a lo largo de los entornos es gestionada a partir de las
practicas de CM que se describen a lo largo de este presentacion.
10
Actividades Esenciales
Nos centramos en actividades específicas, estas actividades son dependientes de la configuración SCM, la
cual es a su vez dependiente del tipo de industria sobre la cual se está aplicando.
Si bien estas actividades son varias, hemos extraído 10 de ellas que consideramos esenciales desde el
punto en que todas ellas son imprescindibles sin importar el tipo de desarrollo en el cual nos encontremos
involucrados.
 Identificar y almacenar artifacts en un repositorio seguro
El primer paso para realizar SCM es identificar los artifacts que deberán ser mantenidos bajo control de
versiones.
Tanto los utilizados para administrar y diseñar el sistema (plan de proyecto, documento de diseño, etc.)
como aquellos requeridos para construir la aplicación (código fuente, código objeto, librerías, archivos de
ayuda, etc.) deben ser mantenidos bajo control de las actividades de SCM.
Cualquier persona que haya trabajado en construcción de software conoce la dificultad que existe en
encontrar la versión “
c
o
r
r
e
c
t
a
”
del archivo “
c
o
r
r
e
c
t
o
”
cuando las versiones no son almacenadas en forma
ordenada. De aquí la utilidad del concepto de baseline visto anteriormente.
Sin embargo, la localización y almacenamiento no son suficientes.
Dado que el repositorio es potencialmente un centro de falla, debemos pedir que además sea robusto y
tolerante a fallas. Escalabilidad, replicación, y distribución son atributos adicionales para la administración
de proyectos de cierta envergadura.
Desde este último punto de vista, la herramienta SCM operará como una base de datos que, dependiendo
del scope de acceso (puntos geográficos diferentes), tamaño de la organización, etc., escalará tal cual lo
hace un DBMS.
11
Actividades Esenciales
 Controlar y auditar cambios sobre los artifacts.
Una vez que los artifacts son identificados y almacenados en el repositorio, debe ser posible
definir quién puede modificarlos como así también quién ha modificado un artifact.
Cuando ha ocurrido esto, por qué ha sido modificado y qué ha sido modificado. A este tipo de
información la denominamos información de auditoría.
La IEEE la denomina configuration control y configuration status accounting respectivamente
de la siguiente forma:
“
l
ae
v
a
l
u
a
c
i
ó
n
,
c
o
o
r
d
i
n
a
c
i
ó
n
,
a
p
r
o
b
a
c
i
ó
nod
e
s
a
p
r
o
b
a
c
i
ó
n
,
ei
mp
l
e
me
n
t
a
c
i
ó
nd
e
c
a
mb
i
o
s
s
o
b
r
eí
t
e
ms
d
e
c
o
n
f
i
g
u
r
a
c
i
ó
n
”
y
,
“
e
l
r
e
g
i
s
t
r
oy
e
mi
s
i
ó
nd
er
e
p
o
r
t
e
s
d
e
l
ai
n
f
o
r
ma
c
i
ó
nr
e
q
u
e
r
i
d
ap
a
r
aa
d
mi
n
i
s
t
r
a
r
l
a
c
o
n
f
i
g
u
r
a
c
i
ó
ne
f
i
c
i
e
n
t
e
m
e
n
t
e
”
.
12
Actividades Esenciales
 Controlar y auditar cambios sobre los artifacts.
Idealmente, dado que estas restricciones deben tener un impacto mínimo sobre la
productividad, los controles deben ser dinámicos y acompañar la fase en la que encuentre la
versión sobre la cual me encuentro operando.
Sobre el inicio de una nueva fase, debemos poder modificar un determinado artifact sin
contar con demasiados controles. A medida que me voy acercando a la etapa de entrega,
d
e
b
op
o
d
e
r
r
e
s
t
r
i
n
g
i
r
l
o
s
c
a
m
b
i
o
s
c
a
d
a
v
e
z
m
a
s
h
a
s
t
a
a
l
c
a
n
z
a
r
l
ae
t
a
p
ad
e
“
c
o
n
g
e
l
a
m
i
e
n
t
o
”
durante la cual ya no posible realizar cambios hasta se haga la liberación del release.
Notar que a menor rigidez en el control de cambios mayor actividad de auditoría.
13
Actividades Esenciales
Organizar artifacts en forma de componentes versionados.
Una vez que tengo mas que unos cientos de archivos y directorios en el sistema, comienza a
ser necesario agrupar estos archivos con una menor granularidad para hacer posible su
administración.
Nos referimos a SCM components como al conjunto de archivos y directorios relacionados
q
u
es
o
n“
v
e
r
s
i
o
n
a
d
o
s
”
,
c
o
m
p
a
r
t
i
d
o
s
,
v
i
n
c
u
l
a
d
o
s
e
i
d
e
n
t
i
f
i
c
a
d
o
s
c
o
m
ou
n
a
u
n
i
d
a
d
.
Dado que la estructura de la configuración es intrínseca a la aplicación y no a su
administración de configuración, es que requerimos un nivel diferente de agrupamiento para
administrar la seguridad, auditoría y versionado. De esta necesidad administrativa es que
surge el concepto de component cuya utilidad es de administración de versiones, seguridad y
auditoría.
14
Actividades Esenciales
Organizar artifacts en forma de componentes versionados.
Ventajas
•
Mapeando componentes lógicos de diseño a SCM components físicos contribuye a
preservar la integridad de la arquitectura del sistema
Los componentes no pueden tener una cohesión coincidental, los mismos deben ser
agrupados de acuerdo a los criterios utilizados durante el diseño.
•
SCM Components reducen la complejidad
Agrega un nivel adicional de abstracción por encima de los archivos y directorios físicos.
•
Es más fácil identificar el nivel de calidad de una determinada versión de un
componente que de un conjunto numeroso de archivos individuales
Dado que un componente contiene un conjunto consistente de versiones de archivos y
directorios, puede ser probado como una unidad.
•
El hecho de administrar los archivos en forma atómica a través del uso de
componentes contribuye a institucionalizar el reuso y compartición de los
componentes
Facilita el acceso a la versión correcta del archivo correcto al reducir el espacio de búsqueda.
15
Actividades Esenciales
Crear baselines para cada milestone del proyecto.
Todos los componentes y artifacts que conforman un sistema de software, deben ser
agrupados seleccionando la versión correcta para cada uno de ellos bajo una línea de base
(baseline). Cada etapa del schedule del proyecto donde se presenta un milestone, debemos
tener un entregable auditable y reproducible.
Al menos debe ser creado un baseline al final de cada iteración del proyecto. Típicamente,
nuevos baselines son creados con mas frecuencia a medida que nos acercamos al final de
una iteración o también, a la etapa de entrega.
Esto nos habilita a reproducir cualquier versión de mi sistema de software, consultar qué
cambios han sido realizados, e indicar la estabilidad de la versión utilizando los atributos
almacenados en la línea de base .
Nota: La mayor cantidad de baselines no se debe a una mayor actividad de cambio sino a
que se hace necesario poder volver a un release mas reciente.
16
Actividades Esenciales
Crear baselines para cada milestone del proyecto.
Motivación
Existen tres razones principales para realizar un baseline:
1. Reproducibility
Es la habilidad de poder ir hacia atrás y re-generar cualquier release o entorno del sistema que haya sido
liberado antes.
Esto es indispensable para identificar problemas nuevos generados por nuevos releases.
2. Traceability
Es la posibilidad de unir requerimientos, planes de proyecto, casos de prueba, y artifacts todos juntos de
modo de no solo poseer el release concerniente al sistema de software sino también, la información
técnica requerida para comprender dicho sistema.
3. Reporting
Es la habilidad de poder consultar el contenido de cualquier baseline y poder además comparar un
baseline con otro. La comparación de baselines nos asiste durante la etapa de debugging y la generación
de notas de release. La comparación de baselines es utilizada en la actividad de “
P
e
e
r
r
e
v
i
e
w
s
”
Estas tres propiedades nos ayudan a corregir errores en productos liberados y facilita auditorías..
17
18
19
Actividades Esenciales
Registrar y hacer seguimiento a change requests.
Change Request Management involucra seguimiento de los requerimientos de cambio sobre
un sistema de software.
Estos pueden provenir de requerimientos de mejora (enhancements) o corrección de errores
(defects).
Nota: Este punto es tratado más adelante en mayor profundidad.
20
Actividades Esenciales
Registrar y hacer seguimiento a change requests.
La relación entre SCM y SRM (Software Requirement Management) es muy cercana, de
hecho actividades de gestión de requerimientos eficientes tienden a mejorar la gestión de
cambios en el software.
Cada requerimiento del cliente que ingresa desde el proceso de SRM, es traducido a una
serie de requerimientos de cambio que se registra en un backlog (aquí change request
backlog). La idea es que la gestión de ese backlog, sin perder trazabilidad sobre el pedido
del cliente, está orientada a la estrategia de asignación de actividades a los equipos de
desarrollo, y de las posibilidades de desarrollar diferentes cambios en forma concurrente.
Muchas veces diferentes pedidos de cambios del cliente (ingresantes desde SRM), se
traducen en cambios sobre los mismos componentes. Otras veces, la naturaleza de la
configuración impide que podamos efectuar un cambio antes que otro o en forma
concurrente. Estos casos dirigen de alguna manera la estrategia de cómo gestionaré el
backlog, y por ende el orden en que serán resueltos los pedidos del cliente.
La gestión de este backlog es fundamental desde el punto de vista de SCM ya que una
actividad ordenada desde este lugar reduce las necesidades de merge integracion,
disminuye los costos de pruebas integrales, y maximiza la cantidad de temas que pueden ser
resueltos en cada actividad.
21
Actividades Esenciales
Organizar e integrar conjuntos consistentes de versiones usando actividades.
Mientras que SCM provee control de versiones a nivel de archivo, es dejado en manos del desarrollador el
seguimiento sostenido de qué versión de qué archivo deben ir juntos con el objetivo de implementar un cambio
lógico y consistente, y para asegurar que este cambio es integrado como una unidad.
Muchas herramientas SCM colaboran con el desarrollador asistiéndolo en que requerimiento se está trabajando
actualmente o qué error es el que está intentando corregir.
El grupo de componentes y artifacts modificados conforman un change set que es tratado como una unidad en
el momento de su implementación (conocido como pack en algunos entornos).
El poder de unir las disciplinas de change request management, configuration management y project
management en un change set, es desde donde se hace visible el poder de esta propuesta .
Una actividad une un conjunto de change requests a un conjunto de recursos del equipo permitiendo de esta
manera vincular el stakeholder (requestor) a la tarea solicitada y a los recursos que la están desarrollando. Esto
nos permite vincular la información requerida para facilitar la tarea de management, code review, cost analysis,
etc.
Resources + CR => Activities
CR
SCM
Defect CR + Description => QA Control and Defect Prevention
Activities + Release => Change Set
22
Actividades Esenciales
Organizar e integrar conjuntos consistentes de versiones usando actividades.
Ventajas
1. Cambios consistentes producen menos problemas de integración y generación.
2. El trabajo basado en actividades es la forma natural en que las personas trabajan.
Generalmente los desarrolladores piensan en qué función, requerimiento de mejora o corrección de error
están trabajando, todos estos no son mas que tipos de actividades. Trabajando centrados en las
actividades, los desarrolladores se mantienen fuera de la complejidad de la implementación
3. La vinculación con un change request es inmediata.
Dado que cada CR es vinculado con cada Change Set en forma única, existe una relación directa en
cuanto a que CR se implementa bajo un Change Set determinado.
4. La vinculación con el área de project management es también directa.
El estado del cambio, quién lo está realizando y una estimación del costo son propiedades de la actividad
misma siendo esta información esencial para el área de project management.
5. El uso de actividades facilita la revisión de código.
Dado que contamos con la versión anterior de cada ítem de configuración, el conocer las diferencias entre
la versión nueva y la inmediata anterior permite aprovechar mejor el esfuerzo durante la etapa de revisión
de código.
23
Actividades Esenciales
Mantener espacios de trabajo consistentes y estables..
Tanto el entorno como los valores de configuración deben formar parte del conjunto de ítems
de configuración.
Esto nos lleva a la conclusión que la herramienta de SCM debe compartir la plataforma sobre
la cual el producto opera. Este se convierte en un aspecto fundamental en la administración
de configuraciones:
No es posible hacer SCM si la herramienta no se encuentra totalmente integrada con el
producto. No debe existir el salto del development del producto hacia su ejecución si no
queremos perder visibilidad.
Un aspecto importante es el nivel de aislamiento requerido para el éxito de esta actividad,
debe ser posible construir y almacenar componentes stub que simulen el entorno de
ejecución para poder testear y enfocarme sobre mis componentes de interés.
24
Actividades Esenciales
Soportar cambios concurrentes sobre los artifacts
Idealmente quisiéramos tener una única persona modificando un ítem de configuración a la
vez.
Dado que esto es ineficiente y no práctico, la complejidad introducida por el desarrollo
concurrente debe ser resuella también por la herramienta SCM.
Los cambios realizados en paralelo deben poder ser integrados con la asistencia de la
herramienta de SCM.
La serialización de cambios propuesta por algunas herramientas SCM presenta algunos
inconvenientes...
25
Actividades Esenciales
Soportar cambios concurrentes sobre los artifacts
Problemas
Algunos cambios, como la resolución de errores, no son serializables.
Para esto la herramienta debe brindar la posibilidad de realizar un merge de los cambios en forma
automática, en caso de que sea posible interpretar la estructura de un ítem de configuración, o en forma
manual facilitando el acceso a los elementos modificados.
26
Actividades Esenciales
Soportar cambios concurrentes sobre los artifacts
Solución
La solución es crear una nueva versión en base al merge de los cambios aplicados sobre las versiones 2 y
3.
27
Actividades Esenciales
Integrar en forma temprana y frecuente.
Durante la integración se descubren problemas en las interfaces y malentendidos en el
diseño. Cuanto antes de realice la integración, antes será posible descubrir estos errores,
siendo obviamente reducido el impacto del problema.
Si se hizo un buen trabajo en la actividad 7 (Mantener espacios de trabajo consistentes y
estables), a lo mejor el nivel de aislamiento hace que la necesidad de integrar se vea
reducida y como consecuencia se vea un impacto en esta actividad.
Tip
La integración no debe ser realizada por la necesidad particular de una parte del team sino
que debe ser una actividad rutinaria destinada a mas un proceso de verificación que de
prueba de un módulo en particular.
28
Actividades Esenciales
Asegurar sea posible reproducir releases de software.
Vimos anteriormente que los baselines me permitían conocer el estado de mi producto de
software y el entorno de ejecución en una instancia determinada.
Los releases están vinculados a un baseline determinado por lo cual, de poder obtener todas
las versiones de artifacts de mi herramienta SCM, podré reproducir mi release.
La mención a esta actividad está relacionada con la política de releasing seleccionada de
modo que, la información histórica mantenida en la herramienta SCM, sea consistente con la
antigüedad de versiones en el mercado para las cuales aún estoy brindando mantenimiento.
29
Actividades Esenciales
Resumen de Actividades Esenciales.
30
Integración
Integración es el proceso a través del cual, los cambios desarrollados en forma
independiente son juntados para formar una pieza de software que pueda ser ejecutada y
probada.
El trabajo del integrador es tomar el trabajo del equipo de desarrollo construyendo una
versión única del sistema o, dependiendo del nivel de integración, un conjunto de
componentes de software.
Los niveles de integración se determinarán por la estructura del equipo de trabajo. A medida
que crece la estructura del equipo de trabajo, los niveles de integración requeridos crecen en
igual medida.
31
Integración
Tipos de Integración
Merge Integration es concerniente a la resolución de cambios en paralelo que son
realizados por diferentes miembros del equipo sobre artifacts en común.
En algunos casos el merge puede ser realizado automáticamente a través de herramientas
que comprenden la estructura interna de los componentes. En otros casos, el merge deberá
ser realizado en forma manual. Bajo la opción de merge manual, es posible sea necesario
agregar nuevos cambios al componente resultante de modo que el merge conserve la union
de las propiedades de las versiones combinadas.
Assembly Integration involucra los procesos tendientes a crear una pieza de software a
partir de varias componentes que comparten la misma baseline. Esta actividad nunca abarca
modificaciones sobre los componentes.
Assembly Integration puede ser realizado en tiempo de construcción o de ejecución, esto
quiere decir que los componentes pueden ser ensamblados creando una única pieza de
software ejecutable o conformar un conjunto de componentes ejecutables que compartan un
entorno de ejecución.
32
Integración
Tipos de Integración
Consistent Merge
Turn-Taking: Los componentes son accedidos en forma exclusiva por una persona o equipo
de trabajo. Esto solo es practicable en equipos de desarrollo pequeños.
Split-Combine: El producto es dividido en componentes independientes que son asignados
a grupos separados. La concurrencia en el desarrollo es alta pero se acceden diferentes
piezas a luego ser ensambladas eliminando de esta forma la complejidad existente en
cambios inconsistentes sobre la misma pieza de software.
A posibilidad de aplicar este tipo de integración aumenta a medida que la granularidad del
dieño es mayor.
Copy-Merge:
E
l
m
i
s
m
oc
o
m
p
o
n
e
n
t
ee
s
“
c
o
p
i
a
d
o
”
e
n
e
s
p
a
c
i
o
s
a
i
s
l
a
d
o
s
y
m
o
d
i
f
i
c
a
d
oe
n
forma paralela por diferentes desarrolladores en espacios de trabajo aislados.
La copia original del componente debe ser utilizada finalmente por el integrador en la etapa
de merging para conocer cuales son los cambios realizados por cada uno de los
desarrolladores.
Las herramientas que colaboran en este tipo de merge utilizan la estructura del código fuente
para poder aumentar el nivel lógico de aislación de los cambios.
33
Integración
Categorías de Equipos de Desarrollo vs Integración
Major Team Integration
Existen dos niveles de integración en este caso. El primero es realizado por cada equipo de trabajo y es similar
al realizado en el caso anterior. El siguiente nivel, junta los resultados de la integración efectuada por cada uno
de los equipos del proyecto.
La estructura del Team (orientada a arquitectura o a funcionalidad), determina el tipo de integración requerida en
el segundo nivel. Si la orientación de la estructura es hacia arquitectura, el segundo nivel será un assembly
integration. En otro caso, la integración será típicamente merge integration.
Generalmente al primer nivel de integración se le llama subsystem o feature integration, mientras que al
segundo nivel se le llama system integration.
Extreme Team Integration
Este tamaño de equipo de trabajo normalmente requiere mas de dos niveles de integración.
Es importante evitar la construcción de aplicaciones monolíticas y construir equipos de trabajo cuya estructura
permita el uso de assembly integration en los niveles superiores.
En este tipo de teams, el tamaño y la complejidad de los sistemas desarrollados hace que la ventaja de la
programación en paralelo se diluya en la complejidad del merge integration posterior. Incluso en el caso de
poseer feature oriented teams, las funciones del sistema deberán ser divididas de modo que los subsistemas
puedan ser modificados en forma aislada.
El modo en el cual los sistemas son integrados y el número de niveles requeridos es determinado mayormente
por la arquitectura del sistema.
34
•
V
e
r
a
p
u
n
t
e“
S
C
MP
a
t
t
e
r
n
s
”
d
ef
o
t
o
c
o
p
i
a
d
o
r
a
.
Existencia de la línea principal (Mainline)
Políticas sobre la línea de cambio activa (Active codeline).
- Politicas de sincronizacion
- Politicas de calidad.
-Commit a nivel de tarea (Task-level commit)
Políticas sobre cambios sobre cada línea (Codeline policy).
Línea de cambio de release (Release line)
Preparación del release (Release-Prep Codeline)
Rama a nivel de tarea (Task branch)
35
36
37