En ingeniería de software , la integración continua ( CI ) es la práctica de fusionar las copias de trabajo de todos los desarrolladores en una línea principal compartida varias veces al día. [1] Hoy en día, normalmente se implementa de tal manera que activa una compilación automatizada con pruebas. Grady Booch propuso por primera vez el término CI en su método de 1991 , [2] aunque no defendía la integración varias veces al día. La programación extrema (XP) adoptó el concepto de CI y abogó por la integración más de una vez al día, tal vez hasta decenas de veces al día. [3]
Al embarcarse en un cambio, un desarrollador toma una copia del código base actual para trabajar. A medida que otros desarrolladores envían el código modificado al repositorio de código fuente , esta copia deja gradualmente de reflejar el código del repositorio. No solo se puede cambiar la base del código existente, sino que se puede agregar código nuevo, así como nuevas bibliotecas y otros recursos que crean dependencias y conflictos potenciales.
Cuanto más tiempo continúe el desarrollo en una rama sin volver a fusionarse con la línea principal, mayor será el riesgo de múltiples conflictos de integración [4] y fallas cuando la rama de 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 deberán realizar los desarrolladores antes de enviar sus propios cambios.
Con el tiempo, el repositorio puede llegar a ser tan diferente de las líneas de base de los desarrolladores que entran en lo que a veces se denomina "infierno de fusión" o "infierno de integración", [5] donde el tiempo que lleva integrar excede el tiempo que llevó crear sus cambios originales. [6]
La CI debe usarse en combinación con pruebas unitarias automatizadas, como las escritas a través de prácticas de desarrollo basado en pruebas . Todas las pruebas unitarias en el entorno local del desarrollador deben ejecutarse y aprobarse antes de comprometerse con la línea principal. Esto ayuda a evitar que el trabajo en curso de un desarrollador rompa la copia de otro desarrollador. Cuando sea necesario, las funciones incompletas se pueden desactivar antes de confirmarlas, mediante la alternancia de funciones , por ejemplo.
Un servidor de compilación compila el código periódicamente. El servidor de compilación puede ejecutar pruebas automáticamente y/o implementar otros procesos de control de calidad continuo . Dichos procesos tienen como objetivo mejorar la calidad del software y el tiempo de entrega ejecutando periódicamente análisis estáticos adicionales, midiendo el rendimiento, extrayendo documentación del código fuente y facilitando procesos manuales de control de calidad .
La CI a menudo está entrelazada con la entrega continua o la implementación continua en lo que se llama un proceso de CI/CD. La "entrega continua" garantiza que el software registrado en la línea principal esté siempre en un estado que pueda implementarse para los usuarios, mientras que la "implementación continua" automatiza completamente el proceso de implementación.
El primer trabajo conocido sobre integración continua fue el entorno Infuse desarrollado por GE Kaiser, DE Perry y WM Schell. [7]
En 1994, Grady Booch utilizó la frase integración continua en Análisis y diseño con aplicaciones orientado a objetos (2ª edición) [8] 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 estaban en el proyecto del Sistema de Compensación Integral de Chrysler , incluida la integración continua. [1] [ fuente autoeditada ] Beck publicó sobre la integración continua en 1998, enfatizando la importancia de la comunicación cara a cara sobre el soporte tecnológico. [9] En 1999, Beck dio más detalles en su primer libro completo sobre Programación Extrema. [10] CruiseControl , una de las primeras herramientas de CI de código abierto, [11] [ fuente autoeditada ] se lanzó en 2001.
En 2010, Timothy Fitz publicó un artículo que detalla cómo el equipo de ingeniería de IMVU había construido y utilizado el primer sistema de CI práctico. Si bien su publicación fue recibida originalmente con escepticismo, rápidamente tuvo aceptación y encontró una adopción generalizada [12] como parte de la metodología de desarrollo de software Lean , también basada en IMVU.
Esta sección enumera las mejores prácticas sugeridas por varios autores sobre cómo lograr una integración continua y cómo automatizar esta práctica. La automatización de la compilación es una mejor práctica en sí misma. [13] [14]
La integración continua (la práctica de integrar frecuentemente el código nuevo o modificado con el repositorio de código existente) debe ocurrir con suficiente frecuencia como para que no quede ninguna ventana intermedia entre la confirmación y la compilación , y de modo que no puedan surgir errores sin que los desarrolladores los noten y los corrijan de inmediato. [1] La práctica normal es activar estas compilaciones con cada confirmación a un repositorio, en lugar de una compilación programada periódicamente. Los aspectos prácticos de hacer esto en un entorno de múltiples desarrolladores de confirmaciones rápidas son tales que es habitual activar un breve período de tiempo después de cada confirmación y luego iniciar una compilación cuando este temporizador expira o después de un intervalo bastante más largo desde la última compilación. Tenga en cuenta que, dado que cada nueva confirmación restablece el temporizador utilizado para el activador de breve duración, esta es la misma técnica utilizada en muchos algoritmos de eliminación de rebotes de botones. [15] De esta manera, los eventos de confirmación se "antirrebotan" para evitar compilaciones innecesarias entre una serie de confirmaciones rápidas. Muchas herramientas automatizadas ofrecen esta programación de forma automática.
Otro factor es la necesidad de un sistema de control de versiones que admita confirmaciones atómicas ; es decir, todos los cambios de un desarrollador pueden verse como una única operación de confirmación. No tiene sentido intentar compilar a partir de sólo la mitad de los archivos modificados.
Para lograr estos objetivos, la integración continua se basa en los siguientes principios.
Esta práctica aboga por el uso de un sistema de control de revisiones del código fuente del proyecto. Todos los artefactos necesarios para construir el proyecto deben colocarse en el repositorio. En esta práctica y en la comunidad de control de revisiones, la convención es que el sistema debe poder construirse desde una nueva versión y no requerir dependencias adicionales. El defensor de la programación extrema, Martin Fowler, también menciona que cuando la ramificación está respaldada por herramientas, su uso debe minimizarse. [16] En cambio, es preferible que los cambios se integren en lugar de mantener múltiples versiones del software simultáneamente. La línea principal (o troncal ) debe ser el lugar para la versión funcional del software.
Un solo comando debería tener la capacidad de construir el sistema. Muchas herramientas de construcción, que existen desde hace muchos años, como make , y otras herramientas más recientes, se utilizan con frecuencia en entornos de integración continua para automatizar la construcción. (Por ejemplo, Makefile, que contiene un conjunto de reglas para crear software, se puede utilizar para automatizar el proceso de creación ). La automatización de la creación debe incluir la automatización de la integración, que a menudo incluye la implementación en un entorno similar a la producción . En muchos casos, el script de compilación no solo compila archivos binarios sino que también genera documentación, páginas de sitios web, estadísticas y medios de distribución (como archivos Debian DEB , Red Hat RPM o Windows MSI ).
Una vez creado el código, se deben ejecutar todas las pruebas para confirmar que se comporta como los desarrolladores esperan que se comporte. [17]
Al comprometerse con regularidad, cada responsable puede reducir la cantidad de cambios conflictivos. Registrar el trabajo de una semana corre el riesgo de entrar en conflicto con otras funciones y puede ser muy difícil de resolver. Los pequeños conflictos tempranos en un área del sistema hacen que los miembros del equipo comuniquen sobre el cambio que están realizando. [18] Realizar todos los cambios al menos una vez al día (una vez por característica creada) generalmente se considera parte de la definición de Integración Continua. Además, generalmente se recomienda realizar una construcción nocturna . [ cita necesaria ] Estos son límites inferiores; Se espera que la frecuencia típica sea mucho mayor.
El sistema debe crear confirmaciones para la versión funcional actual para verificar que se integren correctamente. Una práctica común es utilizar la Integración Continua Automatizada, aunque esto se puede hacer manualmente. La integración continua automatizada emplea un servidor o demonio de integración continua para monitorear el sistema de control de revisiones en busca de cambios y luego ejecutar automáticamente el proceso de compilación.
Al corregir un error, es una buena práctica impulsar un caso de prueba que reproduzca el error. Esto evita que se revierta la solució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 identifique 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 ("puesta en escena") 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 (p. ej., 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 configurar. en un laboratorio de pruebas virtual.
Hacer que las compilaciones estén disponibles para las partes interesadas y los evaluadores puede reducir la cantidad de trabajo 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. Encontrar errores antes puede reducir la cantidad de trabajo necesario para resolverlos.
Todos los programadores deberían comenzar el día actualizando el proyecto desde el repositorio. De esa manera, todos estarán actualizados.
Debería ser fácil saber 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 CI permiten la ejecución de 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 ver. Un avance adicional en esta forma de pensar es la implementación continua , que exige que el software se implemente directamente en producción, a menudo con automatización adicional para evitar defectos o regresiones. [19] [20]
La integración continua tiene como objetivo producir beneficios tales como:
Con las pruebas automatizadas continuas, los beneficios pueden incluir:
Algunas desventajas de la integración continua pueden incluir:
{{cite journal}}: Citar diario requiere |journal=( ayuda )