Pipelines de CI que continuam rápidos

Anatomia

• Trigger: um push, um pull request, uma tag ou um agendamento.
• Os jobs rodam em runners novos; cada job é isolado, então compartilhe dados por artefatos e caches, não pela máquina.
• Os stages ordenam o trabalho: lint e testes unitários primeiro (rápidos, baratos), depois testes de integração, depois build e publicação do artefato.
• Gates: as verificações obrigatórias devem passar antes do merge.
• Ambientes e aprovações protegem o deploy em alvos sensíveis.

Um exemplo 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 }} .

Mantendo-o rápido e confiável

• Faça cache das dependências e das camadas de build, usando o lockfile como chave.
• Rode os testes em paralelo e divida as suítes lentas; ponha testes instáveis em quarentena e corrija-os, nunca repita às cegas.
• Defina timeouts para que um job travado não prenda a fila.
• Torne os builds reproduzíveis: ferramentas fixadas, lockfiles, sem surpresas de rede.
• Trate o pipeline como código de produção: revise-o, teste as mudanças e dê a ele o menor privilégio (veja o domínio Security engineering).

Lendo uma falha