# Jenkins desde cero: creación de pipelines automatizados

**Categoría:** DevOps y cloud · **Nivel:** Intermedio · **Lectura:** 10 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/devops-cloud/jenkins-desde-cero-pipelines-automatizados/

## Respuesta rápida

**Jenkins** es un servidor de automatización de código abierto, gratuito y autoalojado: se instala en tu propia infraestructura y ejecuta [pipelines de CI/CD](../como-crear-pipelines-ci-cd-con-github-actions/index.md) —construir, probar, desplegar—. Es el veterano del rubro, y su fuerza es la **extensibilidad**: miles de plugins lo conectan con casi cualquier herramienta. Su modelo tiene dos roles: el **servidor** (o *controller*) coordina y muestra la interfaz, y los **agentes** son las máquinas donde efectivamente corren los trabajos, lo que permite repartir la carga. Un pipeline moderno se define **como código** en un archivo llamado **Jenkinsfile**, versionado junto a la aplicación, dividido en *stages* (etapas) que se ven como compuertas: si una falla, el pipeline se detiene. Las credenciales se guardan en el **almacén de credenciales** de Jenkins y se referencian por su identificador, nunca escritas en el Jenkinsfile. ¿Cuándo elegirlo? Cuando necesitás control total, correr en tu propia infraestructura o integrar herramientas muy variadas. Frente a él, opciones gestionadas como [GitHub Actions](../como-crear-pipelines-ci-cd-con-github-actions/index.md) evitan mantener el servidor, a cambio de menos control.

## Qué es Jenkins y cuándo elegirlo

**Jenkins** es un servidor de automatización de código abierto que existe desde hace más de una década y sigue siendo enormemente usado. Se instala en tu propia infraestructura —un servidor, una máquina virtual, un contenedor— y desde ahí ejecuta pipelines: automatiza construir, probar y desplegar software con cada cambio.

Su gran fortaleza histórica es la **extensibilidad**: un ecosistema de miles de plugins lo conecta con prácticamente cualquier herramienta, lenguaje o servicio. Eso lo hace muy flexible, pero también implica que *vos* mantenés el servidor, los plugins y las actualizaciones.

| Situación | Jenkins (autoalojado) | Alternativa gestionada |
|---|---|---|
| Infraestructura | La ponés y mantenés vos | La provee el servicio |
| Control y personalización | Total, con plugins | Acotado a lo que ofrece |
| Mantenimiento | A tu cargo (servidor, plugins) | Casi nulo |
| Costo | Software gratis, pagás la infra y el tiempo | Según uso, sin operar servidor |
| Cuándo conviene | Control total, infra propia, casos muy específicos | Empezar rápido, integrado al repositorio |

La elección no es «cuál es mejor» sino «cuál encaja»: Jenkins brilla cuando necesitás control total o correr dentro de tu red; una [plataforma gestionada](../como-crear-pipelines-ci-cd-con-github-actions/index.md) conviene cuando querés evitar operar un servidor.

## Servidor y agentes

Jenkins separa dos roles, y entenderlo evita confusiones y problemas de seguridad:

- El **servidor** (controller) es el cerebro: muestra la interfaz web, guarda la configuración, decide qué correr y cuándo, y almacena los resultados. Por seguridad, conviene que *no* ejecute él mismo los trabajos pesados.
- Los **agentes** son las máquinas o contenedores donde efectivamente corren los trabajos. El servidor reparte el trabajo entre ellos, lo que permite correr pipelines en paralelo y tener agentes con entornos distintos (un sistema operativo concreto, ciertas herramientas).

Cada vez más, los agentes son [contenedores](../docker-desde-cero-imagenes-contenedores-y-volumenes/index.md) efímeros que se crean para un trabajo y se destruyen después, lo que da entornos limpios y reproducibles.

## El Jenkinsfile

La forma moderna de usar Jenkins es **pipeline como código**: en lugar de configurar los pasos haciendo clic en la interfaz, se escriben en un archivo llamado **Jenkinsfile**, versionado junto a la aplicación. Así el proceso de construcción queda revisado y reproducible igual que el código.

```groovy
pipeline {
  agent any
  stages {
    stage('Construir') {
      steps { sh 'npm ci && npm run build' }
    }
    stage('Probar') {
      steps { sh 'npm test' }   // si falla, se detiene todo
    }
    stage('Desplegar') {
      steps { sh './deploy.sh' }
    }
  }
}
```

El pipeline se divide en **stages** (etapas): construir, probar, desplegar. Como en cualquier [pipeline de CI/CD](../como-crear-pipelines-ci-cd-con-github-actions/index.md), cada stage es una compuerta: se ejecutan en orden y, si una falla, el pipeline se detiene y las siguientes no corren. Cada stage contiene **steps** (pasos) con los comandos concretos.

## Credenciales

Para desplegar, Jenkins necesita credenciales, y las gestiona con un **almacén de credenciales** propio. La regla es la de siempre:

> **Atención**
>
> Nunca se escriben en el Jenkinsfile, que se versiona. Se cargan en el almacén de credenciales de Jenkins, y el pipeline las usa a través de su identificador; Jenkins las inyecta en el momento de ejecutar y las **oculta en los registros** para que no queden expuestas. Es el mismo principio que en cualquier pipeline y aplicación: los secretos viven aparte, no en el código. Su tratamiento completo está en [cómo administrar secretos en pipelines y aplicaciones](../como-administrar-secretos-en-pipelines-y-aplicaciones/index.md).

Y como Jenkins es autoalojado, hay una responsabilidad extra: **mantenerlo seguro y actualizado**. El servidor y sus plugins hay que actualizarlos para no arrastrar vulnerabilidades conocidas, restringir quién puede modificar pipelines, y aislar los agentes. La comodidad del control total viene con el deber del [mantenimiento](../../linux/administracion-de-servidores-linux-desde-cero/index.md).

## Errores frecuentes

- **Configurar todo por la interfaz.** Sin Jenkinsfile versionado, el pipeline no es reproducible ni revisable.
- **Ejecutar los trabajos en el propio servidor.** Riesgo de seguridad; los trabajos van en agentes.
- **Escribir credenciales en el Jenkinsfile.** Van en el almacén de credenciales, referenciadas por identificador.
- **No actualizar Jenkins ni sus plugins.** Un servidor viejo acumula vulnerabilidades conocidas.
- **Instalar plugins sin control.** Cada plugin es superficie de ataque y deuda de mantenimiento.
- **Un pipeline que no frena ante fallos.** Si un stage falla y avanza igual, no protege nada.
- **Elegir Jenkins sin evaluar alternativas.** Si no necesitás control total, una opción gestionada ahorra mantenimiento.

## Preguntas frecuentes

**¿Qué es Jenkins y para qué se usa?**
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.

**¿Cuál es la diferencia entre el servidor y los agentes de Jenkins?**
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.

**¿Qué es un Jenkinsfile?**
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.

**¿Cuándo conviene Jenkins y cuándo una alternativa gestionada?**
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.

**¿Dónde se guardan las credenciales en Jenkins?**
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.

**¿Qué responsabilidades de seguridad implica usar Jenkins?**
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.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Sección GNU/Linux](https://underc0de.org/foro/gnu-linux/). Servidores propios, automatización y despliegue.
2. **Underc0de, foro.** [Sección Programación](https://underc0de.org/foro/programacion/). Construcción y entrega de software.

### Documentación oficial

1. **Jenkins / CD Foundation.** [Documentación oficial de Jenkins](https://www.jenkins.io/doc/). La referencia del proyecto.
2. **Jenkins.** [Pipeline](https://www.jenkins.io/doc/book/pipeline/). Cómo se definen los pipelines como código.
3. **Jenkins.** [Using a Jenkinsfile](https://www.jenkins.io/doc/book/pipeline/jenkinsfile/). Estructura, stages y credenciales.
4. **Jenkins.** [Using credentials](https://www.jenkins.io/doc/book/using/using-credentials/). Cómo se almacenan y usan los secretos.

## Guías relacionadas

- [Pipelines CI/CD con GitHub Actions](../como-crear-pipelines-ci-cd-con-github-actions/index.md)
- [Docker desde cero](../docker-desde-cero-imagenes-contenedores-y-volumenes/index.md)
- [Administrar secretos](../como-administrar-secretos-en-pipelines-y-aplicaciones/index.md)
- [Administración de servidores](../../linux/administracion-de-servidores-linux-desde-cero/index.md)
- [Índice de DevOps y cloud](../index.md)