CI/CD en 2026: cuándo usar Jenkins, GitHub Actions, GitLab CI, Argo CD y Tekton
Cuando se habla de CI/CD, Jenkins, GitHub Actions, GitLab CI, Argo CD y Tekton suelen acabar en la misma tabla comparativa. Como primera orientación puede servir, pero en 2026 esa tabla también puede confundir. Algunas herramientas resuelven builds y pruebas cerca del repositorio. Otras gestionan despliegues en Kubernetes. Otras son bloques para construir una plataforma interna de entrega.
Por eso la pregunta “¿cuál elegimos?” suele estar mal planteada. Primero hay que entender el modelo operativo, no la marca: ¿necesitas CI integrado en tu proveedor Git, GitOps CD para un clúster, un motor de pipelines nativo de Kubernetes o un sistema que ha sobrevivido más de una década de automatización enterprise y sigue funcionando en muchas empresas? Solo después tiene sentido elegir el producto.
¿Jenkins está muriendo?
Si miramos Jenkins como un sistema enterprise ya instalado, la respuesta es no: no está muriendo. La documentación oficial de Jenkins sigue girando alrededor de controllers, agents, labels y ejecución distribuida de jobs. Ese modelo todavía funciona donde hay redes cerradas, laboratorios de hardware, code signing, toolchains poco comunes y años de pipelines acumulados. (Jenkins)
Pero como elección desde cero en 2026, Jenkins casi siempre se ve más débil que las plataformas de CI ya integradas en el proceso de desarrollo. No porque haya “dejado de ejecutar builds”, sino porque junto con un Jenkinsfile llega también un producto separado que hay que actualizar, respaldar, proteger, limpiar de plugins innecesarios y mantener sano. Donde GitHub Actions y GitLab CI ya forman parte del desarrollo diario, Jenkins para un equipo nuevo suele sentirse menos como un acelerador y más como otra capa de operación.
Jenkins X es un buen marcador de esta época. En marzo de 2026, el proyecto escribió directamente que el nombre Jenkins se había convertido en una carga de marketing: atraía a personas que esperaban el Jenkins clásico y alejaba a quienes buscaban una alternativa. El proyecto pasó a llamarse JayeX, y las integraciones restantes con Jenkins fueron marcadas como deprecated. Eso ya no es “el futuro de Jenkins”, sino una rama evolutiva independiente. (JayeX)
Mi versión corta es esta: Jenkins no está muerto como base instalada, pero sí está muerto como elección por defecto para proyectos nuevos. Los equipos lo eligen no porque sea la mejor opción en 2026, sino porque a veces el coste de migrar es mayor que el dolor de quedarse.
GitHub Actions
GitHub Actions encaja mejor con los equipos cuyo código, pull requests, code review y proceso de release ya viven en GitHub. La fuerza de Actions no está en YAML como tal, sino en su cercanía al repositorio: los workflows viven junto al código, los estados vuelven directamente al PR, secrets y environments forman parte de la plataforma, y el ecosistema de actions listas para usar cubre casi todas las tareas habituales.
En 2026, GitHub sigue invirtiendo en este modelo. La compañía dice que movió todos los jobs a una nueva arquitectura diseñada para decenas de millones de jobs al día y, al mismo tiempo, redujo los precios de los GitHub-hosted runners desde el 1 de enero de 2026. Para los hosted runners estándar, los precios quedan así: Linux 1-core cuesta $0.002/min, Linux 2-core $0.006/min, Windows 2-core $0.010/min y macOS $0.062/min. Para repositorios públicos, los hosted runners estándar siguen siendo gratuitos; para repositorios privados existe una cuota de minutos incluida según el plan. (GitHub, GitHub, GitHub)
La historia más reveladora de 2026 no va de hosted runners, sino de self-hosted runners. GitHub primero anunció un cargo separado de $0.002/min como cloud platform charge para self-hosted runners, y después pospuso ese modelo tras una reacción negativa de los usuarios. La señal es importante: en el ecosistema GitHub, los self-hosted runners ya no deberían verse como “una forma gratuita para siempre de ejecutar Actions en nuestro propio hardware”. La plataforma se mueve claramente hacia monetizar no solo el compute, sino también el control plane que lo rodea. (GitHub)
GitHub Actions es el mejor valor por defecto si tu equipo ya vive en GitHub y no está construyendo una función separada de platform engineering. Su debilidad también es clara: junto con la comodidad aceptas un lock-in fuerte a GitHub como centro del proceso de ingeniería.
GitLab CI
GitLab CI rara vez gana por ser “el CI más de moda”, pero muy a menudo gana por ser el producto más completo. Si GitHub Actions es fuerte por su cercanía al flujo de pull requests, GitLab CI es fuerte porque vive dentro de una plataforma SDLC más amplia: source code, merge requests, registry, security scans, environments, runners y mecanismos de governance en una misma capa.
La economía del hosted usage en GitLab es especialmente explícita. En GitLab.com, el uso de compute se calcula con la fórmula job duration / 60 * cost factor, y el cost factor depende del tipo de runner y del tamaño de la máquina. Para Linux x86-64 small, el factor es 1; en máquinas más grandes aumenta, y los runners de macOS y GPU tienen multiplicadores bastante más altos. El Free tier de GitLab.com incluye 400 compute minutes al mes, y otros 1000 minutos cuestan $10. También puedes traer tus propios runners, y su uso no consume la cuota de shared runners. (GitLab, GitLab, GitLab)
La conclusión práctica es sencilla. Si el equipo ya está en GitLab, salir de ahí solo por un CI “más moderno” normalmente no tiene sentido. GitLab CI es especialmente bueno cuando importan un modelo de governance unificado, group runners y un perímetro administrativo predecible. Pero si una empresa no usa GitLab como plataforma principal de desarrollo, adoptar todo el stack solo por CI/CD no siempre es racional.
Argo CD
Argo CD pertenece a una capa distinta de GitHub Actions y GitLab CI. Oficialmente es una declarative GitOps continuous delivery tool for Kubernetes. Es decir, Argo CD no responde a la pregunta “¿dónde ejecutamos pruebas y builds?”, sino a “¿cómo converge el clúster hacia el estado descrito en Git?”. (Argo CD)
Esto se ve incluso en la documentación sobre automation from CI pipelines. El flujo recomendado es: CI construye y publica una imagen de contenedor, luego actualiza manifests en Git, y solo después Argo CD sincroniza el clúster con el estado deseado. Si la aplicación tiene automated sync activado, un paso imperativo de deploy dentro del CI deja incluso de ser necesario. (Argo CD)
Por eso Argo CD no reemplaza al CI; vive junto a él. Da a los equipos un proceso GitOps auditable, mejor manejo de múltiples clústeres, separación entre el repositorio de la aplicación y el de configuración, y rollbacks más predecibles a través del historial de Git. Pero si despliegas un único servicio en un VPS con docker compose, añadir Argo CD no es modernidad: es complejidad extra.
Tekton
Tekton vuelve a ser otra clase de sistema. La documentación oficial lo describe como una cloud-native solution for building CI/CD pipelines que se instala como una extensión de Kubernetes y utiliza Custom Resources como bloques básicos de los pipelines. Tekton no es simplemente “otro CI”; es una capa nativa de Kubernetes para construir tu propia plataforma de entrega. (Tekton)
Por eso Tekton encaja especialmente bien con platform engineering. En su terminología aparecen Tasks, Pipelines, Triggers, Chains, catálogos de componentes reutilizables y una línea fuerte de seguridad de la cadena de suministro. En marzo de 2026, Tekton pasó a ser un proyecto CNCF Incubating, lo que lo posiciona como un building block cloud-native maduro y no como un experimento de nicho. (Tekton, CNCF)
Pero todo eso tiene un coste. Tekton funciona bien cuando Kubernetes ya es tu plataforma interna y existe un equipo preparado para operar no solo las aplicaciones, sino también la propia capa de entrega. Para un equipo de producto pequeño, Tekton no suele ser “libertad”; suele ser construir demasiado pronto un PaaS interno.
Self-hosted runners
Los self-hosted runners en 2026 no son útiles porque sean “más baratos por definición”. Son útiles cuando hay escenarios claros: los builds necesitan acceso a una red privada, artefactos internos, toolchains poco comunes, GPU, Arm, HSM/code signing, cachés grandes o un control más estricto sobre datos y latencia.
Pero los self-hosted runners casi siempre se subestiman. En cuanto sales de la ejecución gestionada, aparece una mini-plataforma: autoscaling, colas, actualizaciones de imágenes, parches del sistema operativo, secrets, aislamiento entre jobs, observabilidad, investigación de fallos y capacity planning. En su comunicación de 2026, GitHub dice explícitamente que está invirtiendo en ARC, Scale Set Client, observability y otras capacidades enterprise alrededor de la experiencia self-hosted. Es un buen recordatorio de que una flota de runners es un producto real, no un complemento gratuito del CI. (GitHub)
La regla es simple: elige self-hosted runners por requisitos de seguridad, red o rendimiento. No los elijas solo porque el equipo romantiza “nuestro propio hardware” o quiere ahorrar unos miles de hosted minutes sin calcular el coste operativo.
Qué CI/CD elegir en 2026
Para la mayoría de los equipos, la decisión se vuelve más sencilla si primero se define el modelo operativo y después la herramienta.
| Escenario | Qué elegir | Por qué |
|---|---|---|
| Equipo pequeño, todo el código y review en GitHub | GitHub Actions | El camino más corto del commit a production sin una plataforma separada |
| Equipo que ya vive en GitLab y quiere un stack SDLC unificado | GitLab CI | Source, CI, registry, governance y runners en un solo producto |
| Plataforma Kubernetes con proceso GitOps | GitHub Actions o GitLab CI + Argo CD | CI construye artefactos, Argo CD hace declarative delivery |
| Equipo interno de plataforma que construye su propia capa de entrega sobre Kubernetes | Tekton | Da primitivas y bloques reutilizables, no solo una UI de pipelines ya hecha |
| Organización legacy grande con cientos de jobs e integraciones especiales | Jenkins | El dolor de migrar puede ser mayor que el beneficio de moverse |
Si necesitas una recomendación corta y sin demasiados matices, es esta: en 2026, Jenkins no es la elección por defecto para un equipo nuevo. Normalmente será GitHub Actions o GitLab CI. Argo CD se añade cuando ya tienes Kubernetes y necesitas GitOps CD. Tekton se añade cuando estás construyendo una plataforma interna. Jenkins se queda donde la historia de la empresa ya está profundamente conectada con su modelo.
Conclusión corta
CI/CD en 2026 ya no es un mercado donde una sola herramienta tenga que “hacerlo todo”. En la práctica, los equipos eligen entre distintas capas del delivery stack: CI cerca de Git, despliegue GitOps para Kubernetes y primitivas de plataforma para un sistema interno de ingeniería.
Por eso la pregunta “¿Jenkins o Argo CD?” normalmente significa que el equipo aún no ha separado CI y CD por capas. Jenkins, GitHub Actions y GitLab CI ejecutan automatización. Argo CD vive junto a ellos como Kubernetes CD. Tekton aparece con más frecuencia en la arquitectura de una plataforma interna que en un equipo de producto de cinco personas.
Dicho de forma directa: Jenkins como elección por defecto está muerto. Jenkins como enorme base instalada seguirá vivo durante mucho tiempo. GitHub Actions encaja de forma natural con equipos centrados en GitHub, GitLab CI es fuerte como plataforma unificada, Argo CD se ha convertido en la respuesta estándar para despliegues GitOps en Kubernetes, y Tekton es para equipos que quieren construir su propio motor de entrega en lugar de simplemente ejecutar un pipeline.
El error más caro no es elegir “la marca equivocada”; es elegir una herramienta de la clase equivocada. Cuando un equipo necesita CI normal cerca del repositorio, no necesita Tekton. Cuando necesita GitOps CD para un clúster, no necesita Jenkins en lugar de Argo CD. Y cuando necesita un proceso de entrega rápido y funcional, rara vez necesita un zoológico separado que tendrá que mantener durante más tiempo que su propio producto.