Índice del contenido
La integración continua (CI) implica producir una compilación limpia del sistema varias veces al día, generalmente con una herramienta como CruiseControl, que usa Ant y varios sistemas de control de fuente. Los equipos ágiles suelen configurar CI para incluir compilación automatizada, ejecución de pruebas unitarias e integración de control de código fuente. A veces, CI también incluye la ejecución automática de pruebas de aceptación automatizadas, como las desarrolladas con FitNesse. En efecto, CI significa que la compilación casi siempre está limpia.
Técnica, herramientas y política de integración continua
Hay varias prácticas específicas que CI parece requerir para funcionar bien. en su sitio, Martin Fowler proporciona una descripción larga y detallada de lo que es la integración continua y cómo hacer que funcione.
Una regla popular de CI establece que los programadores nunca dejan nada sin integrar al final del día. La construcción nunca debe pasar la noche en un estado roto. Esto impone cierta disciplina de planificación de tareas en los equipos de programación. Además, si la regla del equipo es que quien rompa la compilación en el check-in debe arreglarlo nuevamente, existe un incentivo natural para verificar el código con frecuencia durante el día.
Beneficios de la integración continua
Cuando CI funciona bien, ayuda a que el código se mantenga lo suficientemente sólido como para que los clientes y otras partes interesadas puedan jugar con el código cuando lo deseen. Esto acelera el flujo del trabajo de desarrollo en general; como señala Fowler, tiene una sensación muy diferente. También fomenta más comentarios entre los programadores y los clientes, lo que ayuda al equipo a hacer las cosas bien antes de los plazos de iteración. Al igual que la refactorización, la integración continua funciona bien si tiene un conjunto exhaustivo de pruebas unitarias automatizadas que garantizan que no está cometiendo código con errores.
Una CI hábil significa que la integración nunca es un dolor de cabeza, porque su trabajo refleja solo una ligera divergencia con respecto al código base. Si el equipo debe lidiar regularmente con divergencias de pequeña escala, nunca tendrá que lidiar con las que realmente dan miedo. También tienen la oportunidad de discutir diferentes enfoques de diseño el día que surgen, porque la integración de ese día los llama la atención de todo el equipo.
