Pipelines de CI que siguen siendo rápidos

Anatomía

• Trigger: un push, un pull request, un tag o una programación.
• Los jobs corren en runners nuevos; cada job está aislado, así que comparte datos mediante artefactos y cachés, no a través de la máquina.
• Los stages ordenan el trabajo: lint y pruebas unitarias primero (rápidas, baratas), luego pruebas de integración, luego build y publicación del artefacto.
• Gates: las verificaciones obligatorias deben pasar antes del merge.
• Los entornos y las aprobaciones protegen el despliegue en destinos sensibles.

Un ejemplo de pipeline

name: ci
on:
  pull_request:
  push: { branches: [main] }
concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true
permissions:
  contents: read
jobs:
  lint-test:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@<full-commit-sha>
      - uses: actions/setup-node@<full-commit-sha>
        with: { node-version: 22, cache: npm }
      - run: npm ci
      - run: npm run lint && npm test
  build:
    needs: lint-test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<full-commit-sha>
      - run: docker build -t app:${{ github.sha }} .

Mantenerlo rápido y confiable

• Cachea las dependencias y las capas de build, usando el lockfile como clave.
• Ejecuta las pruebas en paralelo y divide las suites lentas; pon en cuarentena las pruebas inestables y corrígelas, nunca reintentes a ciegas.
• Define timeouts para que un job colgado no bloquee la cola.
• Haz los builds reproducibles: herramientas fijadas, lockfiles, sin sorpresas de red.
• Trata el pipeline como código de producción: revísalo, prueba los cambios y dale el mínimo privilegio (ver el dominio Security engineering).

Leer una falla