CI/CD na prática: pipelines, deploy contínuo e estratégias de zero downtime

A velocidade com que um time consegue levar uma mudança do commit até a produção, com segurança, é um dos melhores indicadores de saúde de uma engenharia. Times lentos acumulam mudanças grandes e arriscadas; times rápidos entregam pequeno, com frequência e baixo risco. A prática que torna isso possível é o CI/CD.

Este guia explica o que são integração e entrega contínuas, como é a anatomia de um pipeline, quais estratégias de deploy permitem publicar sem derrubar o serviço e como tratar migrações de banco sem downtime. O objetivo é prático: transformar deploy de um evento tenso em uma rotina entediante, que é exatamente o que ele deve ser.

CI e CD: o que cada sigla significa

As letras se confundem, mas representam práticas distintas e complementares.

• CI (Continuous Integration / Integração Contínua): a prática de integrar mudanças de código com frequência, várias vezes ao dia, em um repositório compartilhado. Cada integração dispara automaticamente build e testes, para detectar conflitos e regressões cedo, enquanto ainda são baratos de corrigir.
• CD (Continuous Delivery / Entrega Contínua): a extensão do CI até o ponto em que qualquer versão aprovada está sempre pronta para ir a produção com um clique. A versão mais agressiva, Continuous Deployment / Implantação Contínua, vai além e publica automaticamente toda mudança que passa nos testes, sem aprovação manual.

A diferença entre os dois "CD" é onde fica o botão humano: na entrega contínua, alguém aprova o deploy; na implantação contínua, o pipeline publica sozinho. A escolha depende da maturidade dos testes e do apetite a risco.

Anatomia de um pipeline

Um pipeline de CI/CD é uma sequência automatizada de etapas que toda mudança percorre. As fases típicas:

1. Source: um push ou pull request dispara o pipeline.
2. Build: o código é compilado ou empacotado em um artefato (por exemplo, uma imagem de container).
3. Test: testes unitários, de integração e análise estática rodam. Falhou, para tudo.
4. Security scan: verificação de dependências vulneráveis e segredos expostos.
5. Deploy: o artefato vai para um ambiente (staging e depois produção).
6. Verify: testes de fumaça e monitoramento confirmam que o deploy está saudável.

O princípio que sustenta tudo é "falhe rápido e barato": quanto mais cedo no pipeline um problema é pego, menor o custo de corrigi-lo.

# Exemplo simplificado de pipeline (GitHub Actions)
name: ci-cd
on:
  push:
    branches: [main]
jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build
  deploy:
    needs: build-test
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh --strategy canary --health-check

Repare na dependência needs: build-test: o deploy só acontece se build e testes passarem. Essa é a rede de segurança que permite publicar com confiança.

Estratégias de deploy sem downtime

Publicar uma nova versão sem derrubar o serviço exige uma estratégia. As três mais comuns:

Rolling deploy

A nova versão substitui a antiga aos poucos, instância por instância. Em nenhum momento o serviço fica totalmente fora. É simples e econômico, mas durante a transição convivem duas versões do código, o que exige compatibilidade entre elas.

Blue-green

Mantêm-se dois ambientes idênticos: o "azul" (atual, em produção) e o "verde" (nova versão). Quando o verde está pronto e validado, o tráfego é redirecionado de uma vez. Se algo der errado, o rollback é instantâneo: basta apontar de volta para o azul. O custo é manter dois ambientes completos.

Canary

A nova versão recebe primeiro uma fatia pequena do tráfego (digamos, 5%). O time monitora erros e latência nesse grupo reduzido; se tudo correr bem, a fatia cresce gradualmente até 100%. É a estratégia mais segura para mudanças arriscadas, porque limita o raio de impacto de uma falha.

Tabela comparativa

Estratégia	Risco	Custo de infra	Velocidade de rollback	Quando usar
Rolling	Médio	Baixo	Médio	Mudanças rotineiras e compatíveis
Blue-green	Baixo	Alto (2x)	Instantâneo	Quando rollback rápido é crítico
Canary	Mínimo	Médio	Rápido	Mudanças arriscadas ou de alto tráfego

Migrações de banco sem downtime

O ponto que mais derruba deploys "sem downtime" não é o código, é o banco de dados. Uma migração mal planejada trava tabelas ou quebra a versão antiga do código que ainda está no ar durante a transição. A solução é o padrão expand/contract (expandir e contrair), feito em etapas:

• Expand: adicione o novo elemento de forma compatível (uma coluna nova, opcional), sem remover nada. O código antigo continua funcionando.
• Migrate: faça o deploy do novo código, que passa a usar o novo elemento, e migre os dados em segundo plano.
• Contract: só depois que nada mais usa o elemento antigo, remova-o em uma migração posterior.

Esse faseamento permite que as duas versões do código coexistam durante o deploy, o que é exatamente o que rolling e canary exigem. Nunca renomeie ou remova uma coluna no mesmo deploy que introduz o código novo: separe em passos.

Ambientes e promoção de versões

Um pipeline saudável move o mesmo artefato por uma sequência de ambientes, ganhando confiança a cada etapa. O fluxo clássico tem três estágios:

• Desenvolvimento: onde o código é integrado e os testes automatizados rodam a cada push.
• Staging (homologação): uma réplica o mais fiel possível da produção, onde se validam integrações, dados realistas e testes de aceitação.
• Produção: o ambiente real, que recebe apenas o que já provou saúde em staging.

O detalhe que mais importa é construir o artefato uma única vez e promovê-lo intacto entre os ambientes, em vez de recompilar a cada estágio. Recompilar abre espaço para divergências sutis ("funcionava em staging") justamente porque o que rodou lá não é byte a byte o que foi a produção. A mesma imagem, com configuração injetada por ambiente, elimina essa classe de surpresa.

Trunk-based development e branches curtas

CI/CD funciona melhor quando o time integra cedo e com frequência. O modelo trunk-based development favorece branches de vida curta, integradas ao ramo principal em horas ou poucos dias, em vez de branches longas que acumulam semanas de divergência. Quanto mais tempo um branch vive isolado, maior e mais arriscado fica o eventual merge. Branches curtas, protegidas por revisão e testes automáticos, mantêm o ramo principal sempre liberável, que é a precondição para entregar com frequência.

Boas práticas de CI/CD

• Pipeline rápido. Se o pipeline demora 40 minutos, o time evita rodá-lo. Mantenha-o enxuto e paralelize.
• Tudo versionado, inclusive a infra. Configuração e infraestrutura como código garantem ambientes reproduzíveis.
• Deploys pequenos e frequentes. Mudanças menores são mais fáceis de revisar, testar e reverter.
• Rollback automático. Se a verificação pós-deploy falhar, o pipeline deve voltar à versão anterior sozinho.
• Feature flags. Desacople deploy de liberação: publique o código desligado e ative o recurso quando quiser, sem novo deploy.
• Observabilidade no pipeline. Cada deploy deve emitir sinais que permitam confirmar saúde em segundos.

O objetivo final do CI/CD não é tecnologia pela tecnologia, e sim reduzir o risco de cada mudança a ponto de o time poder entregar muitas vezes ao dia sem medo. Deploy deve ser tão rotineiro que ninguém prenda a respiração quando ele acontece.

Quer entregar mais rápido sem perder o sono?

Um SaaS que escala precisa de um pipeline que entregue com velocidade e segurança, com deploys sem downtime e rollback à prova de pânico. Na ConstructorTI, CI/CD, estratégias de deploy e migrações seguras entram no blueprint desde o início, não como remendo depois do primeiro incidente em produção. Se você quer transformar deploy em rotina entediante, fale com a nossa engenharia e saia da conversa com um diagnóstico técnico do seu fluxo de entrega.