La Integración Continua es una práctica de desarrollo de software donde los miembros de un equipo integran su trabajo con frecuencia. Normalmente cada persona integra al menos diariamente, conduciendo a múltiples integraciones por día.Muchos equipos encuentran que este enfoque conduce a una reducción considerable de los problemas de integración y permite al equipo desarrollar software coherente con mayor rapidez.

Durante el desarrollo de un proyecto software, cada desarrollador tiene una copia de la línea base sobre la que trabaja. Mientras un desarrollador actualiza sus cambios en el repositorio, otro desarrollador puede estar trabajando con una copia que no refleja estos cambios. Para que esto no suceda, cada desarrollador debería actualizar su copia de la línea base, resolver sus conflictos y a continuación actualizar el repositorio con sus cambios Esto es parte de la integración del código.

Cuando en el entorno de desarrollo  conviven varios desarrolladores actualizando varias veces la línea base, podemos encontrar el denominado ‘infierno de interacción’, que consiste en que el desarrollador pasa más tiempo tratando de mantener su copia de la línea base actualizada y coherente que desarrollando las tareas que tiene asignadas.

El concepto de Integración Continua propone actualizar con frecuencia de forma automática, de manera que podamos evitar el ‘infierno de integración’. Esta práctica reduce la repetición de tareas y en definitiva es un ahorro de costes y tiempo.

Existen otros métodos opuestos a la Integración Continua, i.e: antes de actualizar los cambios locales, cada desarrollador debe realizar una actualización de su copia de la línea base y construir completamente el proyecto con sus pruebas. Así cada desarrollador debe realizar esta tarea al comienzo de la jornada y tener su trabajo siempre al día. Esta aproximación contraria a la Integración Continua requiere una gran cantidad de esfuerzo dedicado por cada desarrollador.

La Integración Continua se presenta como un método basado en la automatización de la construcción de un proyecto a partir de un repositorio de código. Una vez construido, la automatización despliega el proyecto en uno o varios entornos similares a los entornos de producción. Además, la automatización también llevará a cabo una serie de pruebas definidas para validar el proyecto, que pueden ser de varios tipos, como pruebas unitarias de código, pruebas funcionales, pruebas de rendimiento, etc. Dentro de la automatización se pueden englobar todas las tareas relacionadas con pruebas de calidad del código.

Así, un sistema de Integración Continua consiste generalmente en:

• Un repositorio de código donde los desarrolladores actualizan su trabajo contra la línea base.
• Un servidor de Integración Continua, que obtendrá una copia de la línea base y construirá automáticamente el proyecto.
• El servidor de Integración Continua ejecutará el  despliegue del proyecto recién construido en uno o varios entornos de pruebas
• Una vez desplegado el proyecto, el servidor de Integración Continua lanzará automáticamente las pruebas definidas para este proyecto.
• El servidor de Integración Continua recogerá y analizará los resultados de la construcción del proyecto, el despliegue y las pruebas, informando a los desarrolladores del estado del proyecto.

Dependiendo del volumen del proyecto y de los recursos destinados a la Integración Continua, el proceso automatizado se puede lanzar con mayor o menor frecuencia. Así, si un ciclo completo de pruebas y validaciones de un proyecto toma 10 horas con X recursos, podríamos lanzar el proceso de Integración Continua todas las noches con el trabajo del día de los desarrolladores. Mientras que si el ciclo completo dura unos minutos, podríamos lanzar un proceso con cada cambio que actualice cada desarrollador.

Una vez tenemos implementado el proceso de Integración Continua, tendremos todos los días un proyecto construido y probado listo para ser entregado al cliente, sin necesidad de hacer un sobre esfuerzo en los desarrolladores para que integren todo el producto y generen una versión entregable en las últimas semanas.

En resumen, la Integración Continua nos aporta una serie de ventajas:

• Cuando las pruebas de integración detectan un fallo, los desarrolladores pueden revertir el código para alcanzar una línea base libre de fallos con rapidez y sin desperdiciar tiempo analizando los fallos.
• Los desarrolladores detectan y corrigen fallos de integración de manera continua, evitando el caos del último minuto de la fecha de entrega.
• Alerta temprana de código roto o incompatible.
• Alerta temprana de cambios conflictivos.
• Pruebas unitarias inmediatas en cada cambio y para todos los cambios.
• Disponibilidad continua de una versión entregable, lista para pruebas, demostraciones o entregas finales.
• Respuesta inmediata a los desarrolladores sobre la calidad, funcionalidad, o el impacto en el conjunto total del sistema del código que están escribiendo.
• Las frecuentes comprobaciones de código impulsan a los desarrolladores a escribir código más modular y menos complejo.
• El proceso genera métricas de las pruebas automáticas, cuyos resultados dirigen a los desarrolladores a escribir código más funcional y con más calidad.

Aunque también tiene una serie de inconvenientes a tener en cuenta:

• Despliegue inicial, preparar un entorno de Integración Continua completo es bastante complejo.
• Para conseguir las ventajas de las pruebas, hay que desarrollar y mantener un buen conjunto de pruebas.
• El coste de los recursos necesarios en máquinas puede ser significativo. La automatización de todos los procesos necesita una gran cantidad de CPU, Memoria, Almacenamiento y Ancho de Banda.

No obstante, haciendo balance de todo ello, consideramos recomendable la Integración Continua en los procesos de desarrollo de proyectos software.