"Practicando" la Integración Continua (IC)

Después de invertir un tiempo considerable en su configuración disponemos de máquinas de Build que son capaces de compilar el código de nuestros proyectos, tenemos definiciones de compilación en diferentes formatos (integración continua, programadas, incrementales) y hemos adoptado la buena práctica de únicamente desplegar en producción las carpetas de despliegue generadas por estas máquinas.

De por sí, el hecho de disponer de esta infraestructura y configuración nos reporta las siguientes ventajas:

• Nos aseguramos, mediante la ejecución programada, que todos nuestros proyectos compilan en un entorno diferente del entorno de desarrollo.
• Eliminamos las dependencias sobre determinados equipos de desarrollo que únicamente podían ser utilizados para subir a producción proyectos específicos, porque sólo compilaban en ese equipo.
• Dejamos de escuchar la frase: "Es preferible esperar a que vuelva tal persona porque es el único que sabe cómo compilar este proyecto".
• Las pruebas de aceptación se ejecutan diariamente garantizando (hasta donde son capaces) que el cambio en diferentes infraestructuras no afecta a nuestros proyectos.

Sólo por lo anteriormente expuesto merece la pena la inversión en hardware y horas de configuración del entorno, pero esto no tiene nada que ver con la Integración Continua, de ahí el título: "Practicando" la Integración Continua (IC). Y es que la Integración Continua es una práctica que va mucho más allá de disponer de máquinas de compilación. En Gestión Ágil de Proyectos Software [1] se explica con un buen nivel de detalle un ciclo genérico de integración, que de hecho, se puede adaptar a un elevado porcentaje de proyectos:

1. El desarrollador sube los cambios a control de código fuente (después de verificar que sus cambios son válidos).
2. La máquina de compilación, al recibir los cambios, recupera la última versión del código fuente, compila, lanza las pruebas, despliega, etc.
3. Si algo no va bien en el proceso anterior avisa inmediatamente al desarrollador/equipo.
4. Se calculan métricas de calidad.
5. Se publican los resultados en el portal de proyecto.

El ciclo anterior comienza en "El desarrollador" y es ahí donde está el principal reto. El resto de ciclo se puede solucionar mediante la automatización (con una buena configuración del entorno) pero para obtener realmente las ventajas de la IC es necesario incorporarla como práctica habitual en nuestro proceso de desarrollo. Para ello, basándonos principalmente en Continuous Delivery [2] hemos definido el siguiente conjunto de reglas a seguir (es el subconjunto que más encaja en nuestros proyectos, pero allí podrás encontrar otras interesantes, por ejemplo, para equipos distribuidos):

• Proteger el código con la mayor frecuencia posible. Obviamente esto no quiere decir que se deba proteger cada línea de código pero debemos acostumbrarnos a hacerlo tan pronto nos sea posible. En lugar de trabajar varios días sobre una parte de código y protegerlo al final es preferible realizar protecciones intermedias. 
• No proteger sobre Builds rotas. Si nos acostumbramos a que una Build esté rota y no se soluciona, sino que seguimos protegiendo código la costumbre se convierte en rutina, y finalmente pasa mucho tiempo hasta que algún miembro del equipo para su trabajo habitual y decide arreglarla. Al final, en lugar de arreglar un pequeño cambio de código tenemos que solucionar los problemas derivados de, probablemente, roturas en cadena.
• Ejecutar siempre los test en local antes de proteger. Como regla básica, antes de proteger código nos debemos asegurar de que todos los test del proyecto quedan en verde, es posible que aunque pasen en local posteriormente en la máquina de Build queden en rojo pero el porcentaje de casos será menor y podremos enfatizar este hecho.
• No dejar una Build rota antes de irse a casa. Si protegemos justo al finalizar el día deberemos esperar el resultado de la Build de IC antes de irnos. Si la Build se rompe hay dos opciones:
• A. Solucionar el problema y arreglar la Build. Si es fácil será la mejor opción pero hay que tener en cuenta que en ocasiones puede llevar tiempo...y tal vez estamos a punto de salir.
• B. Deshacer los cambios realizados y dejar el código bajo control de código fuente operativo como estaba antes. Como la primera regla implicaba no proteger sobre Builds rotas... la versión anterior debe funcionar.
• En ningún caso optar por la posible opción C. Dejar el código fuente que rompe la Build bajo control de código fuente e irnos a casa confiando en solucionarlo al día siguiente. Esto provocará que la Build nocturna falle (ocasionando una alarma innecesaria) y puede tener mayores repercusiones si por cualquier razón al día siguiente no podemos asistir al trabajo.
• Establecer un tiempo máximo para solucionar la Build. En proyectos grandes con varias personas trabajando sería interesante acordar un tiempo máximo para poder solucionar una Build, por ejemplo 15 minutos. Si no consigo solucionarlo en ese tiempo…será mejor revertir los cambios y solucionarlo en local para dejar la Build operativa.
• No comentar test que no pasan. Aunque es muy tentativo comentar test que no pasan para no romper la Build es muy mala práctica. Nos acabamos acostumbrando a que determinado proyecto tiene un test en rojo…y como hace ya tanto tiempo que está en rojo ni nos sorprende. Ante un test en rojo se deberá:
• Solucionar el test. Es posible que la lógica de negocio que valida esté obsoleta y el fallo no sea real.
• Modificar la lógica de negocio que hace fallar al test.
• Eliminar el test si consideramos que han dejado de tener sentido ante un cambio en el negocio.
• En muy limitadas ocasiones puede estar justificado comentar un test para evitar una rotura…el pretender definir estos casos no parece muy rentable por lo que propongo que ésta sea una decisión de consenso del grupo.
• Romper la Build en caso de Warnings de compilación o Alertas de análisis estático de código. Esto es realmente complicado en proyectos que tienen una base de código importante, puesto que bajar a cero-Alertas puede ser una labor titánica (y en ocasiones arriesgada), pero al menos en proyectos nuevos o aquellos en que hemos conseguido cero-Alertas debemos hacer un esfuerzo en mantener este compromiso (de ahí dejarlo como regla y no automatizarlo con el resto del ciclo). 

REFERENCIAS:

[1] Gestión Ágil de Proyectos Software,  Javier Garzas, Juan Enriquez de S. y Emanuel Irrazábal.

[2] Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Jez Humble y David Farley