Deploy Contínuo: Como Montar um Pipeline de CI/CD

Você faz merge na branch principal às 18h de sexta. O deploy manual leva 40 minutos, exige que alguém rode o build local, suba pro servidor e reze para não quebrar nada em produção. Se sua equipe ainda trabalha assim, cada release é um evento de risco em vez de uma rotina chata, e o time acaba evitando lançar coisas justamente nos dias em que teria mais gente disponível para apagar incêndio.

Deploy contínuo resolve isso automatizando o caminho entre o commit e a produção. Este artigo mostra como montar o pipeline, quais testes rodar antes de liberar, como reverter quando algo passa despercebido e o que acompanhar depois que o código já está no ar.

O que é deploy contínuo

Deploy contínuo é a prática de levar toda mudança aprovada nos testes automaticamente para produção, sem intervenção manual. A diferença para a entrega contínua é sutil, mas importa: na entrega contínua, alguém do time ainda aperta um botão para liberar; no deploy contínuo, passou nos testes, foi ao ar.

Isso exige confiança pesada na suíte de testes. Se o pipeline aprova código quebrado, o problema não é a automação em si, é a cobertura de teste que não pegou o bug antes de chegar em produção.

Ferramentas como GitHub Actions, GitLab CI ou o pipeline nativo da Vercel cuidam da orquestração: disparam a cada push, rodam os estágios na ordem certa e bloqueiam a promoção se qualquer um falhar. A ferramenta importa menos do que a disciplina de nunca pular um estágio manualmente, nem quando a correção parece pequena.

Deploy contínuo ou entrega contínua: qual escolher

Escolha deploy contínuo quando a suíte de testes é confiável e a reversão é rápida. Escolha entrega contínua quando o produto exige aprovação humana antes de ir ao ar, como em sistemas financeiros ou de saúde sob regulação.

A maioria dos times de produto SaaS ganha mais eliminando o gargalo humano do que perde em segurança, desde que o pipeline tenha os testes certos e um jeito de reverter em minutos. Times que lidam com dinheiro de terceiros ou dado sensível de saúde costumam manter um portão manual por exigência de compliance, não por falta de confiança na automação.

Como montar um pipeline de deploy contínuo

Um pipeline de deploy contínuo segue cinco estágios fixos, na mesma ordem, seja qual for a stack. Veja como estruturar cada um:

1. Build reproduzível. Trave as versões de dependência com o lockfile commitado, para o build de hoje sair idêntico ao de amanhã.
2. Testes automatizados. Unitários primeiro, porque rodam em segundos. Depois integração, porque pegam o que o unitário não vê.
3. Deploy em ambiente de preview. Cada pull request sobe uma URL isolada, e assim quem revisa o código também revisa o comportamento antes de aprovar.
4. Promoção para produção. Só o commit que já rodou em preview e passou nos testes chega até aqui. Nunca pule esse estágio direto da branch.
5. Verificação pós-deploy. Um teste de fumaça automático confirma que as rotas principais respondem antes de o deploy ser dado como concluído.

Quais testes rodar antes do deploy

O pipeline precisa rodar pelo menos três camadas de teste antes de liberar qualquer coisa: unitário, integração e um teste de fumaça contra o ambiente de preview. Pular qualquer uma delas move o risco para depois do deploy, quando custa bem mais caro corrigir.

Testes unitários cobrem lógica isolada e devem rodar em segundos, sem tocar rede nem banco. Testes de integração validam que as peças conversam direito, banco de dados incluso, e podem levar alguns minutos. O teste de fumaça é o mais barato de rodar: confere se a home, o login e a rota crítica do produto respondem com sucesso logo após o deploy.

Um risco à parte é o teste instável, aquele que falha de vez em quando sem relação com o código alterado. Times que ignoram esse tipo de falha acabam treinando a si mesmos a clicar em "rodar de novo" sem olhar o motivo, o que apaga o sinal justamente no dia em que a falha é real. Trate teste instável como bug de prioridade alta, não como ruído de fundo.

Como reverter rápido quando o deploy quebra

Reversão rápida significa voltar para a versão anterior em poucos minutos, sem precisar investigar a causa primeiro. A investigação vem depois, com o site já estável de novo.

Plataformas como a Vercel guardam cada deploy anterior pronto para ser promovido de volta com um clique ou um comando, o que torna a reversão uma operação de segundos, não um novo build. Se sua infraestrutura não guarda builds anteriores prontos para uso, esse é o primeiro problema a resolver antes de automatizar qualquer outra etapa do pipeline.

Para mudanças de comportamento maiores, uma feature flag ajuda mais do que uma reversão completa. Em vez de desfazer o deploy inteiro, o time desliga só a funcionalidade nova, mantendo todo o resto que já estava funcionando bem no ar. É uma reversão mais cirúrgica, e vale o esforço extra de implementar quando a mudança afeta um fluxo crítico do produto.

O que monitorar depois do deploy

Depois de qualquer deploy, meça taxa de erro, tempo de resposta e Core Web Vitals nas primeiras horas, comparando com a janela de antes do deploy. Um pipeline automatizado sem observabilidade só troca um risco visível por um risco silencioso.

Assim como medir o LCP antes de declarar uma otimização bem sucedida, como mostramos em Como Otimizar o LCP do Seu Site, medir o comportamento real depois do deploy é o que separa uma automação confiável de uma que só parece confiável até o dia em que para de ser.

Deploy contínuo não é sobre lançar mais rápido. É sobre tornar o release chato, previsível, sem drama de sexta-feira à tarde. Se seu processo ainda depende de alguém lembrar dos passos certos na hora certa, fale com a gente na página de contato.