¿Qué es la integración continua? [cerrado]

En su forma más simple, es simplemente un mecanismo que reconstruye su proyecto cada vez que se realiza un check in en algún sistema de control de revisiones (CVS, etc.). Sin embargo, esto se puede extender para incluir la ejecución de pruebas, hasta la generación de una imagen de CD, el montaje dentro de las máquinas virtuales, la instalación del producto y la ejecución de pruebas completas en él.

Tiene la simple ventaja de resaltar cuando los cambios de código rompen el sistema lo antes posible. No solo detecta interrupciones en el código, sino que resalta quien causó la ruptura. Este efecto psicológico es muy eficaz en el fomento de una buena prueba antes de registrarse!

Es la práctica de asegurar que todos los aspectos de su proceso de desarrollo de software estén alineados para permitir la creación diaria de una versión de trabajo de su producto. Es mejor conocido como parte de la Programación Extrema.

Esto implica cosas tan lejanas como la automatización de la compilación, las pruebas automatizadas, las comprobaciones diarias, el uso de un repositorio de código fuente, etc. Pero el objetivo final es ayudar a que todo el proyecto se ejecute de acuerdo con los principios Ágiles básicos para que pueda entregar temprano y con frecuencia. Este, a su vez, le ayuda a aprovechar los comentarios de sus usuarios, etc.

+1 para el enlace a la página de Fowler.

Personalmente, me pareció "agradable" saber cuando algo no se compilaba porque teníamos la mala práctica de tener una sola compilación (sí, desarrollamos en la compilación de producción; fuimos increíbles). No teníamos la fase de pruebas integradas antes de irme.

Después de un tiempo, sin embargo, disminuyó la cantidad de cambios masivos de codificación (en comparación con el "check in and pray my changes don't conflict" que estaba desenfrenado). Con el tiempo, la mayoría los desarrolladores comenzaron a hacer pequeños cambios con frecuencia solo para obtener la confirmación de la CC.Net icono de bandeja.

En general, me pareció muy reconfortante saber que podíamos enviar una construcción inmediatamente si teníamos que hacerlo. Si hubiéramos tenido solo unas pocas pruebas de humo integradas, creo que el nivel de estrés habría sido sustancialmente menor.

Solo para refrescar. En este punto hay una gran diferencia entre la Integración Continua (CI) y la Entrega Continua (CD). Mientras que la mayoría de los posts descritos anteriormente CD voy a tratar de mostrar cómo CI extiende ahora la definición de CD. Tener todas las herramientas necesarias para construir un paquete e implementar una nueva versión de la aplicación automáticamente es una parte crucial de CD. Además de eso, la automatización de las pruebas (basada en tres niveles de verificación: Chequeo general, Estadísticas Detalladas y registros históricos) y una gobernanza adecuada estás creando una muy buena pieza de IC. Solo gracias a una definición tan extendida es posible crear herramientas extraordinarias en la nube. Piensa en muleESB o esbeetle.com. Para ambos CI es algo natural, aunque solo el segundo es compatible con los componentes ESB y ETL.

Espero que haya sido útil.