CI, CD e CD: o que cada sigla significa na prática

"Temos CI/CD" é uma das afirmações mais imprecisas do vocabulário técnico. Ela pode significar desde "temos um script que roda testes" até "todo commit aprovado vai sozinho para produção em oito minutos" — e a distância entre as duas é enorme.

Parte da confusão é estrutural: a sigla CD representa duas coisas diferentes, e quase nunca se diz qual. Desfazer isso muda a qualidade da conversa sobre o que a sua operação realmente tem.

CI — integração contínua

O que é: a prática de integrar o trabalho de todo mundo na branch principal com frequência alta — idealmente mais de uma vez por dia por pessoa —, com validação automática a cada integração.

O que ela ataca: o merge doloroso. Integração é uma dívida com juros compostos: adiar um dia custa pouco, adiar um mês custa desproporcionalmente mais. Quando o merge dói, o time evita integrar; quando evita, a branch fica mais tempo aberta e o merge dói mais. CI quebra esse ciclo.

O que ela exige de verdade:

• Controle de versão com uma branch principal clara.
• Branches de vida curta — um a dois dias, não semanas. Este é o requisito real, e o mais violado.
• Pipeline automático que roda a cada integração: build, lint, testes rápidos.
• Retorno em poucos minutos. Se o resultado demora 40 minutos, as pessoas param de integrar com frequência e a prática morre.
• Build quebrado tratado como prioridade, não como ruído de fundo.

O indicador que diz se você tem CI: a duração média das suas branches. Se são semanas, você tem controle de versão e um pipeline — não integração contínua.

CD #1 — entrega contínua

O que é: todo código que passa no pipeline fica pronto para ir a produção, a qualquer momento. O deploy acontece quando alguém decide, apertando um botão.

O que ela ataca: o acúmulo. Sem entrega contínua, o que está pronto espera pela próxima janela — e janelas raras significam lotes grandes, que são mais arriscados e mais difíceis de diagnosticar quando falham.

O que ela exige além do CI:

• Artefato versionado e imutável, guardado em registry.
• Construir uma vez e promover o mesmo artefato entre ambientes, em vez de reconstruir para cada um. Reconstruir significa que o que foi testado não é o que vai para produção.
• Ambientes parecidos entre si, criados a partir do mesmo código.
• Deploy automatizado e reprodutível, não comando digitado no servidor.
• Migração de banco compatível para trás, porque a versão anterior pode precisar voltar.
• Rollback ensaiado — não no papel, executado e cronometrado.

O indicador: quanto tempo leva do commit aprovado até estar em produção, se alguém decidir agora. Se a resposta envolve "na próxima terça", você não tem entrega contínua.

CD #2 — implantação contínua

O que é: o passo adicional. Todo código que passa no pipeline vai automaticamente para produção, sem decisão humana.

O que ela exige além da entrega contínua:

• Suíte de testes em que o time confia de verdade. Sem teste instável — um teste que falha aleatoriamente treina todo mundo a ignorar falha.
• Monitoramento capaz de detectar degradação em minutos.
• Rollback automático por critério objetivo e escrito, definido antes do deploy.
• Feature flags, para desacoplar entregar código de liberar funcionalidade.
• Cultura de lotes pequenos já consolidada.

É o objetivo de todo mundo? Não. Implantação contínua faz muito sentido para produto web com boa cobertura de teste e monitoramento maduro. Faz pouco sentido para software com versões em campo, sistema regulado com exigência de aprovação, ou time que ainda não confia na própria suíte.

Entrega contínua é a meta razoável para a grande maioria. Ela entrega quase todo o benefício, mantendo a decisão de ir ao ar com um humano.

O comparativo

A ordem de adoção

Não dá para pular degraus, e tentar é o erro mais comum:

1. Controle de versão para tudo, inclusive infraestrutura e configuração.
2. Pipeline de build e teste rápido — retorno em menos de 10 minutos.
3. Branches curtas, com limite acordado pelo time. Aqui você tem CI.
4. Artefato versionado em registry, construído uma vez.
5. Ambientes padronizados, criados pelo mesmo código.
6. Deploy automatizado, com rollback ensaiado. Aqui você tem entrega contínua.
7. Observabilidade com alerta que detecta degradação rápido.
8. Critérios objetivos de reversão e rollback automático. Aqui você pode ter implantação contínua.

Quem tenta o passo 8 sem o 3 produz um sistema que entrega bugs em produção automaticamente — o que é pior do que não ter nada.

Como avaliar o que você tem hoje

Cinco perguntas, respondidas com honestidade:

1. Qual a duração média das suas branches? Semanas significa que não há CI.
2. Quanto tempo do commit até o retorno que diz se quebrou? Acima de 20 minutos e o time deixa de integrar.
3. O artefato que vai para produção é o mesmo que foi testado em homologação? Se é reconstruído, não é.
4. Quando foi a última vez que alguém reverteu um deploy de verdade? "Nunca" significa que o rollback é teórico.
5. Com que frequência o código chega em produção? Mensal, semanal ou diária?

As respostas localizam você na escada acima com precisão razoável.

O que mais importa, acima das siglas

Independentemente de onde você esteja:

• Lote pequeno. É o que reduz risco de verdade. Times que entregam mais vezes falham menos, não mais — porque mudou pouca coisa e a causa é óbvia.
• Pipeline confiável. Teste instável destrói a confiança e, com ela, todo o valor da automação.
• Caminho de volta real. Rollback testado e cronometrado, com migração de banco que permite voltar.
• Medição. Frequência de entrega, tempo de ciclo, taxa de falha e tempo de recuperação. Sem esses quatro, "estamos melhorando" é fé.

Erros comuns

• Dizer "temos CI/CD" com branches de três semanas abertas.
• Pipeline lento, que faz o time parar de integrar.
• Reconstruir o artefato em cada ambiente.
• Conviver com testes instáveis e reexecutar por hábito.
• Deploy manual por SSH em produção.
• Rollback que existe no documento e nunca foi executado.
• Migração destrutiva de banco no mesmo deploy que o código que a usa.
• Buscar implantação contínua sem confiança na suíte de testes.
• Imagem do registry removida por política de retenção, inviabilizando reverter.
• Tratar build quebrado como normal.

Onde a Solvefy/Cloud entra

Começamos medindo onde você está: duração de branches, tempo até o primeiro retorno, frequência de entrega, tempo de recuperação. A partir daí, subimos os degraus na ordem — pipeline rápido e confiável, artefato único promovido entre ambientes, paridade de ambientes, deploy automatizado com rollback ensaiado e cronometrado. E deixamos a medição contínua rodando, para o ganho não se perder no trimestre seguinte. Trabalhamos com GitHub Actions, GitLab CI e Jenkins.

Quer saber em que degrau a sua entrega está? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.