|
Integrar los elementos implementados
| En el área de trabajo (workspace) adecuado, será necesario combinar todos los cambios y nuevos
desarrollos completados que no estén en la última versión de la línea de base. Será necesario resolver
cualquier conflicto de versión entre los artefactos ya sea eliminando los cambios/agregados que generaron el conflicto
o corrigiendo los cambios/agregados de manera de que se incluya un merge de la versión (versión fusionada) de los
artefactos conflictivos. |
Crear una nueva compilación de la versión
Generar una nueva compilación de la versión del producto integrada.
Los detalles de este paso dependen del lenguaje de programación y del entorno de desarrollo. Pueden implicar compilar,
vincular (linkear) u otros procesos que den como resultado una versión ejecutable del sistema.
Los ejemplos de estos pasos incluyen:
-
Compilar y vincular los archivos fuente para crear un ejecutable
-
Cargar objetos binarios en un banco de pruebas o simulador
-
Ejecutar un script para generar/actualizar esquemas de bases de datos
-
Empaquetar y desplegar aplicaciones web
|
Verificar los elementos integrados
Ejecutar las pruebas unitarias de los elementos/componentes integrados para verificar que se comporten de la misma
manera que lo hicieron de forma aislada durante la construcción de los elementos. Asegurarse de que el alcance de estas
pruebas sea lo más amplio posible, para garantizar que los últimos cambios/agregados no generaron fallas en
las pruebas de componentes (o unitarias) de otras áreas del sistema. A este tipo de pruebas se las llama "pruebas
de regresión unitaria".
Para esto se recomienda tener las pruebas de componentes (unitarias) automatizadas, para disminuir el costo de
ejecutar las pruebas.
El objetivo de estas pruebas es diferente a cuando se ejecutan con el componente aislado. En la integración el objetivo
es verificar que la comunicación del componente con el resto de los componentes (a diferencia de las pruebas
unitarias que se realizan con stubs o drivers) es correcta.
|
Disponibilizar los cambios
Cuando las pruebas se completan de forma exitosa y la versión generada se considera "buena", los resultados
se ponen a disposición del resto del equipo mediante la aprobación de los cambios. Los detalles de este paso dependen
de las herramientas de gestión de la configuración se estén usando, pero en general esto implica confirmar
(realizar un commit) de un conjunto de cambios probados en el repositorio donde se lleva la gestión de la
configuración, para que sirva como base para el desarrollo del próximo incremento del sistema.
Esta es la "esencia" de la integración continua.
|
Ejecutar "pruebas de humo"
Varias versiones van a ser creadas en cada iteración. Para cada versión, este paso se realiza solamente cuando se
han completado los cambios/agregados que satisfacen los requisitos de una versión.
Será necesario entonces ejecutar un subconjunto de las pruebas de sistema definidas en el plan de pruebas
como pruebas de sistema y/o validación, para asegurarse de que la versión es adecuada para ser sometida
a las pruebas de UAT (antes de comprometer dichos recursos). Si bien el nivel de prueba variará, será
necesario concentrarse en ganar la confianza de que el incremento de la solución generado tiene suficiente calidad
como para establecer una línea base para las pruebas del sistema y pruebas UAT.
Un subconjunto de las pruebas UAT planificadas para este incremento también pueden ser usadas en este paso.
|
Generar una línea base
El procedimiento para este paso depende de las herramientas de gestión de la configuración en uso.
Se deberá crear una línea base que identifique de forma inequívoca la configuración para la versión que se
encuentra lista para la pruebas del sistema y UAT. Identificar la versión de cada elemento de implementación
(código, scripts, archivos de configuración, etc) y los artefactos de soporte que se usaron para crear esta
versión.
|
|
