Repositorios y CI/CD

Un repositorio es el almacén donde vive un proyecto junto con toda su historia: no solo la versión actual de cada fichero, sino cada cambio, quién lo hizo, cuándo y por qué. Es la pieza sobre la que se apoya el control de versiones, y también el punto de partida de todo lo automático que ocurre después.

Conviene no mezclar dos cosas que se llaman igual y guardan cosas distintas. El repositorio de código guarda el fuente y su historia. El repositorio de artefactos guarda el resultado ya compilado y empaquetado, los ficheros JAR o WAR de un proyecto Java por ejemplo, junto con las dependencias externas que hacen falta para construirlo.

Un repositorio de artefactos evita que cada máquina se descargue las dependencias de internet una y otra vez, y garantiza que todos construyan con exactamente la misma versión de cada biblioteca.

Una forja (forge) es una plataforma que aloja repositorios y añade encima todo lo que un equipo necesita para trabajar sobre ellos: gestión de incidencias, revisión de código, wiki, control de permisos y automatización. El concepto viene del mundo del software libre y de código abierto (FOSS), donde hacía falta un lugar público en el que colaborar entre desconocidos.

El flujo colaborativo típico, popularizado por GitHub, encadena dos operaciones. Con el fork se hace una copia del proyecto ajeno dentro de la propia cuenta de la plataforma, sin salir de la nube; esa copia es tuya y en ella puedes hacer lo que quieras. Después la clonas a tu equipo, trabajas y subes los cambios a tu copia.

Con el pull request (llamado merge request en GitLab) le propones al dueño del proyecto original que incorpore tus cambios. No es un comando de Git, sino una función de la plataforma: abre una página donde se ve la diferencia propuesta, se comenta línea a línea, se ejecutan automáticamente las pruebas y, si el responsable lo aprueba, se fusiona. Es el mecanismo estándar de revisión de código incluso dentro de un mismo equipo, donde no hace falta fork y basta con una rama.

El fork es tuyo y no requiere permiso de nadie; el pull request es una petición que el dueño del repositorio original puede aceptar, rechazar o pedir que se modifique.

La integración continua consiste en que cada cambio que alguien sube al repositorio se compile y se pruebe automáticamente, sin esperar a un momento de integración al final del proyecto. Así, si un cambio rompe algo, se sabe en minutos y con un solo autor sospechoso, en vez de descubrirlo semanas después mezclado con el trabajo de todos.

El servidor de integración vigila el repositorio y reacciona a cada subida. La lectura del repositorio se puede disparar de tres formas: a mano, de forma planificada a intervalos regulares, o a la escucha, avisado por el propio repositorio en cuanto entra algo nuevo.

Las dos siglas CD se distinguen por quién aprieta el botón: en entrega continua el despliegue queda preparado y lo autoriza una persona; en despliegue continuo no hay botón que apretar.

Servidores y servicios de integración continua habituales: Jenkins, que es el más veterano y el que se cita casi siempre en examen, Travis CI, CircleCI, TeamCity, Codeship, Bamboo, y las funciones integradas en las propias forjas, como GitHub Actions o GitLab CI.

Un pipeline es la secuencia de etapas automáticas por las que pasa un cambio. Cada etapa solo se ejecuta si la anterior ha terminado bien, de modo que el proceso se detiene en cuanto algo falla y nadie pierde tiempo desplegando código roto. Este es el circuito típico de un proyecto Java gestionado con Jenkins, que lleva Maven dentro para encargarse de la construcción y de las dependencias.

1. 1El servidor lee del repositorio de código (Git, Subversion o TFS) todo lo que se ha subido.
2. 2Recupera del repositorio de artefactos las dependencias externas necesarias y compila el proyecto.
3. 3Pasa el análisis de código estático, por ejemplo con SonarQube, que rechaza el cambio si no cumple el estándar de calidad acordado.
4. 4Ejecuta las pruebas unitarias con JUnit, ya con el código en ejecución, para comprobar que la funcionalidad sigue en pie.
5. 5Despliega el resultado en un servidor de aplicaciones (JBoss, WildFly, WebSphere), tarea que puede delegarse en una herramienta de automatización como Ansible.

Los cuatro primeros pasos son integración continua; el quinto es el que convierte el proceso en despliegue continuo. Es la forma más rápida de recordar dónde acaba CI y dónde empieza CD.

El paso 3 y el paso 4 se complementan y se preguntan enfrentados: el análisis estático mira el código sin ejecutarlo y detecta lo que huele mal (duplicidades, complejidad excesiva, incumplimientos del estándar), mientras que las pruebas unitarias ejecutan el código y detectan lo que se comporta mal.