Jenkins en 2026: cuándo conservarlo y cuándo migrar

Todo equipo de plataforma tiene una opinión sobre Jenkins y casi ninguno tiene los números. La opinión suele ser "deberíamos salir de aquí". Los números suelen decir algo más aburrido: el controlador lleva tres años sin actualizarse, la mitad de los jobs se configuraron a mano en la interfaz por gente que ya no está, y nadie sabe cuáles de los 400 jobs siguen importando.

Eso no es un problema de Jenkins. Es lo que le pasa a cualquier sistema de CI que no tiene dueño. La decisión de conservar o migrar debería venir después de saber cuál de los dos tienes.

En qué sigue siendo bueno Jenkins

Jenkins es un ejecutor de tareas de propósito general con 1.900 plugins que resulta que se usa para CI. Esa generalidad es la razón de que sobreviva donde las alternativas gestionadas no encajan:

• Compilaciones que necesitan máquinas reales. Pruebas con hardware en el lazo, compilaciones contra cadenas de herramientas con licencia atada a un equipo físico, cualquier cosa con una llave USB o una red de laboratorio. Jenkins pone un agente ahí y no hace preguntas.
• Redes aisladas o muy reguladas. Sin salida a internet, sin plano de control SaaS, todo el sistema dentro de tu perímetro y con las trazas de auditoría en tu poder.
• Orquestación que en realidad no es CI. Procesos de datos nocturnos, trenes de release, coreografía entre repositorios. Muchos "jobs de Jenkins" son un cron con interfaz y registro de auditoría, y sustituirlos por un producto de CI es forzar la forma.

Si tu Jenkins hace sobre todo una de esas cosas, migrar te aporta poco y te cuesta un trimestre.

En qué es malo, sin adornos

• Coste por minuto de compilación cuando hay mucho ocioso. Un controlador encendido siempre más una flota de agentes estáticos ocupados el 8 por ciento del día es el desperdicio de CI más común que encontramos. Tiene arreglo (abajo), pero no es lo que viene por defecto.
• Deriva de configuración. Lo que se configura en la interfaz existe en un solo sitio, en un solo disco, y es invisible a la revisión de código. Esta es la causa real de la mayoría de quejas de "Jenkins es frágil".
• Cadena de suministro de plugins. El ecosistema de plugins es el superpoder de Jenkins y su principal pasivo de seguridad. Cada plugin corre con privilegios del controlador, y un controlador con cien plugins tiene cien caminos de actualización capaces de romper el arranque.
• Experiencia de desarrollo. A nadie le gusta leer un Jenkinsfile de 600 líneas que llama a una biblioteca compartida que invoca un script Groovy. Los colaboradores evitan tocar CI, y entonces CI deja de mejorar.

La prueba de los tres números

Antes de decidir nada, consigue estos:

Jobs realmente ejecutados en los últimos 90 días. Desde el controlador:

// Administrar Jenkins > Consola de scripts
Jenkins.instance.getAllItems(Job.class).each { j ->
  def b = j.getLastBuild()
  println "${j.fullName}\t${b ? b.getTime() : 'nunca'}\t${j.builds.size()}"
}

La respuesta típica es que entre el 20 y el 30 por ciento de los jobs han corrido este trimestre. El resto es inventario, no carga de trabajo, y no cuenta para el coste de migración.

Utilización de agentes. Minutos de ejecutor ocupados entre minutos de ejecutor aprovisionados. Por debajo del 15 por ciento significa que pagas máquinas ociosas y la victoria más rápida son agentes efímeros, no una migración.

Tiempo de commit a artefacto desplegable, p50 y p95. Si el p95 es más del triple del p50, tu problema es de colas o de tests inestables, y ninguno de los dos se arregla cambiando de proveedor de CI.

La decisión

Conserva Jenkins e invierte en él si: los jobs activos no llegan a unos cientos, la mayor parte ya está en Jenkinsfile dentro de los repositorios y tienes al menos una persona que se hará cargo del controlador. La inversión es configuración como código, agentes efímeros y bibliotecas compartidas: entre dos y cuatro semanas de trabajo que abaratan los siguientes cinco años.

Migra si: tus compilaciones son construcciones de contenedores normales sobre Linux, tu código ya está en GitHub o GitLab y el controlador se ha convertido en un punto único de fallo que nadie quiere tocar. El destino suele ser GitHub Actions o GitLab CI, y el coste honesto es una persona durante seis a diez semanas para un entorno mediano, la mayor parte gastada en secretos, credenciales y los veinte jobs que hacen algo raro.

Haz las dos cosas si el entorno está partido: migra las compilaciones de contenedor normales y deja un Jenkins pequeño para el hardware y la orquestación nocturna. Tener dos sistemas de CI no es un fracaso si la frontera es explícita y cada lado tiene dueño.

No migres para huir de un problema que te llevas contigo

El modo de fallo que más vemos: un equipo migra de Jenkins a Actions para arreglar una compilación de 45 minutos y acaba con una compilación de 45 minutos sobre otra infraestructura, más un trimestre de migración y una factura nueva. La compilación era lenta porque la suite de tests no tiene paralelismo ni caché, y eso viajó con ella.

Arregla la duración del pipeline donde vive ahora, en el sistema que ya tienes. Si el resultado es rápido, el argumento para migrar se debilita y la migración en sí se vuelve mucho más fácil. Si sigue lento, al menos ya sabes que la causa no era el motor de CI.