Jenkins desde cero: creación de pipelines automatizados

Jenkins es un servidor de automatización de código abierto, gratuito y autoalojado, que se usa principalmente para ejecutar pipelines de integración y entrega continuas, es decir, para automatizar las tareas de construir, probar y desplegar software cada vez que hay un cambio. Existe desde hace más de una década y sigue siendo muy utilizado en la industria. Su rasgo distintivo es la extensibilidad: cuenta con un ecosistema enorme de plugins que lo conectan con prácticamente cualquier lenguaje, herramienta o servicio, lo que lo hace extremadamente flexible y adaptable a flujos de trabajo muy diversos. A diferencia de las plataformas gestionadas, Jenkins se instala y corre en la propia infraestructura de quien lo usa, lo que otorga control total sobre el entorno y permite operar dentro de una red privada, pero también implica que el mantenimiento del servidor, los plugins y las actualizaciones quedan a cargo de quien lo opera.

Son los dos roles en los que Jenkins divide el trabajo. El servidor, también llamado controller, es el cerebro del sistema: muestra la interfaz web, guarda la configuración, decide qué pipelines correr y cuándo, coordina la ejecución y almacena los resultados. Los agentes son máquinas o contenedores separados, conectados al servidor, donde efectivamente se ejecutan los trabajos del pipeline. El servidor reparte el trabajo entre los agentes disponibles, lo que aporta dos beneficios importantes: permite correr muchos pipelines en paralelo distribuyendo la carga, y permite tener agentes con entornos distintos, por ejemplo con distintos sistemas operativos o conjuntos de herramientas, según lo que cada proyecto necesite. Por razones de seguridad se recomienda que el servidor no ejecute él mismo los trabajos pesados, sino que los delegue en agentes, que idealmente son entornos efímeros y aislados, muchas veces contenedores que se crean para un trabajo y se destruyen al terminar.

Es un archivo de texto en el que se define el pipeline de Jenkins como código, en lugar de configurarlo haciendo clic en la interfaz web. Se guarda versionado junto al código de la aplicación, lo que trae ventajas considerables: el proceso de construcción y despliegue queda registrado en el control de versiones, puede revisarse como cualquier otro cambio de código, y es reproducible porque la definición viaja con el proyecto. Dentro del Jenkinsfile, el pipeline se organiza en etapas llamadas stages —típicamente construir, probar y desplegar— que se ejecutan en orden y funcionan como compuertas: si una etapa falla, el pipeline se detiene y las siguientes no se ejecutan, de modo que un problema en la construcción o en las pruebas impide llegar al despliegue. Cada etapa contiene pasos concretos con los comandos a ejecutar. Definir el pipeline como código es hoy la práctica recomendada frente a la configuración manual por la interfaz, que no queda versionada ni es fácilmente reproducible.

La decisión depende de las necesidades y no de cuál sea objetivamente mejor. Jenkins conviene cuando se necesita control total sobre el entorno de automatización, cuando hay que correr dentro de la propia infraestructura o de una red privada por razones de seguridad o cumplimiento, o cuando se requieren integraciones muy específicas que se resuelven con su enorme catálogo de plugins. A cambio de esa flexibilidad, hay que hacerse cargo de instalar, operar, asegurar y actualizar el servidor y sus plugins. Una alternativa gestionada e integrada en el repositorio, como GitHub Actions, conviene cuando se quiere empezar rápido sin montar ni mantener un servidor, cuando el flujo de trabajo encaja con lo que la plataforma ofrece, y cuando se prefiere delegar la infraestructura a cambio de menos control y personalización. Muchas organizaciones incluso combinan ambos enfoques según el proyecto. La regla sana es evaluar honestamente cuánto control se necesita de verdad frente a cuánto mantenimiento se está dispuesto a asumir.

Jenkins tiene un almacén de credenciales propio pensado justamente para esto, donde se cargan las contraseñas, claves y tokens que los pipelines necesitan para construir y desplegar. Dentro del Jenkinsfile esas credenciales se referencian únicamente por un identificador, y Jenkins se encarga de inyectar el valor real en el momento de la ejecución y de ocultarlo en los registros para que no quede expuesto. Lo que nunca hay que hacer es escribir las credenciales directamente en el Jenkinsfile, porque este se versiona junto al código y cualquier secreto escrito ahí quedaría a la vista de quien tenga acceso al repositorio. Es exactamente la misma regla que rige en cualquier pipeline, imagen de contenedor o código fuente: los secretos viven en un mecanismo aparte diseñado para protegerlos y se referencian o inyectan, nunca se incrustan en lo que se versiona. Conviene además restringir quién puede ver y usar cada credencial dentro de Jenkins mediante sus controles de acceso.

Al ser autoalojado, Jenkins traslada a quien lo opera la responsabilidad de mantener seguro tanto el servidor como su entorno, algo que las plataformas gestionadas resuelven por su cuenta. Las obligaciones principales son varias. Mantener actualizado el servidor y, muy especialmente, sus plugins, porque un Jenkins viejo acumula vulnerabilidades conocidas que se vuelven una puerta de entrada. Instalar solo los plugins realmente necesarios, ya que cada uno añade superficie de ataque y deuda de mantenimiento. Restringir quién puede crear o modificar pipelines y quién puede acceder a las credenciales, mediante los controles de acceso que Jenkins ofrece. Aislar los agentes y evitar que el servidor ejecute directamente trabajos que podrían comprometerlo. Y proteger el acceso a la interfaz web con autenticación sólida. En definitiva, la contrapartida de la comodidad del control total es el deber constante de administrar y endurecer el servidor, que forma parte de las tareas habituales de administración de sistemas.