Integración Continua

El desarrollo de software está lleno de mejores prácticas de las que frecuentemente hablamos, pero rara vez hacemos. Uno de estos casos es el de tener un proceso automatizado para ensamblar y probar versiones ejecutables de nuestro software, de manera que el equipo de desarrollo pueda construir y probar varias veces al día el software en que están trabajando. Este concepto es conocido como “integración continua” y es una de las prácticas de Extreme Programming, sin embargo no es necesario estar siguiendo Extreme Programming para aplicarla.

*Nota: a lo largo de este artículo menciono frecuentemente el concepto de “integrar” software. Esto se refiere al proceso específico de generar una versión ejecutable de un software, que puede involucrar compilar el código fuente, empaquetarlo, incluir archivos de configuración, etcétera; es lo que en inglés se expresa como “to build software”. Adicionalmente, mencionaremos el producto resultante de este proceso, que en inglés se conoce como “software build”, y en español lo estaré llamando “versión ejecutable”.

¿Qué es?

Martin Fowler es uno de los autores más reconocidos en el ámbito de prácticas ágiles y define la integración continua de la siguiente manera:

“La integración continua es una práctica en la que miembros de un equipo integran su trabajo frecuentemente, típicamente cada persona integra al menos una vez al día, generando varias versiones por día. Cada versión ejecutable es verificada por un sistema automático de integración y pruebas para detectar errores de integración lo más rápido posible.”

Implementar esta práctica exitosamente involucra ciertos requisitos:

• Tener un repositorio maestro donde esté disponible todo el código fuente y del que cualquier integrante del equipo pueda obtenerlo.

• Automatizar el proceso de integración para que cualquier persona pueda generar una versión ejecutable del sistema a partir del código fuente.

• Automatizar las pruebas para que sea posible ejecutar la matriz (suite) de pruebas en cualquier momento con un solo comando.

• Asegurar que cualquiera puede obtener el ejecutable más reciente y tener la confianza de que es la mejor versión hasta el momento.

Todo esto requiere bastante disciplina y requiere un esfuerzo significativo para introducirlo a un proyecto, pero una vez habilitado es sencillo mantenerlo y brinda grandes beneficios.

Beneficios

Estos son algunos beneficios puntuales de la integración continua:

• Reducir problemas de integración.

• Mejorar la visibilidad del estatus del producto de software.

• Acelerar la detección de fallas.

• Disminuir el tiempo dedicado a depurar errores.

• Evitar la espera para averiguar si un código funciona.

En resumen, los beneficios de la integración continua consisten en “resolver problemas rápidamente”. Dado que el software es integrado frecuentemente, cuando se encuentra un error típicamente no es necesario retroceder mucho para descubrir donde se introdujo la falla. En comparación, cuando un equipo no sigue una estrategia de integración continua los periodos entre integración son largos y la base de código es muy distinta entre cada integración por lo que cuando se encuentran errores hay que revisar mucho más código, lo cual requiere un mayor tiempo y esfuerzo.

En palabras de Fowler, “la integración continua no elimina los defectos, pero si hace que sea mucho más fácil encontrarlos y corregirlos”.

¿Cómo se hace?

Aunque implantar una estrategia de integración continua no es algo trivial, sí es algo que está al alcance de cualquier organización que desarrolla software sin importar su tamaño, presupuesto o tecnología utilizada. Más que nada es cuestión de que el equipo entienda las prácticas y sea disciplinado.

Comencemos por las prácticas en las que se basa la integración continua [2]:

• Mantener un repositorio único del código fuente.

• Automatizar el proceso de integración (build).

• Hacer que el producto de software se pueda probar a sí mismo.

• Cada que se generan nuevas versiones en el repositorio (“hacer commit”) se debe generar una nueva integración en una máquina designada para ello (integration machine).

• Mantener rápido el proceso de integración.

• El ambiente de prueba debe ser un clon del ambiente de producción.

• Los integrantes del equipo deben poder obtener fácilmente la versión ejecutable más reciente.

