Integración continua

La automatización de compilaciones es una buena práctica. ^{[ 11 ] [ 12 ]} Las herramientas de automatización de compilaciones automatizan la compilación.

Los defensores de la integración continua recomiendan que un solo comando tenga la capacidad de construir el sistema.

La automatización suele incluir la automatización de la integración, que a menudo comprende el despliegue 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).

La integración continua (CI) requiere que el sistema de control de versiones admita confirmaciones atómicas ; en otras palabras, todos los cambios de un desarrollador se gestionan como una única confirmación.

Al realizar un cambio en el código, un desarrollador crea una rama que es una copia del código base actual . A medida que se confirman otros cambios en el repositorio , esta copia diverge 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 fallos cuando finalmente se fusione la rama del desarrollador. Cuando los desarrolladores envían código al repositorio, primero deben actualizarlo para reflejar los cambios realizados en el repositorio desde que obtuvieron 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 volverse tan diferente de las líneas base de los desarrolladores que entran en lo que a veces se denomina "infierno de fusión" o "infierno de integración" ^{[ 14 ]} , donde el tiempo que lleva integrar excede el tiempo que les llevó realizar sus cambios originales. ^{[ 15 ]}

Los defensores de la integración continua sugieren que los desarrolladores utilicen el desarrollo guiado por pruebas y se aseguren de que todas las pruebas unitarias se ejecuten correctamente de forma local antes de confirmar los cambios en la rama de integración, para que el trabajo de un desarrollador no dañe la copia de otro.

Las funciones incompletas se pueden deshabilitar antes de confirmar los cambios, utilizando interruptores de funciones .

La entrega continua garantiza que el software registrado en una rama de integración esté siempre en un estado que permita su despliegue a los usuarios, y el despliegue continuo automatiza el proceso de despliegue.

La entrega continua y el despliegue continuo a menudo se realizan junto con la integración continua (CI) y, en conjunto, forman una canalización de CI/CD.

Los defensores de la integración continua recomiendan almacenar todos los archivos e información necesarios para la compilación en un sistema de control de versiones (en el caso de Git , un repositorio ), y que el sistema se pueda compilar desde una copia nueva sin necesidad de dependencias adicionales.

Martin Fowler recomienda que todos los desarrolladores se comprometan con la misma rama de integración. ^{[ 16 ]}

Los desarrolladores pueden reducir el esfuerzo de resolver cambios conflictivos sincronizándolos entre sí con frecuencia, al menos diariamente. Registrar el trabajo de una semana conlleva el riesgo de conflictos, tanto por la probabilidad de que ocurran como por 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 con mayor frecuencia, mejor. ^{[ 17 ]}

Generalmente se recomienda construir a diario , o incluso con mayor frecuencia. ^{[ 18 ]}

El sistema debe generar confirmaciones en la versión de trabajo actual para verificar que se integren correctamente. Una práctica común es usar la integración continua automatizada, aunque también 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 versiones en busca de cambios y luego ejecutar automáticamente el proceso de compilación.

Al corregir un error, es recomendable implementar un caso de prueba que lo reproduzca. Esto evita que la corrección se revierta y que el error reaparezca, lo que se conoce como regresión.

Es necesario que la compilación finalice rápidamente para que, si surge algún problema de integración, se identifique con prontitud.

Disponer de un entorno de pruebas puede provocar fallos en los sistemas probados al implementarlos en el entorno de producción, ya que este último puede diferir significativamente del de pruebas. Sin embargo, crear una réplica del entorno de producción resulta prohibitivo en términos de costes. En su lugar, el entorno de pruebas o un entorno de preproducción independiente ("staging") debería diseñarse como una versión escalable del entorno de producción para reducir costes, manteniendo al mismo tiempo la composición y las particularidades de la pila tecnológica . En estos entornos de pruebas, se suele utilizar la virtualización de servicios 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 en desarrollo o son demasiado complejas para configurarlas en un laboratorio de pruebas virtual.

Facilitar el acceso a las versiones compiladas a las partes interesadas y a los evaluadores puede reducir la cantidad de trabajo adicional necesario al reconstruir una función que no cumple con los requisitos. Además, las pruebas tempranas disminuyen las probabilidades de que los defectos persistan hasta el despliegue. Detectar los errores con anticipación reduce el trabajo necesario para resolverlos.

Todos los programadores deberían comenzar el día actualizando el proyecto desde el repositorio. De esa forma, todos estarán al día.

Debería ser fácil averiguar si la compilación falla y, en caso afirmativo, quién realizó el cambio pertinente y cuál fue ese cambio.

La mayoría de los sistemas de integración continua (CI) permiten ejecutar scripts una vez finalizada la compilación. En la mayoría de los casos, es posible escribir un script para desplegar la aplicación en un servidor de prueba en vivo que todos puedan consultar. Un avance adicional en este enfoque es el despliegue continuo , que requiere que el software se despliegue directamente en producción, a menudo con automatización adicional para prevenir defectos o regresiones. ^{[ 19 ] [ 20 ]}