Integração Contínua e Entrega Contínua (CI/CD)

O que é Integração Contínua

A definição origional (Martin Flower, por volta dos anos 2000) é: uma prática de engenharia onde os desenvolvedores integram seu trabalho a uma linha principal compartilhada com muita frequência (pelo menos uma vez por dia) e cada integração é verificada por um build automatizado (incluindo testes) que detecta erros de integração o mais rápido possível.

Certo, mas porque isso existe? qual o problema que resolveu?

O problema é histórico. Quando não há essa prática em times de desenvolvimentos acontece o “Integration Hell” . Times trabalhavam semanas em branches isoladas e só juntavam tudo no fim do ciclo. E como você já deve imaginar, resultava em diversos conflitos de merges de uma vez só, bugs que só apareciam quando o código de todo mundo finalmente se encontrava, e um período de “estabilização” que podia durar semanas.

Fowler então descreveu as práticas que, juntas formam CI de verdade (resumidas e adaptadas para hoje).

• Um repositório único de código-fonte, desse modo, todos os desenvolvedores deveriam trabalhar do mesmo lugar
• Automatizar o build: compilar/empacotar deve ser um comando, nunca um ritual manual com passos documentados numa wiki
• Fazer o build se autotestar: o build inclui rodar a suíte de testes automatizados. “Buildou” sem rodar testes não conta.
• Todo mundo commita na linha principal do dia: branches de feature vivem horas ou poucos dias, nunca semanas
• Toda integração builda a linha principal numa máquina dedicada, não vale “builda na minha máquina”; precisa buildar em um ambiente neutro, repordutível.
• Manter o build rápido, feedback que demora horas deixa de ser útil; o ponto todo é saber do erro em minutos
• Testar em um clone do ambiente de produção, para não descobrir só em produção que algo só funciona em sua máquina
• Tornar fácil pegar o último entregável, qualquer pessoa do time deve conseguir pegar a build mais recente sem caçada
• Todo mundo vê o resultado, status do build é visível pra o time inteiro, não escondido
• Automatizar o deploy: Já é a ponte pro que seção 2 chama de Continuous Delivery/Deployment

Uma peça central que costuma passar batido: CI depende de um jeito de trabalhar chamado trunk-based development — branches de vida curta (horas, no máximo 1–2 dias) que voltam pra main rapidamente. Sem isso, não tem CI de verdade possível: se o código só integra de 3 em 3 semanas, você tem build automatizado, mas não tem integração contínua — é só automação de um processo que continua lento no fundo.

Continous Delivery vs. Continous Deployment (a distinção que quase todo mundo confunde)

As pessoas usam CI/CD como se fosse uma coisa só, mas o “CD” sozinho já é ambíguo. existem duas práticas distintas escondidas atrás da mesma sigla.

	O que garante	Deploy em produção
Continuous Integration (CI)	Todo commit builda e passa nos testes.	Não se aplica — CI para na integração, não decide nada sobre deploy.
Continuous Delivery	O software está sempre em um estado implantável, através de um pipeline totalmente automatizado até staging/pré-produção.	Manual — uma pessoa aperta um botão pra liberar aquela versão específica pra produção, quando o negócio decidir.
Continuous Deployment	Mesma coisa que Delivery, mas vai um passo além.	Automático — toda mudança que passa no pipeline vai pra produção sem nenhuma ação humana.

A diferença entre as duas últimas é só um gate de decisão humana antes do deploy final, tecnicamente o pipeline é idêntico. Delivery é a escolha certa quando existe uma razão de negócio pra controlar o momento do deploy (um lançamento coordenado com marketing, uma janela de manutenção, compliance que exige aprovação humana). Deployment contínuo é pra times que confiam o bastante no pipeline (testes, gates de qualidade, observabilidade) pra deixar ele decidir sozinho.

Os antipadrões que CI/CD resolve

1. "Funciona na minha máquina": o ambiente de build de cada desenvolvedor é ligeiramente diferente (versão de SDK, variável de ambiente, dependência global instalada manualmente), sem um ambiente de build neutro e reprodutível, ninguém tem certeza do que realmente vai rodar em produção.
2. Merge day / "merge hell": integrar semanas de trabalho paralelo de uma vez só produz uma quantidade de conflito que cresce de forma não linear com o tempo de isolamento.
3. Deploy como evento raro e assustador: quando deploy acontece a cada trimestre, cada deploy carrega meses de mudança acumulada — se algo quebra, é quase impossível saber qual das centenas de mudanças foi a causa. Deploys frequentes e pequenos isolam o risco.
4. Servidores "floco de neve" (snowflake servers): ambientes configurados manualmente, únicos, que ninguém consegue recriar do zero com confiança — pipeline como código (infra e deploy descritos em arquivos versionados) é o antídoto.
5. Feedback lento: um bug introduzido numa sexta-feira só é descoberto quando aparece em produção semanas depois — nesse ponto, ninguém lembra mais o contexto da mudança que causou. Quanto mais rápido o feedback, mais barato o bug.

