O que é Integração Contínua / Entrega Contínua (CI/CD)?

Integração contínua foi desenvolvida e difundida no contexto de Extreme Programming. Martin Fowler publicou um artigo sobre a prática em 2000 e o revisou depois, incluindo uma versão atualizada em 2024. Seu foco é integrar alterações de cada pessoa à base compartilhada com frequência e verificar cada integração.

Jez Humble e Dave Farley sistematizaram a entrega contínua no livro Continuous Delivery, publicado em 2010. Humble distinguiu entrega contínua da implantação contínua: a primeira preserva a capacidade de liberar a qualquer momento; a segunda automatiza a ida à produção de cada mudança aprovada. CI/CD é um rótulo prático que reúne essas disciplinas, não uma ferramenta única.

Imagine preparar pequenas encomendas ao longo do dia e conferir cada uma antes de enviá-la, em vez de juntar uma montanha no fim do mês. Em software, CI/CD reduz o tamanho das mudanças não verificadas e torna o caminho até produção repetível. O pipeline automatizado ajuda, mas a prática começa com hábitos do time: integrar cedo, manter testes úteis e corrigir a base quando uma verificação falha.

Integração contínua. Pessoas integram alterações numa linha compartilhada pelo menos diariamente, e cada integração passa por build e testes automáticos. Isso revela conflitos enquanto o contexto ainda está recente. Abrir um pull request não basta se ele fica dias esperando e só é integrado muito depois. O objetivo é que a base principal permaneça em condição de trabalho. Trunk-based development é uma forma de organizar esse hábito com branches curtas ou integração direta.

Feedback rápido. O primeiro estágio do pipeline deve detectar falhas frequentes em pouco tempo, como erro de compilação, teste unitário quebrado ou verificação de formato. Outras etapas podem investigar integração, segurança, desempenho e comportamento em ambiente próximo de produção. Uma suíte lenta pode ser dividida em camadas, mantendo retorno rápido sem abrir mão de cobertura relevante. Nenhum conjunto de testes prova ausência de defeitos; revisão e observação do serviço continuam necessárias.

Base quebrada. Se uma mudança falha nas verificações, o time trata isso como trabalho prioritário: corrige ou reverte, conforme o caso. Ignorar um pipeline vermelho por dias destrói sua utilidade como sinal. Testes instáveis também exigem atenção; quando falham aleatoriamente, pessoas começam a desconfiar de todos os alertas. A meta não é exibir um selo verde, e sim ter informação confiável sobre o estado do produto.

Entrega contínua. Além de integrar, a equipe constrói e verifica um artefato que pode seguir até produção por um processo conhecido. Configuração, migração de dados, dependências e operação fazem parte da prontidão. O pipeline pode incluir etapas de autorização humana, desde que o caminho seja reproduzível e a versão continue liberável. Entrega contínua não obriga lançar cada commit ao cliente; oferece essa possibilidade quando fizer sentido.

Implantação contínua. Quando cada alteração aprovada pelo processo é automaticamente implantada em produção, a prática é implantação contínua. Ela requer confiança nos testes, observação e capacidade de responder a falhas. Produção não é sinônimo de exposição universal: uma feature flag pode manter comportamento oculto. A decisão de usar implantação automática depende de risco e contexto, mas uma liberação manual pode ainda coexistir com entrega contínua.

Pipeline de deploy. Uma versão atravessa etapas de confiança crescente. O time deve conseguir identificar qual código e configuração compõem o artefato e reproduzir o procedimento. Testar um pacote e reconstruir outro para produção cria uma diferença que reduz confiança. Automatizar o processo diminui passos manuais sujeitos a erro, mas não corrige um teste que verifica a regra errada nem uma mudança de dados irreversível. Para casos de risco, planeje reversão ou correção antes de liberar.

Qualidade e colaboração. Desenvolvimento, teste, segurança, operação e produto precisam compartilhar a responsabilidade pelo caminho completo. Se o código passa na CI mas espera semanas por validação externa, há integração, mas a entrega não é contínua. O time deve tornar visível onde a mudança para e negociar critérios claros para avançar. Práticas de TDD e testes automatizados podem ajudar, sem serem um requisito nominal para cada mudança.

Métricas. Observe tempo entre mudança e produção, taxa de falha, tempo de recuperação e frequência de implantação conforme o objetivo do serviço. Uma frequência alta sem qualidade não é sucesso. Se o pipeline ficou mais rápido mas a aprovação final continua criando uma fila, o lead time para o cliente pouco muda. Use dados para descobrir onde investir, não para pressionar pessoas a fazer commits sem valor.

CI/CD funciona melhor com mudanças pequenas, responsáveis claros e infraestrutura confiável. Uma organização pode começar por build reproduzível e testes de regras críticas, depois automatizar mais etapas. Não é preciso comprar uma plataforma específica para iniciar. O que importa é a capacidade real de integrar, verificar e liberar com segurança.

Imagine uma equipe hipotética que mantém um serviço de reservas. Antes, quatro pessoas trabalham em branches separadas durante duas semanas. A integração leva três dias, testes manuais revelam um erro na confirmação e o deploy precisa ser adiado. Os números são ilustrativos. O problema não é apenas a duração dos testes: mudanças grandes chegam juntas e fica difícil identificar qual delas causou a falha.

O time passa a integrar recortes pequenos diariamente. Cada integração executa build e testes rápidos. Um segundo estágio testa o fluxo de reserva num ambiente semelhante ao de produção. Quando um teste falha, a equipe corrige antes de acrescentar mais trabalho à base. O artefato aprovado pode ser implantado por um procedimento automatizado, com autorização de produto para expor a nova confirmação.

Numa mudança posterior, o pipeline detecta uma incompatibilidade com o serviço de pagamentos no mesmo dia. A correção leva horas no cenário, e a equipe evita juntar o problema a dezenas de alterações futuras. Isso não garante que nunca haverá incidente: um caso de dados reais pode escapar aos testes. Por isso, o time observa erros após implantação e sabe como desativar ou corrigir o comportamento.

O ganho precisa ser avaliado no serviço completo. Se uma aprovação externa continuar demorando oito dias, a CI pode estar funcionando enquanto a entrega segue lenta. A equipe então usa o fluxo visível para conversar sobre critérios e capacidade de aprovação, mantendo o controle necessário. CI/CD transforma a integração e o deploy em rotina verificável, não em cerimônia de fim de projeto.

Curso K21 recomendado