Se você trabalha com desenvolvimento de software há algum tempo, já ouviu falar em CI/CD. O problema é que esse termo agrupa conceitos distintos que muita gente confunde — e a confusão começa já na sigla. CI/CD pode significar coisas diferentes dependendo de quem está falando: às vezes é Continuous Integration com Continuous Delivery, às vezes com Continuous Deployment. São práticas relacionadas mas com implicações bem diferentes para o time e para o negócio.
Nesse post a gente vai destrinchar cada uma dessas práticas, entender onde começa e onde termina cada fase do pipeline e deixar claro de uma vez por todas qual é a diferença entre Delivery e Deployment.
Continuous Integration — a base de tudo
A Integração Contínua — ou CI, do inglês Continuous Integration — é a prática de integrar as mudanças de código de todos os desenvolvedores do time em um repositório compartilhado com frequência, várias vezes ao dia se possível. Cada vez que alguém faz um commit, um servidor de CI automaticamente constrói a aplicação e executa os testes.
O objetivo é simples: descobrir problemas o mais cedo possível, enquanto o contexto ainda está fresco e a correção ainda é barata. Um bug encontrado minutos depois do commit leva minutos para ser corrigido. O mesmo bug encontrado duas semanas depois, quando o código já foi integrado com o trabalho de outros cinco desenvolvedores, pode levar dias.
Na prática, um pipeline de CI faz basicamente isso: detecta o commit no repositório, baixa o código, instala as dependências, compila a aplicação e executa os testes unitários. Se qualquer etapa falhar, o time é notificado imediatamente. O resultado de cada build fica visível para todos — o que cria transparência e responsabilidade compartilhada sobre a saúde do código.
Um ponto importante: CI sozinha não inclui deploy em produção. Ela garante que o código compila e passa nos testes. O que acontece depois disso é responsabilidade das práticas que vêm a seguir.
Continuous Testing — qualidade em cada etapa
O Teste Contínuo — CT, de Continuous Testing — é muitas vezes tratado como parte implícita do CI, mas merece atenção própria porque vai muito além dos testes unitários que rodam no build inicial.
A ideia é que testes automatizados estejam presentes em cada etapa do pipeline, não só na integração. Testes unitários rodam no commit. Testes de integração rodam quando o código chega ao ambiente de homologação. Testes de aceitação verificam se o comportamento do sistema atende aos critérios definidos pelo negócio. Testes de performance detectam regressões antes que cheguem à produção.
O Continuous Testing muda a mentalidade do time: qualidade deixa de ser uma fase no final do processo e passa a ser uma propriedade verificada continuamente ao longo de todo o pipeline. Isso tem uma consequência prática importante — quanto mais cedo um tipo de falha é detectado, mais barato é corrigi-la. Um teste de integração que falha em homologação é muito menos custoso do que um problema de integração descoberto em produção.
A cobertura de testes também entra aqui. Um servidor de CI bem configurado monitora a porcentagem de código coberta por testes e alerta quando um commit reduz essa cobertura. Com o tempo, ver a cobertura crescendo vira um motivador natural para o time escrever mais testes.
Continuous Delivery — sempre pronto para ir a produção
A Entrega Contínua — CD, de Continuous Delivery — é o passo seguinte à Integração Contínua. A ideia central é que o software esteja sempre em um estado deployável — ou seja, que a qualquer momento seja possível colocar a versão atual em produção com confiança.
Para isso, além de compilar e testar o código, o pipeline de Continuous Delivery automatiza também a entrega até ambientes de pré-produção: homologação, staging, ambientes de teste de aceitação. O código passa por todas essas etapas de forma automática. O que não é automático no Continuous Delivery é o deploy final em produção — esse passo é deliberadamente manual e acionado por uma decisão humana.
Isso pode parecer uma limitação, mas é uma escolha estratégica. Nem toda empresa tem condições de ou interesse em colocar código em produção dezenas de vezes por dia. O Continuous Delivery garante que quando a decisão de ir a produção for tomada — seja por uma janela de manutenção, por uma aprovação de negócio ou por qualquer outro critério — o processo seja rápido, confiável e sem surpresas. O botão existe. Alguém tem que apertar.
Continuous Deployment — do commit ao usuário sem intervenção humana
O Deployment Contínuo — também abreviado como CD, de Continuous Deployment — é a evolução natural do Continuous Delivery. A diferença é uma só, mas é fundamental: não existe o passo manual de aprovação para produção. Todo commit que passa por todas as etapas do pipeline vai automaticamente para produção.
No Continuous Delivery, a implantação em produção requer aprovação manual — representada pela etiqueta vermelha no diagrama. No Continuous Deployment, todas as etapas são automáticas, do teste unitário até os testes pós-implantação em produção.
Isso significa que em um time que pratica Continuous Deployment, um desenvolvedor pode fazer um commit às 9h e ver aquela mudança rodando em produção para usuários reais às 9h05, sem precisar falar com ninguém. Isso só é possível porque a confiança no pipeline de testes é alta o suficiente para que a automação substitua a aprovação humana.
Continuous Deployment não é para todo mundo. Exige maturidade técnica elevada, cobertura de testes robusta e uma cultura de times que aceita a responsabilidade de que cada commit pode ir a produção. Mas para quem chega lá, o ganho em velocidade de entrega de valor para o usuário é substancial.
O pipeline completo na prática
Juntando tudo, o pipeline de um time maduro em CI/CD tem mais ou menos essa progressão:
Um desenvolvedor faz um commit no repositório. O servidor de CI detecta a mudança, compila o código e executa os testes unitários — isso é Continuous Integration. Se passar, testes de integração e de aceitação são executados automaticamente em ambientes controlados — isso é Continuous Testing. O código é automaticamente promovido para homologação e validado lá — isso é Continuous Delivery. Se o time pratica Continuous Deployment, a próxima etapa é produção, também automática. Se pratica Continuous Delivery, alguém aperta o botão quando o momento é certo.
Cada etapa tem um propósito e um custo diferente de falha. Quanto mais cedo um problema é detectado no pipeline, mais barato é corrigi-lo. A lógica de todo esse investimento em automação é exatamente essa: deslocar a descoberta de problemas para o mais próximo possível do momento em que o código foi escrito.
Continuous Delivery ou Continuous Deployment — qual escolher?
A resposta depende do contexto do seu produto e da maturidade do seu time.
Continuous Delivery faz sentido quando existe uma necessidade real de controle sobre o que vai para produção e quando — seja por requisitos regulatórios, por janelas de manutenção acordadas com clientes, ou simplesmente porque o produto ainda está em um estágio onde a validação humana agrega valor real antes de cada deploy.
Continuous Deployment faz sentido quando o time tem confiança alta no pipeline de testes, quando o produto suporta deploys frequentes sem impacto negativo para o usuário e quando a velocidade de entrega de valor é uma vantagem competitiva real para o negócio.
O que não faz sentido é confundir os dois conceitos e achar que está praticando Continuous Deployment quando na verdade está fazendo Continuous Delivery — ou vice-versa. São estratégias diferentes, com implicações diferentes para processos, ferramentas e cultura de time.
O mais importante é que qualquer um dos dois é infinitamente melhor do que nenhum. Um time que pratica Continuous Delivery consistentemente entrega software com mais qualidade, mais previsibilidade e menos estresse do que um time que ainda faz deploys manuais, pontuais e cheios de cerimônia.
Treinamentos relacionados com essa postagem
