Integración continua

Este artículo incluye una lista de referencias generales , pero carece de suficientes citas en línea correspondientes . Ayúdenos a mejorar este artículo introduciendo citas más precisas. ( Julio de 2016 ) ( Aprenda cómo y cuándo eliminar este mensaje )

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]

This section needs expansion. You can help by adding to it. (August 2014)

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.

This section contains instructions, advice, or how-to content. Please help rewrite the content so that it is more encyclopedic or move it to Wikiversity, Wikibooks, or Wikivoyage. (May 2015)

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]}

The neutrality of this section is disputed. Relevant discussion may be found on the talk page. Please do not remove this message until conditions to do so are met. (May 2016) (Learn how and when to remove this message)

This section needs additional citations for verification. Please help improve this article by adding citations to reliable sources in this section. Unsourced material may be challenged and removed. (May 2016) (Learn how and when to remove this message)

Los beneficios de CI incluyen:

• Facilita la detección temprana de errores .
• Reduce el esfuerzo para encontrar la causa de los errores; si una prueba de CI falla, los cambios desde la última compilación correcta contienen el cambio causante; si se compila después de cada cambio, entonces exactamente un cambio es la causa ^[1]
• Evita el caos de integrar muchos cambios
• Cuando una prueba falla o se encuentra un error, revertir el código base a un buen estado da como resultado menos cambios perdidos.
• Disponibilidad frecuente de una compilación conocida y en buen estado para pruebas, demostración y lanzamiento
• La confirmación frecuente de código fomenta un código modular y menos complejo ^[20]
• Comentarios rápidos sobre el impacto de los cambios de código en todo el sistema
• Admite la recopilación de métricas de software , como la cobertura del código y la complejidad del código.

Los riesgos de IC incluyen:

• La configuración del sistema de compilación requiere esfuerzo ^[21]
• Escribir y mantener un conjunto de pruebas automatizadas requiere esfuerzo
• El valor añadido depende de la calidad de las pruebas ^[22]
• La alta latencia de compilación (esperando en cola) limita el valor ^[22]
• Implica que no se debe integrar código incompleto, lo que es contrario a la práctica preferida de algunos desarrolladores ^[22]
• La seguridad y la garantía del desarrollo de misión crítica (por ejemplo, DO-178C , ISO 26262 ) requieren documentación y revisión que pueden ser difíciles de lograr.

• Automatización del lanzamiento de aplicaciones  : proceso de empaquetado e implementaciónPages displaying short descriptions of redirect targets
• Indicador de luz de compilación  : dispositivo visual utilizado en el desarrollo de software ágil para informar al equipo sobre el progreso de la compilación.Pages displaying wikidata descriptions as a fallback
• Comparación de software de integración continua
• Diseño continuo  : proceso de diseño modular en el que los componentes se pueden sustituir libremente para mejorar el diseño, modificar el rendimiento o cambiar otra característica en un momento posterior.Pages displaying wikidata descriptions as a fallback
• Prueba continua  : proceso de ejecución de pruebas automatizadas como parte del proceso de entrega de software para obtener retroalimentación inmediata sobre los riesgos comerciales asociados con un candidato a lanzamiento.Pages displaying wikidata descriptions as a fallback
• Integración continua en múltiples etapas  : técnica de desarrollo de software
• Desarrollo rápido de aplicaciones  : concepto de desarrollo de software

• "Integración continua" (wiki) (una discusión colegial). C2. {{cite journal}}: Requiere citar revista |journal=( ayuda )
• Richardson, Jared. "Integración continua: la piedra angular de una gran tienda" (introducción).
• Flowers, Jay. "Una receta para la capacidad de mantenimiento y reutilización de los sistemas". Archivado desde el original el 25 de junio de 2020. Consultado el 28 de mayo de 2006 .
• Duvall, Paul (4 de diciembre de 2007). "Trabajos de desarrolladores". IBM .
• "Ciclo de vida de una versión". MediaWiki. Junio ​​de 2024.