As peças fundamentais de qualquer pipeline (vocabulário universal, antes de qualquer ferramenta específica)

Esse vocabulário vale pra Jenkins, GitLab CI, Azure DevOps, CircleCI ou GitHub Actions, só muda o nome que cada ferramenta dá pra mesma ideia.

• Pipeline: a sequência inteira de estágios automatizados, do commit até (potencialmente) a produção.
• Trigger / gatilho: o evento que inicia a pipeline — um push, a abertura de um Pull Request, uma tag de release, um agendamento (schedule, tipo cron), ou um disparo manual.
• Runner / agente / worker: a máquina (física, virtual ou efêmera) que executa os passos de um job. Pode ser hospedada pela própria ferramenta de CI ou auto-hospedada pelo time.
• Job: um agrupamento de passos que roda inteiro num único runner. Jobs diferentes de uma mesma pipeline normalmente rodam em runners diferentes, em paralelo.
• Step / task: uma ação individual dentro de um job — rodar um comando, restaurar dependências, compilar, etc. Steps de um mesmo job rodam em sequência e compartilham o sistema de arquivos daquele runner.
• Artifact: o resultado produzido por um estágio (um binário compilado, um pacote, um relatório de testes) que precisa passar pro próximo estágio ou ficar disponível pra download.
• Environment (ambiente): onde um artifact é implantado — development, staging, produção — cada um com suas próprias variáveis, segredos e, às vezes, regras de aprovação.
• Secrets: credenciais (chaves de API, connection strings, tokens) injetadas em tempo de execução pela própria ferramenta de CI — nunca escritas no código-fonte.

Como medir se isso está funcionando com as métricas DORA

O DORA (DevOps Research and Assessment, hoje parte do Google Cloud) passou anos de pesquisa comparando times de alta e baixa performance, e chegou a 4 métricas que correlacionam fortemente com desempenho organizacional:

1. Deployment Frequency (frequência de deploy) — com que frequência o time implanta em produção. Times de elite: várias vezes ao dia. Times de baixa performance: uma vez por mês ou menos.
2. Lead Time for Changes (tempo de entrega de mudança) — quanto tempo leva do commit até aquele código estar rodando em produção. Times de elite: menos de um dia. Times de baixa performance: meses.
3. Change Failure Rate (taxa de falha de mudança) — que percentual dos deploys causa um incidente ou precisa de correção emergencial. Contraintuitivo: deployar com mais frequência não aumenta essa taxa — times de elite têm deploys frequentes e baixa taxa de falha, porque deploys pequenos e frequentes são mais fáceis de entender e reverter que deploys gigantes e raros.
4. Time to Restore Service / MTTR (tempo pra restaurar serviço) — quando algo quebra em produção, quanto tempo leva pra voltar ao normal. Times de elite: menos de uma hora.

O ponto central da pesquisa do DORA: essas 4 métricas andam juntas — um time não troca velocidade por estabilidade, bons pipelines de CI/CD entregam as duas coisas ao mesmo tempo.

Como saber a maturidade do processo da sua equipe

• Nível 0 — Manual: build e deploy são processos manuais, sem automação nenhuma, dependem de uma pessoa seguir um passo a passo.
• Nível 1 — Scripts automatizados, execução manual: existe um script que builda/testa, mas alguém precisa lembrar de rodar ele.
• Nível 2 — CI: toda mudança builda e testa automaticamente a cada push/PR, sem intervenção humana — mas o deploy continua manual.
• Nível 3 — Continuous Delivery: pipeline totalmente automatizado até staging/pré-produção; deploy em produção é um clique de alguém, não mais um processo.
• Nível 4 — Continuous Deployment: zero intervenção humana — tudo que passa no pipeline vai pra produção sozinho.

CI (Continuous Integration): cada push ou pull request dispara automaticamente um pipeline que compila o código, roda os testes e valida a qualidade.

CD (Continuous Delivery/Deployment): após o CI passar, o código pode ser entregue automaticamente ao ambiente de staging ou produção.

O ponto central: um código que não passa nos testes nunca chega ao deploy. Isso é um gate automático — sem humano no meio