La integración continua de múltiples etapas es una técnica de desarrollo de software destinada a lograr una actividad de desarrollo paralela altamente integrada y al mismo tiempo reducir el alcance de los problemas de integración. [1]
La integración continua de múltiples etapas aprovecha un patrón unificador básico de desarrollo de software: el software pasa 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. con el tiempo. Lo que cambia de un taller a otro es el número de etapas, el número y tamaño de los equipos y la estructura de las interdependencias del equipo.
La integración continua de varias etapas es una expansión de la integración continua ; supone que ya está siguiendo esas prácticas recomendadas.
Cuanto más grande y/o más complejo sea el proyecto, mayores serán las posibilidades de que se vuelva inestable. Las alertas y las compilaciones fallidas 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 fallos en la construcción aumenta exponencialmente a medida que aumentan el número y las ubicaciones de los desarrolladores. [2]
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, sólo ese equipo se ve afectado, no todo el esfuerzo de desarrollo. Esto es similar a cómo funciona la parada de línea en una instalación moderna de fabricación ajustada. Si alguien en la línea tira del cordón 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 "tema" o "característica" ha ganado popularidad sobre el modelo de rama basado en equipos. Véase, por ejemplo, el popular modelo de ramificación Git-Flow [3].
Con frecuencia, el equipo decidirá pasar a la segunda fase: la 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 habrá funciones preintegradas, no 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 donde 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 sólo cuando hay un problema. Idealmente, los cambios llegan al área de integración principal con la misma frecuencia que cuando se realiza el desarrollo principal. La diferencia es que menos problemas llegan hasta la principal zona de integración. La integración continua de múltiples etapas permite que se produzca un alto grado de integración en paralelo, al tiempo que reduce enormemente el alcance de los problemas de integración. [4]
Para una integración continua de varias etapas, cada equipo debe tener su propia sucursal.
La integración continua de varias etapas tiene muchas ventajas: [ cita necesaria ]
Las herramientas que admiten la integración continua de varias etapas incluyen: