Integração contínua (CI)

Integração contínua (CI, do inglês continuous integration) significa que os desenvolvedores fazem merge de pequenas mudanças na branch principal com frequência, e um servidor faz o build do código e executa os testes automatizados a cada push ou pull request. O objetivo é feedback rápido: se uma mudança quebra algo, o autor descobre enquanto a mudança ainda está fresca, e não dias depois durante um merge gigante.

Exemplo (GitHub Actions)

Um pipeline mínimo que executa a suíte de testes em todo pull request e em pushes para a main:

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test

Se o npm test terminar com código diferente de zero, o job falha e o pull request mostra um check vermelho. Junto com uma proteção de branch que exige esse check, código quebrado não consegue entrar no merge.

O que é responsabilidade do tester na CI

• Quais testes rodam onde. Testes unitários e de API rápidos em todo pull request; suítes end-to-end mais lentas no merge ou em horário agendado. Um pipeline de pull request que leva 40 minutos deixa de ser usado.
• Qualidade do sinal. Um teste flaky em um job bloqueante ensina as pessoas a clicar em “re-run”. Coloque os testes instáveis em quarentena para que um build vermelho sempre signifique alguma coisa.
• Artefatos. Publique relatórios, traces e screenshots das execuções com falha para que ninguém precise reproduzir uma falha localmente só para vê-la.
• Paralelismo. Dividir uma suíte longa em shards em várias máquinas mantém o tempo de feedback estável à medida que a suíte cresce.

Diferença em relação ao CD

A entrega contínua (continuous delivery) estende a CI: todo build aprovado é empacotado e fica pronto para release, geralmente passando por ambientes de staging. O deploy contínuo (continuous deployment) vai um passo além e libera automaticamente em produção toda mudança aprovada. A CI é a base dos dois; sem uma suíte de testes confiável em cada commit, nenhum deles é seguro.

Erros comuns

Rodar a CI só à noite, deixar a branch principal vermelha por dias e tratar o pipeline como o lugar onde os testes são escritos, e não onde são executados. A CI é tanto um hábito do time quanto uma ferramenta: merges pequenos e, quando o build quebra, corrigir ou reverter.