Como decíamos "ayer", una de las tareas propias de las metodologías ágiles es la llamada "integración continua".
Esta práctica consiste en llevar al límite el proceso de construcción automática y diaria. Si conseguimos automatizar este proceso ¿porqué no lanzarlo cada vez que hagamos algún cambio, por pequeño que sea?
Pues precisamente esa es la clave de la integración continua, pero como es lógico, no todo es tan fácil como puede parecer a simple vista.

El primer paso para la integración continua es, como ya hemos dicho, automatizar el proceso de construcción. Para ello nos basamos en herramientas como Ant, Maven, el antiguo MAKE, Jam, etc., que nos permiten ir lanzando distintas tareas de forma secuencial y sin nuestra intervención.
Una vez que hemos logrado ejecutar todos los pasos necesarios, tenemos que conseguir que ese proceso se lance automaticamente, cada vez que algún cambio de código se integra en el repositorio. Lo podemos conseguir facilmente gracias a un montón de herramientas para ello, que nos ayudan a programar las construcciones, aunque también podríamos habilitar una máquina dedicada y conseguir que todo el equipo se comprometa a lanzar una compilación después registrar cada cambio. Ummmm, creo que va a ser mejor instalarse alguna herramienta ¿no?
Empresas que manejan proyectos muy grandes dan a este aspecto una importancia vital. Por ejemplo: Microsoft, en su equipo de desarrollo de Windows, tiene todo un laboratorio de construcciones diarias: un montón de servidores y personas responsables de que la compilación y las pruebas se ejecuten correctamente todos los días.

Bien, el modelo de integración continua, si no se hace con cabeza, puede traernos más problemas que ventajas.
Pongamos el caso en que tenemos un repositorio con nuestro código fuente. Nosotros usamos Subversion, pero valdrían otros como CVS, Source Safe, Perforce, etc. Cada vez que integramos un cambio en el repositorio, existe alguna posibilidad de que el programa deje de compilar (por ejemplo si hemos olvidado subir un archivo nuevo), o que hayamos generado algún bug, así que podemos decir que en ese momento, y hasta que se valide de nuevo, el repositorio está en estado inestable. Si hacemos que se lance una construcción cada vez que integramos algo en el repositorio, muchas de esas construcciones fallarán. Por ejemplo: todas las tardes, antes de irnos a casa, registramos nuestro trabajo, aunque no esté terminado, y muchas veces la construcción resultante no es válida. Pensad que esto lo hacemos todos los desarrolladores, así que a la mañana siguiente tenemos el repositorio lleno de bugs y en un estado caótico, y si ese mismo día necesitásemos entregar una versión, estaremos en apuros.

A continuación podéis ver el diagrama que representa esta situación:


Cada flecha es un cambio hecho en el repositorio, y como véis, algunos cambios desestabilizan el producto, bien introduciendo bugs o errores de compilación.

Para conseguir que la integración continua tenga su efecto beneficioso, tenemos que organizar el desarrollo en distintas ramas, o branches.
Para este modelo de gestión de la configuración tenemos varias opciones, aunque las más habituales son las siguientes:

Cada desarrollador tiene su propia rama de código, donde trabaja a diario, hace sus cambios, registra código, etc. Esa rama es privada, y podrá hacer lo que quiera con ella y mantenerla en cualquier estado. Lo habitual es que esa rama esté muy inestable al comenzar con una nueva tarea, y vaya ganando estabilidad conforme avance en el desarrollo.
En el momento en que el desarrollador termina con su trabajo, se compila una versión de esa rama y se pasa a pruebas. El departamente de pruebas validará la funcionalidad sobre la que ha estado trabajando el desarrollador, se reportarán los bugs oportunos, y cuando se de por correcta, se etiquetará esa rama y se integrará en el repositorio principal. En ese momento se lanza una construcción del producto de la rama principal, y se vuelve a pasar a QA el producto ya integrado, para validar que la integración ha sido correcta.
En este caso, hemos pasado a tener una funcionalidad más, reduciendo al máximo los tiempos de inestabilidad de la rama principal. Una vez que la rama principal se da por buena desde el departamento de QA, se etiqueta y se continua con la siguiente funcionalidad.
Podemos verlo representado aquí, y fijaros que la rama principal tiene muchas menos zonas en rojo:


Existe todavía otro modelo, muy parecido al anterior, y que consiste en tener una rama de desarrollo para cada nueva funcionalidad. El esquema es el mismo que hemos visto, donde los desarrolladores que trabajan en una misma funcionalidad lo hacen sobre una rama separada. La diferencia es que cuando la funcionalidad se da por terminada, se integra en la rama principal y esa rama queda muerta, teniendo que crear otra nueva para la siguientes funcionalidad.

Bien, como véis, es tema no es sencillo de gestionar, y requiere algo de infraestructura de por medio.
Yo os recomendaría que, al igual que se automatiza el proceso de construcción, intentéis hacer lo más automático posible la gestión de la configuración, teniendo scripts para la creación de ramas para desarrolladores, para funcionalidades, de integración en el principal etc.

Pero... ¿donde queda la integración continua en este jaleo de ramas? Pues en la rama principal, que es donde se registrarán los cambios definitivos y estables. No tiene sentido que intentemos compilar el producto cada vez que se cambie algo en una rama secundaria, ya que habrá muchos momento de inestabilidad. Así que cada vez que una tarea es dada por buena, se integrará en el repositorio principal y se construirá el producto final.

Y ya para poner la guinda al pastel, puedes poner un "ambient orb" en la oficina, para que todo el mundo vea el estado de la rama principal.

Automated Continuous Integration and the Ambient Orb
Using an Ambient Orb to show continuous integration build status
The Build Indicator Lamp

Nosotros no llegamos tan lejos, ¿y tú?

Etiquetas: agile, programación