## glossário

O que é CI/CD?

CI/CD é a prática de automatizar a integração, a verificação e a entrega de mudanças de código. A sigla junta duas ideias relacionadas mas distintas: CI (Continuous Integration) e CD — que pode significar Continuous Delivery ou Continuous Deployment, dependendo de quão longe a automação vai.

As três siglas, sem confusão

Integração contínua (CI) — cada push dispara build e testes automaticamente, detectando conflitos e regressões em minutos em vez de semanas.
Entrega contínua (CD) — todo commit aprovado gera um artefato pronto para produção, mas o deploy final depende de aprovação humana.
Deploy contínuo (CD) — o passo além: aprovado nos testes, vai para produção sozinho, sem clique nenhum.

A distinção entre os dois "CD" importa na prática. Entrega contínua é adequada quando existe regulação, janela de manutenção ou necessidade de coordenação. Deploy contínuo exige confiança alta na suíte de testes e em mecanismos de reversão.

O problema que a integração contínua resolve

Antes da CI, equipes trabalhavam semanas em branches separadas e integravam tudo no fim — o chamado "inferno da integração", onde conflitos acumulados viravam dias de trabalho. Integrar continuamente troca uma dor grande e imprevisível por várias dores pequenas e triviais.

Pipeline de CI com GitHub Actions

name: CI
on: [push, pull_request]

jobs:
  verificar:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage
      - run: npm run build

O que compõe um pipeline maduro

Um pipeline completo costuma encadear: análise estática e lint, testes unitários, build do artefato, testes de integração, varredura de segurança em dependências, deploy em ambiente de homologação, testes end-to-end e finalmente produção. Cada etapa que falha interrompe a esteira e avisa quem fez a mudança.

Estratégias de deploy que reduzem risco

Rolling update — substitui instâncias aos poucos, mantendo o serviço no ar.
Blue-green — mantém dois ambientes idênticos e alterna o tráfego de uma vez, permitindo reversão instantânea.
Canário — envia uma fração pequena do tráfego para a versão nova e amplia conforme as métricas confirmam a estabilidade.
Feature flags — o código vai para produção desligado e é ativado por configuração, separando deploy de lançamento.

Boas práticas

Mantenha o pipeline rápido — acima de dez minutos, as pessoas param de esperar e o feedback perde valor. Falhas devem ser determinísticas: testes instáveis corroem a confiança até que todo mundo passe a ignorar o vermelho. E automatize a reversão, porque o que garante segurança não é nunca errar, e sim conseguir voltar em segundos.

## faq

Perguntas frequentes

Qual a diferença entre entrega contínua e deploy contínuo?

Na entrega contínua, cada mudança aprovada fica pronta para ir a produção, mas alguém precisa autorizar. No deploy contínuo, não há aprovação manual: passou nos testes, foi publicado. A diferença é apenas esse último passo humano.

Preciso de CI/CD em um projeto pessoal?

Um pipeline mínimo que roda lint, testes e build já compensa até em projetos solo — evita publicar código quebrado e documenta como o projeto é construído. Ferramentas como GitHub Actions oferecem cota gratuita suficiente para isso.

Quais ferramentas de CI/CD são mais usadas?

GitHub Actions domina projetos hospedados no GitHub pela integração nativa. GitLab CI é padrão em quem usa GitLab. Jenkins segue forte em ambientes corporativos com necessidades específicas, e CircleCI e Azure DevOps ocupam nichos relevantes.