DevOps: ¿qué es CI/CD?

CI/CD no es un producto. Es el hábito de integrar, probar y desplegar software en ciclo corto, con el máximo de pasos automáticos. El “día del merge” de 2019 sigue siendo el antipatrón. Lo que cambió es dónde mora el YAML, quién ejecuta el job y qué ocurre después que el pipeline se queda en verde.

CI, entrega e implantación — los tres CDs

CI (integración continua): cada push o merge request se convierte en build y test automáticos sobre el tronco compartido. El conflicto aparece hoy, no el viernes del release.

Entrega continua: el artefacto aprobado (binario, imagen OCI, paquete) va por sí solo a un registro y queda listo para producción. La subida todavía depende de un humano pulsando el botón — o de un criterio: tag, aprobación, ventana de cambio.

Implantación continua: el mismo artefacto sube solo a producción si las pruebas han pasado. El feedback del usuario llega en minutos. Exige pruebas en las que realmente confías, no un job verde vacío.

No vale la pena pelear por el acrónimo. Vale la pena diseñar el pipeline: qué es automático, qué es puerta y cómo se hace el rollback.

El pipeline en 2026: YAML en Git

Jenkins con plugins todavía ejecuta mucho legado. El punto de partida en Linux hoy es un archivo en el repositorio, un runner en contenedor y el artefacto en un registry.

GitHub Actions — el estándar de quien ya está en GitHub. Fija cada action por SHA del commit, no por etiqueta flotante: en marzo de 2025 las etiquetas de la action tj-actions/changed-files fueron reasignadas a un commit malicioso que volcaba secrets en los logs (CVE-2025-30066). Quien las usaba @v45 ejecutó el código del atacante; quien había fijado el SHA, no.

# .github/workflows/ci.yml
name: ci
on:
  pull_request:
  push:
    branches: [main]
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - run: make test

El bloque permissions reduce el token del job al mínimo necesario — sin él, el valor por defecto puede ser más amplio de lo que la prueba necesita.

GitLab CI — algo que la entrada hermana de 2019 ya usaba para Terraform. Un .gitlab-ci.yml y runners propios, si quieres soberanía:

# .gitlab-ci.yml
stages: [test, image]

test:
  stage: test
  image: golang:1.27
  script:
    - go test ./...

image:
  stage: image
  image: docker:29
  services: [docker:29-dind]
  script:
    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"
    - docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Las variables CI_REGISTRY* las rellena el propio GitLab para el registro del proyecto: ninguna contraseña queda escrita en el YAML.

Forgejo Actions / Gitea Actions — sintaxis compatible en buena parte con GitHub Actions, ejecutándose de forma autoalojada, sin enviar el código a la nube ajena. El paso a paso con el runner está en el post sobre Gitea con Actions y runner. Woodpecker es la otra opción ligera. En el homelab Linux, esto compite con GitLab CE.

O curso de Docker sigue siendo un prerrequisito: el job moderno é un contenedor. La infraestructura como código sigue el mismo espíritu: Ansible y el pipeline de Terraform en GitLab.

CD se convirtió en GitOps

Desplegar en Kubernetes en 2026 rara vez está kubectl apply dentro del job de CI. El CI construye la imagen, la firma, la envía al registry y actualiza el Git (tag o digest). El cluster extrae el estado deseado:

• Argo CD — aplicaciones declaradas en Git, detección de drift y sincronización. La línea 3.5 (2026) trajo mTLS en el repo-server y una verificación opcional, todavía en alpha, de la integridad de las fuentes en el hydrator.
• Flux — el otro proyecto graduado de la CNCF para GitOps, con controllers dentro del cluster.

Git pasa a ser la fuente de la verdad. El runner deja de tener credenciales de producción eternas: OIDC para la nube, tokens de corta duración y admission en el cluster verificando la firma (Cosign) antes de que el pod se levante. Quien todavía lo hace docker compose up en un VPS vía SSH (como en Vaultwarden) está en el escalón de la entrega continua — válido, simplemente no es GitOps. Para el contexto de dónde vinieron las piezas, vea la historia de Docker e la de Kubernetes.

El pipeline como objetivo

En 2019 el miedo era el merge roto. En 2026 el miedo es el job que pasa y publica malware: action comprometida, paquete npm secuestrado, secret filtrando en el log.

• Fije actions e imágenes por SHA o digest, nunca por @v3 suelto.
• Secrets en la bóveda (GitHub/GitLab, Vault, SOPS) — nunca en el YAML.
• Token del job con el mínimo de permisos (permissions: en Actions).
• SBOM y firma con Cosign (Sigstore, keyless vía OIDC) en la imagen.
• Procedencia SLSA Build L2/L3 cuando quien genera es la plataforma de build, no un script del repositorio.
• PR procedente de un fork: no ejecutes el workflow de la rama del atacante con secretos de la organización (pull_request_target mal usado).

Después del deploy, el Prometheus dice si el verde mintió.

Por dónde empezar de verdad

1. Tronco compartido, PRs pequeños, CI en el PR (lint + test). Sin esto, el resto es teatro.
2. Imagen OCI versionada por el SHA del commit, en un registry propio o en GHCR/GitLab.
3. Staging automático; producción con puerta (etiqueta o aprobación) hasta que las pruebas merezcan despliegue continuo.
4. Solo entonces GitOps, firma y SLSA.

Mucha empresa se queda en el paso 2 y lo llama DevOps. No es pecado; es honestidad. Saltar a Argo CD sin tests es pintar el avión.

Si el objetivo es formalizar el conocimiento, la entrada sobre la certificación LPI DevOps Tools Engineer cubre CI/CD, contenedores y automatización.

Un recorrido visual

El episodio del Diccionario del Programador, del canal Código Fonte TV, resume pipeline y CI/CD en pocos minutos:

Referencias

• Pipelines Terraform en GitLab — el CD de infraestructura en el mismo año de este post
• Gitea: Git self-hosted con Actions, runner y tea CLI
• La historia de GitLab
• Curso de Docker gratis
• Automatizando servidores Linux con Ansible
• Prometheus y Node Exporter
• Documentación de GitLab CI/CD · Documentación de GitHub Actions · Forgejo Actions
• SLSA · Sigstore · Argo CD · Flux

CI/CD sigue siendo el mismo pipeline de 2019: integrar pronto, probar siempre, soltar en trozos pequeños. El YAML fue a Git, el cluster pasó a extraer el estado, y el job verde ahora necesita demostrar de dónde salió el binario. El resto es herramienta.