• Todos deben poder conocer el estatus en cualquier momento.

• Automatizar el despliegue.

Vale la pena aclarar que aunque la primera práctica indica mantener un repositorio único de código fuente, esto no significa que se tenga que usar un sistema de control de versiones centralizado. Hay que recordar que en un sistema de control de versiones distribuido (DVCS) también hay un repositorio único, es simplemente que tiene varias copias distribuidas.

Una vez que hemos entendido las prácticas y principios podemos entrar a actividades específicas. A continuación describo un posible flujo de actividades para implementar dichas prácticas:

1. Cada desarrollador obtiene una copia del código en su espacio de trabajo privado.

2. Cuando un desarrollador termina su trabajo, envía sus cambios al repositorio.

3. El servidor de integración continua monitorea el repositorio y detecta los cambios automáticamente.

4. El servidor (de integración continua) integra el sistema y corre las pruebas unitarias y de integración.

5. El servidor publica los artefactos ejecutables.

6. El servidor asigna una etiqueta a la nueva versión y su ejecutable.

7. El servidor informa al equipo el resultado de la integración.

8. Si la integración o pruebas fallan, el servidor alerta al equipo y el equipo lo resuelve lo antes posible.

9. Se continúa integrando frecuentemente a lo largo del proyecto.

Para que todo esto funcione se pueden establecer políticas que los integrantes del equipo deban cumplir, tales como:

• Registrar (commit) su código al menos una vez al día.

• No registrar código con errores.

• No registrar código sin probar.

• No generar nuevas versiones con código que no funciona.

• No pueden terminar sus actividades del día hasta haber registrado su código y que el sistema se integre exitosamente.

Algunos equipos generan rituales alrededor de estas políticas para ellos mismos controlar que se cumplan sin necesidad de supervisión de algún coordinador o gerente.

Entrega y despliegue continuo

¿Qué sucede si extendemos el concepto de la integración continua hasta llevarlo al despliegue a producción? Es decir, que cada que se cambia el código de la aplicación, automáticamente se genere un build nuevo, y si pasa exitosamente todas las pruebas automáticamente se libere a producción. Esto es lo que se conoce con el nombre de despliegue continuo (continuous deployment) y aunque parezca utópico, es algo que sí existe y hay organizaciones que lo hacen [2].

¿Qué sucede si queremos quedarnos un pasito antes y simplemente dejar el código “listo para producción”, y solamente si estamos seguros que queremos hacerlo, entonces ya “presionemos el botón” para poner en producción? Justamente eso es lo que se conoce como entrega continua (continuous delivery) y es una práctica recomendada, especialmente en el contexto DevOps [3].

Aunque la entrega continua parezca simplemente agregar un paso más a la integración continua y no tener mayores consecuencias, en realidad no es solo eso ya que por lo pronto involucra tener automatizadas todas las pruebas y scripts para migración de datos así como para rollback en caso de fallas. Adicionalmente, tiene un impacto importante en el modelo de ciclo de vida de software ya que embebe prácticas ágiles en el mismo proceso de planeación y construcción de software. Tan es así, que hay quienes dicen que para realmente estar haciendo “Agile” necesitas tener entrega continua, sino lo que estás haciendo no puede ser llamado Agile [4]. A fin de cuentas, la meta de la entrega continua es poner al cliente al mando de lo que se libera y cuándo se libera.

Pero bueno, es un hecho que antes de correr hay que caminar, así que antes de pensar en entrega continua necesitamos dominar la integración continua.

Referencias

1. M. Fowler. “Continuous Integration”. http://swgu.ru/su

2. T. Fitz. “Continuous deployment at IMVU: Doing the impossible 50 times a day”. http://swgu.ru/sw

3. J. Humble. “Continuous Delivery vs. Continuous Deployment”.  http://swgu.ru/sx

4. I. Buchanan. “Why Agile Development needs Continuous Delivery”. http://swgu.ru/sy