La integración continua de múltiples etapas es una técnica de desarrollo de software destinada a lograr una actividad de desarrollo paralelo altamente integrada mientras se reduce el alcance de los problemas de integración.
La integración continua de múltiples etapas aprovecha un patrón unificador básico de desarrollo de software: el software se mueve en etapas desde un estado de inmadurez a un estado de madurez, y el trabajo se divide en unidades lógicas realizadas por equipos interdependientes que integran las diferentes partes juntas tiempo extraordinario. Lo que cambia de una tienda a otra es la cantidad de etapas, la cantidad y el tamaño de los equipos y la estructura de las interdependencias de los equipos.
La integración continua de múltiples etapas es una expansión sobre la integración continua, se supone que ya está siguiendo esas prácticas recomendadas.
Cuanto más grande y / o complejo sea el proyecto, mayor será la probabilidad de que el proyecto se vuelva inestable. Las alertas y las compilaciones rotas aumentan a medida que crece el proyecto. El progreso disminuye y la línea principal se vuelve cada vez más inestable. El riesgo de fallas en la construcción aumenta exponencialmente a medida que aumenta el número y las ubicaciones de los desarrolladores.
Cada desarrollador trabaja en su propia tarea. A medida que realizan cambios, se realiza una integración continua con la rama de ese equipo. Si no tiene éxito, entonces ese desarrollador (posiblemente con la ayuda de sus compañeros de equipo) arregla la rama. Cuando hay un problema, solo ese equipo se ve afectado, no todo el esfuerzo de desarrollo. Esto es similar a cómo funciona detener la línea en una instalación moderna de fabricación ajustada. Si alguien en la línea tira del cable de "detener la línea", solo afectará a un segmento de la línea, no a toda la línea.
Es digno de mención que en los últimos años el modelo de rama de "tema" o "función" ha ganado popularidad sobre el modelo de rama basado en equipos. Vea, por ejemplo, el popular modelo de ramificación de Git-Flow
Con frecuencia, el equipo decidirá pasar a la segunda fase: integración con la línea principal. En esta fase, el equipo hace lo mismo que haría un individuo en el caso del desarrollo principal. La rama del equipo debe tener todos los cambios de la línea principal fusionados (el equivalente a una actualización del espacio de trabajo), debe haber una compilación exitosa y todas las pruebas deben pasar. La integración con la línea principal será más fácil de lo habitual porque solo estarán las funciones preintegradas, no las funciones en proceso. Luego, los cambios del equipo se fusionan en la línea principal, lo que desencadenará un ciclo de compilación y prueba en la línea principal. Si eso pasa, entonces el equipo vuelve a la primera fase en la que los desarrolladores individuales trabajan en sus propias tareas. De lo contrario, el equipo trabaja para que la línea principal vuelva a funcionar, como si fuera un individuo trabajando en la línea principal.
Los cambios se propagan lo más rápido posible y se detienen solo cuando hay un problema. Idealmente, los cambios llegan al área de integración principal con la misma frecuencia que cuando se realiza el desarrollo de la línea principal. La diferencia es que menos problemas llegan hasta el área de integración principal. La integración continua de múltiples etapas permite que ocurra un alto grado de integración en paralelo al tiempo que reduce enormemente el alcance de los problemas de integración.
Para la integración continua de múltiples etapas, cada equipo debe tener su propia rama.
La integración continua de varias etapas tiene muchas ventajas:
Las herramientas que admiten la integración continua de varias etapas incluyen:
