Integração Contínua

A Integração Contínua é amplamente mal compreendida. Não é apenas um servidor de build. Não é apenas executar testes em cada commit. Essas são ferramentas que apoiam a CI—mas a CI em si é uma prática.

CI de verdade significa:

• Todos fazem commit na branch principal (ou trunk) pelo menos diariamente
• Cada commit dispara uma execução de build e testes
• Se o build quebrar, corrigi-lo é a prioridade máxima
• A branch principal está sempre em um estado implantável

A parte "contínua" é fundamental. Se você está integrando semanalmente, isso não é contínuo. Se você tem branches de funcionalidade de longa duração, isso não é contínuo. CI significa integrar seu trabalho com o trabalho de todos os outros todos os dias, geralmente várias vezes ao dia.

A CI verdadeira requer desenvolvimento baseado em trunk: todos fazem commit na branch principal (frequentemente chamada de "trunk" ou "main").

Isso parece assustador. As pessoas não vão quebrar as coisas? É aí que entra a disciplina:

• Execute testes antes de fazer commit (não quebre o build)
• Faça commit de mudanças pequenas (mais fácil de integrar, mais fácil de corrigir)
• Corrija builds quebrados imediatamente (todos param até que fique verde)
• Use feature flags para funcionalidades incompletas (para que possam ser mescladas mas não ativadas)

Branches de longa duração são o inimigo da CI. Quando você desenvolve em uma branch por semanas, você não está integrando. Você está apenas adiando a integração—e quanto mais você espera, mais difícil fica.

Branch por horas, não dias. Integre diariamente, não semanalmente.

Para que a CI funcione, o ciclo de build e testes deve ser rápido. Martin Fowler sugere a regra dos 10 minutos: o build inteiro, incluindo todos os testes, deve ser concluído em menos de 10 minutos.

Por que 10 minutos? Porque:

• Desenvolvedores precisam de feedback rápido sobre suas mudanças
• Esperar uma hora para saber se você quebrou algo é muito lento
• Builds longos incentivam desenvolvedores a pular a execução de testes localmente

Se seu build demora muito:

• Paralelizar testes
• Usar hardware mais rápido
• Otimizar os testes mais lentos
• Considerar categorização de testes (testes unitários rápidos vs testes de integração lentos)
• Revisar o design dos testes (muito banco de dados? muita rede?)

Algumas equipes executam um subconjunto rápido localmente (testes unitários) e a suíte completa no servidor de CI. Isso é aceitável desde que a suíte completa execute rápido o suficiente para fornecer feedback oportuno.

O build vai quebrar. O que importa é o que acontece em seguida.

A regra: Quando o build quebra, corrigi-lo se torna a prioridade máxima. Todo o resto para.

Isso pode parecer extremo, mas considere: um build quebrado significa que a equipe não pode confiar na branch principal. O trabalho de todos está bloqueado porque eles não podem integrar com segurança. Cada minuto que o build está quebrado é um minuto de risco acumulado.

Quem corrige? Geralmente a pessoa que quebrou. Mas se ela estiver travada, outros ajudam. Um build quebrado é um problema da equipe, não um problema individual.

Como prevenir quebras:

• Executar testes localmente antes de fazer commit
• Manter mudanças pequenas (mudanças menores = menor risco)
• Prestar atenção às notificações de CI (corrigir rápido)
• Não fazer commit e ir embora no final do dia

Algumas equipes usam uma rotação de "xerife de CI"—alguém responsável por observar o build e coordenar correções. Isso previne o efeito espectador onde todos assumem que outra pessoa vai corrigir.

CI é a base para práticas mais avançadas:

Entrega Contínua (CD): Cada commit pode ser implantado em produção. A implantação é uma decisão de negócio, não técnica.

Implantação Contínua: Cada commit que passa nos testes é automaticamente implantado em produção. Nenhuma aprovação humana necessária.

Nem toda equipe precisa de implantação contínua. Mas toda equipe se beneficia da CI. Comece por aí.

Métricas de CI para observar:

• Tempo de build (deve ser menos de 10 minutos)
• Frequência de build (deve ser várias vezes por dia por desenvolvedor)
• Tempo médio para corrigir builds quebrados (deve ser minutos, não horas)
• Cobertura de testes (não é uma métrica perfeita, mas é um sinal)

CI não é apenas sobre capturar bugs. É sobre criar um ritmo onde a integração é entediante, rotineira e segura. Quando a integração é segura, tudo o mais fica mais fácil.