La integración continua ( CI ) es la práctica de integrar cambios en el código fuente con frecuencia y garantizar que la base de código integrada esté en un estado funcional.
Normalmente, los desarrolladores fusionan los cambios en una rama de integración y un sistema automatizado crea y prueba el sistema de software . [1] A menudo, el proceso automatizado se ejecuta en cada confirmación o se ejecuta según un cronograma, como una vez al día.
Grady Booch propuso por primera vez el término CI en 1991 , [2] aunque no defendía la integración varias veces al día, pero más tarde, CI pasó a incluir ese aspecto. [3]
El primer trabajo conocido (1989) sobre integración continua fue el entorno Infuse desarrollado por GE Kaiser, DE Perry y WM Schell. [4]
En 1994, Grady Booch utilizó la frase integración continua en Object-Oriented Analysis and Design with Applications (2.ª edición) [5] para explicar cómo, cuando se desarrolla utilizando microprocesos, "las versiones internas representan una especie de integración continua del sistema y existen para forzar el cierre del microproceso".
En 1997, Kent Beck y Ron Jeffries inventaron la programación extrema (XP) mientras trabajaban en el proyecto Chrysler Comprehensive Compensation System , que incluía la integración continua. [1] [ fuente autoeditada ] Beck publicó un artículo sobre la integración continua en 1998, destacando la importancia de la comunicación cara a cara por sobre el soporte tecnológico. [6] En 1999, Beck profundizó más en su primer libro completo sobre programación extrema. [7] CruiseControl , una de las primeras herramientas de CI de código abierto, [8] [ fuente autoeditada ] se lanzó en 2001.
En 2010, Timothy Fitz publicó un artículo en el que detallaba cómo el equipo de ingeniería de IMVU había creado y utilizado el primer sistema de integración continua práctico. Si bien su publicación fue recibida inicialmente con escepticismo, rápidamente se popularizó y se adoptó ampliamente [9] como parte de la metodología de desarrollo de software lean , también basada en IMVU.
Las actividades principales de CI son que los desarrolladores coloquen los cambios de código en un área de integración compartida con frecuencia y que la base de código integrada resultante se verifique para comprobar su corrección. La primera parte generalmente implica fusionar los cambios en una rama de control de versiones común. La segunda parte generalmente implica procesos automatizados que incluyen: creación, prueba y muchos otros procesos.
Por lo general, un servidor compila desde el área de integración con frecuencia; es decir, después de cada confirmación o periódicamente, como una vez al día. El servidor puede realizar controles de calidad , como ejecutar pruebas unitarias [10], y recopilar métricas de calidad del software a través de procesos como análisis estático y pruebas de rendimiento.
En esta sección se enumeran las mejores prácticas de los profesionales para otras prácticas que mejoran la mejora continua.
La automatización de la compilación es una buena práctica. [11] [12]
CI requiere que el sistema de control de versiones admita confirmaciones atómicas , es decir, todos los cambios de un desarrollador se manejan como una única confirmación.
Al realizar un cambio de código, un desarrollador crea una rama que es una copia del código base actual . A medida que se envían otros cambios al repositorio , esta copia se desvía de la última versión.
Cuanto más tiempo se prolongue el desarrollo en una rama sin fusionarla con la rama de integración, mayor será el riesgo de múltiples conflictos de integración [13] y fallas cuando la rama del desarrollador finalmente se vuelva a fusionar. Cuando los desarrolladores envían código al repositorio, primero deben actualizar su código para reflejar los cambios en el repositorio desde que tomaron su copia. Cuantos más cambios contenga el repositorio, más trabajo deben hacer los desarrolladores antes de enviar sus propios cambios.
Con el tiempo, el repositorio puede llegar a ser tan diferente de las líneas base de los desarrolladores que entran en lo que a veces se conoce como "infierno de la fusión" o "infierno de la integración", [14] donde el tiempo que lleva realizar la integración excede el tiempo que llevó realizar los cambios originales. [15]
Los defensores de CI sugieren que los desarrolladores deberían utilizar un desarrollo basado en pruebas y garantizar que todas las pruebas unitarias pasen localmente antes de confirmarlas en la rama de integración para que el trabajo de un desarrollador no dañe la copia de otro desarrollador.
Las funciones incompletas se pueden deshabilitar antes de confirmar, mediante el uso de interruptores de funciones .
La entrega continua garantiza que el software registrado en una rama de integración esté siempre en un estado que pueda implementarse para los usuarios, y la implementación continua automatiza el proceso de implementación.
La entrega continua y la implementación continua a menudo se realizan junto con CI y juntas forman una cadena de CI/CD.
Los defensores de CI recomiendan almacenar todos los archivos y la información necesaria para la compilación en el control de versiones (en el caso de Git , un repositorio ); que el sistema se pueda compilar desde un nuevo pago y que no requiera dependencias adicionales.
Martin Fowler recomienda que todos los desarrolladores se comprometan con la misma rama de integración. [16]
Las herramientas de automatización de compilación automatizan la construcción.
Los defensores de CI recomiendan que un solo comando tenga la capacidad de construir el sistema.
La automatización a menudo incluye la automatización de la integración, que a menudo incluye la implementación en un entorno similar al de producción . En muchos casos, el script de compilación no solo compila binarios, sino que también genera documentación, páginas web, estadísticas y medios de distribución (como archivos DEB de Debian , RPM de Red Hat o MSI de Windows ).
Los desarrolladores pueden reducir el esfuerzo que supone resolver cambios conflictivos sincronizando los cambios entre sí con frecuencia, al menos una vez al día. Si se registra el trabajo de una semana, se corre el riesgo de que surjan conflictos tanto en cuanto a la probabilidad de que se produzcan como a la complejidad de su resolución. Los conflictos relativamente pequeños son significativamente más fáciles de resolver que los grandes. Integrar (confirmar) los cambios al menos una vez al día se considera una buena práctica, y es mejor hacerlo con más frecuencia. [17]
En general, se recomienda construir a diario , o incluso con mayor frecuencia. [ cita requerida ]
El sistema debe compilar las confirmaciones de la versión actual en funcionamiento para verificar que se integren correctamente. Una práctica habitual es utilizar la integración continua automatizada, aunque esto puede hacerse de forma manual. La integración continua automatizada emplea un servidor o demonio de integración continua para supervisar el sistema de control de revisión en busca de cambios y, a continuación, ejecutar automáticamente el proceso de compilación.
Al corregir un error, es una buena práctica enviar un caso de prueba que reproduzca el error. Esto evita que se revierta la corrección y que el error vuelva a aparecer, lo que se conoce como regresión .
La compilación debe completarse rápidamente para que, si hay un problema con la integración, se pueda identificar rápidamente.
Tener un entorno de prueba puede provocar fallas en los sistemas probados cuando se implementan en el entorno de producción porque el entorno de producción puede diferir del entorno de prueba de manera significativa. Sin embargo, construir una réplica de un entorno de producción tiene un costo prohibitivo. En cambio, el entorno de prueba o un entorno de preproducción separado ("ensayo") debe construirse para que sea una versión escalable del entorno de producción para aliviar los costos y, al mismo tiempo, mantener la composición y los matices de la pila de tecnología . Dentro de estos entornos de prueba, la virtualización de servicios se usa comúnmente para obtener acceso bajo demanda a dependencias (por ejemplo, API, aplicaciones de terceros, servicios, mainframes , etc.) que están fuera del control del equipo, aún están evolucionando o son demasiado complejas para configurarlas en un laboratorio de pruebas virtual.
Poner las compilaciones a disposición de las partes interesadas y los evaluadores puede reducir la cantidad de trabajo de rehacer necesario al reconstruir una característica que no cumple con los requisitos. Además, las pruebas tempranas reducen las posibilidades de que los defectos sobrevivan hasta la implementación. Detectar errores antes puede reducir la cantidad de trabajo necesario para resolverlos.
Todos los programadores deberían empezar el día actualizando el proyecto desde el repositorio. De esa manera, todos estarán al día.
Debería ser fácil descubrir si la compilación falla y, de ser así, quién realizó el cambio relevante y cuál fue ese cambio.
La mayoría de los sistemas de integración continua permiten ejecutar scripts una vez finalizada la compilación. En la mayoría de las situaciones, es posible escribir un script para implementar la aplicación en un servidor de prueba en vivo que todos puedan consultar. Otro avance en esta forma de pensar es la implementación continua , que requiere que el software se implemente directamente en producción, a menudo con automatización adicional para evitar defectos o regresiones. [18] [19]
Los beneficios de CI incluyen:
Los riesgos de IC incluyen:
{{cite journal}}: Requiere citar revista |journal=( ayuda )