Busque em todas as páginas da documentação
CI/CD é frequentemente dito como uma única palavra, mas nomeia duas perguntas separadas para as quais uma equipe precisa de respostas automatizadas: esta alteração é segura para mesclar e esta alteração é segura para lançar.
Integração Contínua (CI) responde à primeira pergunta executando verificações rápidas e repetíveis em cada alteração proposta.
Entrega/Implantação Contínua (CD) responde à segunda, transformando uma alteração mesclada em um artefato implantável e movendo esse artefato exato através de ambientes em direção à produção.
Noções Básicas de CI/CD mostra como ambos os pipelines se parecem como fluxos de trabalho do GitHub Actions para um serviço Node; esta página é o modelo por trás deles - para que serve um pipeline, e por que dividi-lo em dois é a forma correta em vez de uma convenção arbitrária.
Antes do CI/CD, "isso funciona" era respondido por uma pessoa executando testes localmente, e "isso é seguro para lançar" era respondido por outra pessoa clicando em um deploy manualmente.
Ambas as etapas eram trabalho real, ambas podiam ser puladas sob pressão de prazo, e ambas produziam resultados diferentes dependendo de quem as executava e em que estado sua máquina se encontrava.
Um pipeline substitui isso por uma sequência fixa e automatizada de etapas que executa da mesma maneira todas as vezes, na mesma infraestrutura, independentemente de quem a acionou.
Um gate é qualquer etapa nessa sequência que pode parar o pipeline completamente - um teste falhando, um erro de lint, uma descoberta de vulnerabilidade crítica em uma verificação de segurança - e o objetivo de um gate é que ele bloqueia por padrão, em vez de depender de alguém se lembrar de verificar.
A divisão CI/CD se alinha a duas preocupações genuinamente diferentes: CI é executado em cada alteração proposta (um pull request) para responder "isso é seguro para mesclar", enquanto CD é executado após uma alteração ser aceita para responder "isso é seguro para lançar" - confundi-los em um único pipeline tende a atrasar cada PR com etapas relacionadas ao deploy que ele não precisa, ou pular verificações específicas de release que só importam quando o código está indo para produção.
O trabalho de um pipeline de CI é estreito e rápido: instalar dependências, então executar os gates mais baratos primeiro - lint, typecheck - antes dos mais caros - testes unitários, e às vezes testes de integração - para que uma alteração quebrada falhe em segundos em vez de minutos.
PR aberto
-> instalar (npm ci)
-> lint (falha rápido, segundos)
-> typecheck (falha rápido, segundos)
-> testes unitários (minutos)
-> merge bloqueado até que todos os gates passem
O trabalho de um pipeline de CD começa onde o de CI termina: pegar uma alteração já validada e produzir um artefato - uma imagem Docker, um zip do Lambda, um bundle compilado - com tag imutável, geralmente pelo SHA do commit git que o produziu.
Esse artefato é então promovido: implantado em um ambiente de staging, testado com smoke tests, e só então implantado em produção, com a regra crítica de que é o mesmo artefato se movendo para frente em cada etapa, nunca uma nova compilação por ambiente.
Merge para main
-> construir artefato, tag com SHA do git
-> deploy para staging
-> smoke test automatizado contra staging
-> (aprovação, ou automático se totalmente contínuo)
-> deploy do mesmo artefato para produção
Reconstruir por ambiente anula o propósito de todo o modelo: se staging e produção são construídos a partir de builds separadas, um teste de staging que passa não garante mais nada sobre o que realmente chega à produção, porque os dois nunca foram comprovadamente o mesmo código.
// Uma etapa do pipeline marca com o SHA do commit, não com um rótulo mutável -
// isso é o que torna "promover o mesmo artefato" possível
const image = `ghcr.io/acme/api:${process.env.GITHUB_SHA}`;
// etapas de deploy de staging e produção referenciam esta tag exata,
// nunca `:latest`, então ambos os ambientes executam código comprovadamente idênticoAmbientes (ci, staging, production) existem para capturar diferentes classes de problemas em diferentes pontos: CI captura regressões em nível de código antes da mesclagem, staging captura problemas de integração e configuração contra infraestrutura semelhante à de produção, e produção é onde o tráfego real valida o release.
Rollback é a válvula de segurança para a qual todo esse modelo existe para tornar barato: como cada release é um artefato imutável com tag, desfazer um release ruim significa reimplantar a tag anterior conhecida como boa, em vez de reconstruir o que costumava estar em execução a partir da memória.
Entrega contínua e implantação contínua são frequentemente usadas de forma intercambiável, mas descrevem níveis diferentes de automação: entrega significa que cada alteração que passa por todos os gates está pronta para ser implantada a qualquer momento, geralmente com uma aprovação manual antes da produção; implantação significa que cada alteração que passa por todos os gates realmente faz o deploy automaticamente, sem intervenção humana.
A maioria das equipes se encontra em algum lugar entre as duas - deploys automáticos de staging, mas uma aprovação necessária (ou um rollout progressivo) controlando a produção - porque a implantação contínua completa exige um nível de cobertura de gates e maturidade de monitoramento que leva tempo para ser conquistado.
Monorepos complicam o modelo de pipeline diretamente: executar todos os gates em cada alteração, independentemente do que mudou, não escala quando um repositório contém muitos serviços implantáveis independentemente, razão pela qual a filtragem baseada em caminhos e ferramentas como Nx ou Turborepo que detectam pacotes "afetados" se tornaram padrão em vez de opcionais nessa escala.
A segurança se tornou uma preocupação de primeira classe no pipeline em vez de um pensamento posterior: auditoria de dependências, escaneamento de imagens de contêiner e verificações de assinatura/proveniência de commits agora são executados como gates ao lado de testes, porque um pipeline que apenas valida a correção funcional deixa uma lacuna real para o risco da cadeia de suprimentos.
Técnicas de entrega progressiva - canary releases, blue-green deploys - estendem o modelo de promoção ainda mais, tornando o "deploy para produção" em si um processo gradual e controlado, em vez de um interruptor instantâneo de tudo ou nada, para que um release ruim possa ser detectado e revertido após atingir uma pequena fração do tráfego em vez de todos.
| Modelo de Entrega | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| Entrega Contínua (gate manual para prod) | Julgamento humano sobre o timing do release; modelo mental mais simples | Cadência de release mais lenta; aprovação pode se tornar um gargalo | Ambientes regulamentados, alterações de alto risco |
| Implantação Contínua (totalmente automática) | Loop de feedback mais rápido possível; sem cerimônia de dia de release | Requer altíssima confiança nos gates automatizados | Equipes maduras com forte cobertura de testes/monitoramento |
| Processo de release manual | Nenhum investimento em pipeline necessário | Inconsistente, lento, não escala além de uma equipe pequena | Protótipos iniciais, projetos descartáveis |
CI é executado em cada alteração proposta para responder "isso é seguro para mesclar" - lint, typecheck, testes. CD é executado após uma alteração ser aceita para responder "isso é seguro para lançar" - construir um artefato e promovê-lo através de ambientes em direção à produção.
Eles servem a momentos diferentes no ciclo de vida de uma alteração e a públicos diferentes: o PR de cada contribuidor precisa de feedback rápido de CI, mas nem todo PR precisa de uma execução de pipeline de release. Separados, eles mantêm o feedback de PR rápido e mantêm etapas específicas de release (construir artefatos, implantar) fora do caminho de mesclagem.
Qualquer verificação automatizada que pode impedir o pipeline de prosseguir - um teste falhando, uma violação de lint, uma descoberta de vulnerabilidade crítica. Gates bloqueiam por padrão, o que os torna mais confiáveis do que depender de alguém se lembrar de verificar manualmente.
Se staging e produção são construídos separadamente, um teste de staging que passa não garante mais nada comprovável sobre o que realmente é executado em produção, porque as duas builds nunca foram confirmadas como idênticas. Marcar um artefato pelo SHA do commit e promover essa mesma tag preserva essa garantia.
Como cada release é um artefato imutável com tag, reverter significa reimplantar a tag anterior conhecida como boa em vez de tentar reconstruir um estado anterior a partir da memória ou de etapas manuais.
Entrega contínua significa que cada alteração que passa por todos os gates está pronta para ser implantada a qualquer momento, geralmente atrás de uma aprovação manual. Implantação contínua remove essa etapa manual completamente - cada alteração que passa faz o deploy automaticamente.
Geralmente sim - executar todos os gates em cada alteração para de escalar quando um repo contém múltiplos serviços implantáveis independentemente, razão pela qual a detecção de pacotes afetados (Nx, Turborepo) e gatilhos de fluxo de trabalho baseados em caminhos se tornam prática padrão.
Sim, tratada como um gate ao lado de testes funcionais - auditorias de dependências e escaneamento de imagens capturam riscos da cadeia de suprimentos que testes puramente funcionais nunca foram projetados para capturar.
Não - ele apenas prova o que seus gates foram construídos para verificar. Revisão de código, monitoramento de produção e julgamento sobre o risco específico da alteração ainda importam, especialmente para qualquer coisa que os gates de um pipeline não foram projetados para verificar.
É um trade-off deliberado entre velocidade e controle - uma etapa de aprovação permite que um humano aplique julgamento sobre o timing do release ou o risco de negócios que os gates automatizados não estão posicionados para avaliar.
Executar as verificações mais baratas e rápidas (lint, typecheck) antes das mais caras (suítes de testes completas, builds) para que uma alteração quebrada seja rejeitada em segundos em vez de após vários minutos de trabalho desnecessário.
Uma extensão do modelo de promoção onde o "deploy para produção" em si se torna controlado e incremental - um novo release atinge primeiro uma pequena fatia do tráfego, e só se expande se parecer saudável, para que um release ruim afete muito menos usuários antes de ser detectado.
Versões de Stack: Esta página é conceitual e não está vinculada a uma versão específica de stack.
Revisado por Chris St. John·Última atualização: 15 de jul. de 2026