Integración Continua en el desarrollo de software
Cómo entendemos en Brújula la Integración Continua (CI) en el desarrollo de software, qué estrategias nos han funcionado, y cómo afrontamos la implantación adaptándonos al contexto de cada empresa (incluida la nuestra).
Ya hace unos cuantos años (“un parell mallorquí” que diríamos en la isla) que implantamos el proceso de Integración Continua (CI) en todos los proyectos que desarrollamos en Brújula. En nuestro caso, entendemos el proceso de CI como lo define Martin Fowler en su artículo de 2006 [1].
“Una práctica del desarrollo de software en el que los miembros de un equipo integran su trabajo frecuentemente, al menos una vez al día, siendo lo ideal que se hagan múltiples integraciones diarias. Cada integración es verificada por un build automático (incluyendo tests) para detectar posibles errores de integración tan pronto como sea posible”
Es un requisito básico para implantar CI que se trabaje en un repositorio de código común (Git, Mercurial, Subversion, CVS), poder automatizar el build del proyecto (Gradle, Maven, Ant, NPM), poder automatizar la ejecución de los tests si se tienen (sí, todavía existen proyectos que no los tienen…) y que este proceso se ejecute en una “máquina central”. Idealmente esta máquina debe tener un entorno de ejecución similar a producción.
Pero, ¿cómo empezamos? Con Jenkins. Es lo que a nosotros nos ha funcionado. Porque es el estándar de facto en la industria para la CI y eso supone disponer de mucha documentación y soporte. Porque su funcionalidad es fácilmente ampliable a través de todos los plugins que se desarrollan. Y porque es una herramienta sencilla de utilizar y que se adapta a todos los entornos y contextos.
La implantación de una CI debe hacerse de forma gradual y teniendo claros los objetivos. Puede haber un objetivo tan simple como que exista una máquina “independiente” que en cada commit simplemente compruebe que compile el proyecto. Y si no compila que notifique al equipo enseguida (por e-mail, Slack, etc.). Este pequeño objetivo puede ahorrarnos mucho tiempo con los típicos errores de “se me olvidó subir el nuevo fichero X”. Y, una vez asentado este primer objetivo, plantearnos añadir nuevos pasos/fases a la CI:
- Ejecución de tests unitarios y de integración (siempre).
- Publicación de artefactos en un repositorio de artefactos (cuando sea necesario).
- Cálculo de métricas de calidad de software (ocasionalmente).
- Ejecución de tests funcionales end-to-end con Selenium.
A través de los Pipelines podremos customizar para que la CI se ejecute en todas las branches, o sólo en master (o trunk), o que algunos pasos sean diferentes dependiendo del “tipo” de branch.
Pero no debemos volvernos locos, porque un hecho muy importante de un buen proceso de CI es que debe ser rápido. Menos de 1 minuto si puede ser. Aunque se puede hacer complicado a medida que introduces nuevos steps en tu pipeline.
Conclusiones
Hoy en día es impensable que un proyecto de desarrollo de software no se apoye en un proceso de CI. Tanto en nuevos proyectos como en proyectos legacy, los beneficios de su implantación son muy altos. Pero es muy importante tener en cuenta al equipo y que éste entienda el objetivo. Porque si no se explican bien los beneficios, o no le aportan lo suficiente, la implantación fracasará y el equipo tenderá a funcionar como lo hacía antes de la CI. La clave del éxito es la implicación del equipo. Como casi siempre.
Joan Miralles Ramis · Arquitecto Software de Brújula · Linkedin