La integración continua ( CI , ing. Continuous Integration ) es una práctica de desarrollo de software que consiste en fusionar constantemente copias de trabajo en una rama de desarrollo principal común (hasta varias veces al día) y realizar compilaciones de proyectos automatizadas frecuentes para identificar rápidamente posibles defectos y resolver la integración problemas En un proyecto típico, donde los desarrolladores trabajan de forma independiente en diferentes partes del sistema, la etapa de integración es la final. Puede retrasar impredeciblemente la finalización del trabajo. La transición a la integración continua le permite reducir la complejidad de la integración y hacerla más predecible debido a la detección temprana y la eliminación de errores e inconsistencias, pero la principal ventaja es reducir el costo de corregir un defecto debido a su detección temprana.
Primero conceptualizado y propuesto por Grady Booch en 1991 [1] . Es uno de los elementos principales de la práctica de la Programación Extrema .
Para aplicar la práctica, es necesario cumplir una serie de requisitos básicos para el proyecto de desarrollo. En particular, el código fuente y todo lo que se necesita para compilar y probar el proyecto deben almacenarse en el repositorio del sistema de control de versiones , y las operaciones de copiar desde el repositorio, compilar y probar todo el proyecto deben automatizarse y llamarse fácilmente desde dispositivos externos. programas
Para organizar el proceso de integración continua en un servidor dedicado, se lanza un servicio, cuyas tareas incluyen:
Una compilación local se puede realizar por una solicitud externa, por programación, por el hecho de una actualización del repositorio y por otros criterios.
Las compilaciones programadas ( ing. daily build - daily build ), por regla general, se llevan a cabo fuera del horario de atención, por la noche ( ing. nightly build ), se planifican de tal manera que los resultados de las pruebas estén listos al comienzo del siguiente día hábil. Para distinguir, se introduce adicionalmente un sistema de numeración de conjuntos; por lo general, cada conjunto se numera con un número natural, que aumenta con cada nuevo conjunto. Los textos de origen y otros datos de origen, cuando se toman del repositorio (repositorio) del sistema de control de versiones, se marcan con un número de compilación. Gracias a esto, exactamente el mismo ensamblaje se puede reproducir con precisión en el futuro: simplemente tome los datos de origen para la etiqueta deseada y comience el proceso nuevamente. Esto hace posible volver a publicar incluso versiones muy antiguas del programa con correcciones menores.
Los beneficios de la integración continua incluyen:
Al mismo tiempo, la práctica no está exenta de inconvenientes, en particular:
Además, el efecto inmediato de un código incompleto o que no funciona desalienta a los desarrolladores a realizar copias de seguridad periódicas del código en el repositorio, pero en el caso de utilizar un sistema de control de versiones de código fuente con soporte de bifurcación, este problema se puede resolver creando un código separado. "rama" ( eng. rama ) del proyecto para realizar cambios importantes (código, cuyo desarrollo a una versión viable llevará varios días, pero es deseable guardar el resultado con más frecuencia en el repositorio). Una vez que se completa el desarrollo y las pruebas individuales de dicha rama, se puede fusionar ( fusionar ) con el código principal o "troncal" ( troncal ) del proyecto.