O que é um pipeline CI/CD

Um pipeline CI/CD é uma sequência automatizada de etapas que leva o código do repositório até o ambiente de produção. Cada commit dispara o pipeline, que executa testes, build, análise de segurança e deploy sem intervenção manual.

O objetivo é simples: reduzir o tempo entre escrever código e entregar valor para o usuário final, com confiança de que nada está quebrado.

Anatomia de um pipeline moderno

Etapa 1: Lint e validação

Antes de tudo, valide formatação, convenções de código e tipagem estática. Isso pega erros triviais antes de gastar tempo com testes mais pesados.

Etapa 2: Testes automatizados

Execute testes unitários, de integração e e2e. Quebre o build se qualquer teste falhar. Testes são a rede de segurança que permite deploy frequente com confiança.

Etapa 3: Análise de segurança

SAST (Static Application Security Testing) analisa seu código por vulnerabilidades conhecidas. Dependency scanning verifica se suas dependências têm CVEs publicados. Secret scanning detecta credenciais acidentalmente commitadas.

Etapa 4: Build e artefato

Compile a aplicação, gere o artefato (Docker image, bundle, binário) e publique em um registry. Use tags semânticas (v1.2.3) e hashes de commit para rastreabilidade.

Etapa 5: Deploy

Deploy automático para staging após merge em develop. Deploy para produção após merge em main (ou com aprovação manual, dependendo da maturidade do time).

Etapa 6: Smoke tests pós-deploy

Após o deploy, execute testes de fumaça automatizados que validam que as funcionalidades críticas estão funcionando. Se falharem, rollback automático.

Gestão de ambientes

Ambientes por branch vs ambientes fixos

A estratégia clássica de ambientes fixos (dev, staging, production) funciona, mas cria gargalos quando múltiplos times querem testar em staging simultaneamente.

Ambientes efêmeros (preview environments) criados automaticamente para cada pull request resolvem isso. Cada PR ganha seu próprio ambiente completo, destruído após o merge. Ferramentas como Vercel, Netlify e ArgoCD com ApplicationSets facilitam isso.

Infrastructure as Code no pipeline

O pipeline não deve apenas deployar código — deve também provisionar infraestrutura. Terraform, Pulumi ou AWS CDK no pipeline garantem que mudanças de infraestrutura passem pelo mesmo processo de review e testes que mudanças de código.

Separe pipelines de infraestrutura de pipelines de aplicação. Mudanças em infra são menos frequentes e mais arriscadas, justificando um processo de aprovação mais rigoroso.

Feature Flags

Feature flags permitem deployar código inativo e ativá-lo independentemente do deploy. Isso desacopla "deploy" de "release": você pode deployar uma feature incompleta em produção sem que usuários a vejam, e ativá-la quando estiver pronta.

Isso também habilita rollback granular: se uma feature específica causa problemas, desative-a sem fazer rollback do deploy inteiro. LaunchDarkly, Flagsmith e Unleash são opções populares.

Estratégias de deploy seguro

Rolling deployment

Atualiza instâncias gradualmente. Se uma nova instância falha no health check, o deploy para e faz rollback. Configure maxUnavailable e maxSurge para controlar velocidade e disponibilidade.

Blue-Green deployment

Mantém dois ambientes. O tráfego é roteado para o novo após validação. Rollback é instantâneo — basta redirecionar o tráfego de volta. O custo é manter infraestrutura dobrada durante o deploy.

Canary releases

Direciona uma pequena porcentagem do tráfego para a nova versão. Monitora métricas e expande gradualmente. Detecta problemas com impacto mínimo.

Combine canary com análise automática de métricas: se a taxa de erro da nova versão for maior que a da versão anterior, rollback automático. Argo Rollouts e Flagger automatizam esse processo.

Progressive delivery

A evolução do canary: combine feature flags, canary releases e análise de métricas em um processo unificado. O deploy avança automaticamente por stages (1%, 5%, 25%, 50%, 100%) com validação automática em cada etapa.

Segurança no pipeline

Segurança não é uma etapa — é uma camada

O erro mais comum é tratar segurança como "mais uma etapa no pipeline". Segurança deve permear todo o processo:

  • Pre-commit: hooks que detectam secrets antes de commitar (git-secrets, detect-secrets)
  • PR review: análise automática de código por vulnerabilidades (CodeQL, SonarQube)
  • Build: dependency scanning com SCA (Software Composition Analysis)
  • Container: scan de imagens por vulnerabilidades (Trivy, Snyk Container)
  • Deploy: admission policies que bloqueiam imagens sem scan ou com vulnerabilidades críticas
  • Runtime: monitoramento de comportamento anômalo em produção

Supply Chain Security

Em 2026, ataques a supply chain de software são uma ameaça real. Proteja-se com:

  • SBOM (Software Bill of Materials): documente todas as dependências e suas versões
  • Assinatura de artefatos: assine imagens Docker e binários com cosign/sigstore
  • Verificação de proveniência: valide que o artefato foi construído pelo seu pipeline, não por um atacante
  • Pinagem de dependências: use lock files e hashes para garantir que dependências não foram alteradas

Otimização de performance do pipeline

Pipelines lentos matam a produtividade. Cada minuto a mais é um minuto que o desenvolvedor espera (ou muda de contexto e perde foco).

Paralelismo

Execute etapas independentes em paralelo. Lint, testes unitários e security scanning podem rodar simultaneamente. Use matrix builds para testar em múltiplas versões de linguagem/SO em paralelo.

Cache agressivo

Cache de dependências (node_modules, pip packages, Maven artifacts) entre execuções. Cache de layers Docker. Cache de resultados de testes que não mudaram. Um pipeline que baixa dependências do zero a cada execução está desperdiçando minutos preciosos.

Testes incrementais

Em vez de rodar todos os testes a cada commit, rode apenas os testes afetados pelas mudanças. Ferramentas como Nx (monorepos), Jest --changedSince e Bazel calculam automaticamente quais testes precisam rodar.

Métricas que importam

As quatro métricas DORA (DevOps Research and Assessment) são o padrão da indústria:

  • Deployment Frequency: quantas vezes você faz deploy por dia/semana
  • Lead Time for Changes: tempo do commit ao deploy em produção
  • Change Failure Rate: porcentagem de deploys que causam incidentes
  • Time to Restore: tempo para recuperar de uma falha em produção

Times de elite fazem deploy múltiplas vezes por dia, com lead time de menos de uma hora e change failure rate abaixo de 5%.

Meça essas métricas continuamente. Use ferramentas como Sleuth, LinearB ou dashboards customizados no Grafana para visualizar tendências e identificar gargalos.

Cultura DevOps: além das ferramentas

CI/CD não é só pipeline. É cultura. Sem os comportamentos certos, a melhor ferramenta do mundo não vai ajudar.

  • Commits pequenos e frequentes: branches de longa duração são inimigas do CI. Integre código pelo menos diariamente.
  • Testes como responsabilidade do time: testes não são "coisa do QA". Desenvolvedores escrevem testes, desenvolvedores corrigem testes quebrados.
  • Ownership de deploy: quem escreve o código é responsável por deployá-lo e monitorar em produção. Isso cria incentivo natural para qualidade.
  • Blameless post-mortems: quando algo quebra, investigue a causa raiz sem culpar indivíduos. O objetivo é melhorar o processo, não encontrar culpados.

Comece simples, evolua com disciplina

Um pipeline CI/CD não precisa ser perfeito no dia 1. Comece com lint + testes + build automático. Depois adicione security scanning, deploy automático e canary releases. Cada camada adiciona velocidade e confiança para sua equipe.

O objetivo final é que o deploy seja tão rotineiro e confiável que ninguém precisa pensar nele. Quando deploy vira evento, algo está errado. Quando deploy vira rotina, você chegou lá.