CI/CD con Git: 5 consejos para repositorios de Git compatibles con CI

Un sistema de almacenamiento externo como Artifactory (que tiene un complemento para Bamboo), Nexus o Archiva puede ser útil para los artefactos generados por tu equipo o por otros equipos. Los archivos necesarios pueden introducirse en el directorio de compilación al principio de la compilación, como pasa con las bibliotecas de terceros que introduces con Maven o Gradle.

Si aún no dispones de un sistema de almacenamiento externo en tu red, te resultará más fácil aprovechar la compatibilidad con archivos grandes (LFS) de Git.

Git LSF es una extensión que almacena punteros en archivos grandes en tu repositorio, en lugar de almacenar los archivos en sí. Dichos archivos se almacenan en un servidor remoto. Como supondrás, esto reduce significativamente el tiempo de clonación.

Es probable que ya tengas acceso a LFS de Git, ya que tanto Bitbucket como GitHub lo admiten.

Pero digamos que tu compilación requiere el historial completo del repositorio; si, por ejemplo, uno de los pasos de tu compilación actualiza el número de versión en tu POM (o algo parecido), o si fusionas dos ramas con cada compilación. Para ambos casos, Bamboo debe volver a implementar cambios en tu repositorio.

Con Git, se pueden hacer cambios sencillos en los archivos (como actualizar un número de versión) sin necesidad de contar con el historial completo. Sin embargo, para la fusión sigue siendo necesario el historial del repositorio, ya que Git necesita retroceder y encontrar el antepasado común de las dos ramas, lo que supone un problema si la compilación usa la clonación superficial. Esto me lleva al tercer consejo.

Esto también agiliza el proceso de clonado; de hecho, Bamboo lo hace de forma predeterminada.

Ten en cuenta que el almacenamiento en caché del repositorio solo te beneficia a ti si usas agentes persistentes entre compilaciones. Si creas y destruyes agentes de compilación en EC2 u otro proveedor de servicios en la nube cada vez que se ejecuta una compilación, el almacenamiento en caché del repositorio dejará de tener sentido, ya que estarás trabajando con un directorio de compilaciones vacío y tendrás que incorporar una copia completa del repositorio cada vez.

Los clones superficiales más el almacenamiento en caché del repositorio, dividido entre agentes persistentes frente a agentes extensibles, da como resultado una interesante red de factores. Aquí tienes una pequeña base para ayudarte a elaborar tus estrategias.

Casi no hace falta decir que ejecutar la integración continua en todas las ramas activas es una buena idea. Pero ¿también es buena idea ejecutar todas las compilaciones en todas las ramas para todas las confirmaciones? Probablemente, no. Aquí te explicamos por qué.

Veamos, por ejemplo, el caso de Atlassian. Contamos con más de 800 desarrolladores, cada uno de los cuales introduce cambios en el repositorio varias veces al día, principalmente a sus ramas de función. Eso son muchas compilaciones, lo que supone mucho tiempo de espera en la cola a menos que escales tus agentes de compilación de forma instantánea e infinita.

Uno de nuestros servidores internos de Bamboo alberga 935 planes de compilación distintos. Conectamos 141 agentes de compilación a este servidor y seguimos las prácticas recomendadas, como la aprobación de artefactos y la paralelización de pruebas, para que cada compilación fuera lo más eficiente posible. Aun así, las compilaciones después de cada envío generaban cuellos de botella.

En lugar de configurar otra instancia de Bamboo con más de 100 agentes adicionales, hemos dado un paso atrás y nos hemos preguntado si de verdad era necesario. Y la respuesta ha sido que no.

De este modo, ofrecimos a los desarrolladores la opción de crear sus compilaciones de ramas con pulsador, en lugar activarlas siempre automáticamente. Es una buena forma de hacer balance del rigor de las pruebas con la conservación de recursos, y las ramas es donde se produce la mayor parte de la actividad, de modo que hay una gran oportunidad para ahorrar.

A muchos desarrolladores les gusta el control adicional que ofrecen las compilaciones mediante pulsador, y ven que se ajusta forma natural en su workflow. Otros prefieren no pensar sobre cuándo ejecutar una compilación, y se ciñen a los activadores automatizados. Cualquier enfoque puede funcionar. Lo importante es someter las ramas a pruebas y garantizar que cuentas con una compilación limpia antes de realizar una fusión más adelante.

Las ramas críticas, como la principal y las de versión estable, son otra historia. En ellas, las compilaciones se activan de forma automática, ya sea buscando cambios en el repositorio o enviando una notificación de envío de Bitbucket a Bamboo. Como utilizamos ramas de desarrollo para todo nuestro trabajo en progreso, las únicas confirmaciones en la rama principal deben ser (en teoría) ramas de desarrollo que se fusionan. Además, estas son las líneas de código desde las que lanzamos y creamos nuestras ramas de desarrollo. Por eso es tan importante que obtengamos los resultados de las pruebas a tiempo en cada fusión.

Sondear tu repositorio cada pocos minutos en busca de cambios es pan comido para Bamboo. Pero si tienes cientos de compilaciones en miles de ramas con decenas de repositorios, todo se va acumulando rápidamente. En lugar de sobrecargar Bamboo con todos esos sondeos, puedes configurar Bitbucket para que indique cuándo se ha enviado un cambio y se requiere una compilación.

Normalmente, esto se consigue añadiendo un hook al repositorio, aunque en este caso la integración entre Bitbucket y Bamboo se encarga de toda la configuración por ti. Una vez vinculados en el back-end, las compilaciones basadas en el repositorio activan Just Work™ para que esté listo para usar, sin hooks ni configuraciones especiales.

Independientemente de las herramientas, los desencadenadores basados en el repositorio tienen la ventaja de que desaparecen automáticamente cuando la rama de destino se vuelve inactiva. Esto quiere decir que nunca malgastarás ciclos de CPU en los sistemas de CI sondeando cientos de ramas abandonadas ni perderás tiempo desactivando manualmente las compilaciones de rama. (Si prefieres seguir con los sondeos, vale la pena señalar que Bamboo se puede configurar fácilmente para que ignore las ramas después de un número determinado de días de inactividad).