Nove práticas essenciais que a sua equipe precisa para a realização da integração contínua

O principal erro em integração contínua é a introdução de código novo quando o processo de compilação está quebrado. Se a compilação quebrou, os desenvolvedores responsáveis estão esperando para consertá-lo. Eles identificarão a causa do problema assim que possível e a corrigirão. Se essa estratégia for adotada, o código sempre estará́ na melhor condição para que os problemas sejam resolvidos imediatamente. Se alguém fez um check-in e quebrou o processo de compilação como resultado, a melhor chance de resolver o problema imediatamente é deixar que essa pessoa tente consertá-lo. O pior que pode ser feito nesse momento é introduzir um código não relacionado, pois isso fará a compilação rodar novamente, causando mais problemas.

Como já estabelecemos, um check-in cria uma versão candidata. Funciona como em uma publicação. A maioria das pessoas verifica o trabalho antes de publicá-lo em algum lugar, e com um check-in não é diferente. Queremos check-ins pequenos o bastante para que não tenhamos receio de fazer isso a cada vinte minutos, mas formais o bastante para que pensemos por um instante antes de um deles. Rodar os testes localmente é uma espécie de teste de saúde antes de viajar, por exemplo. É uma forma de garantir que o que acreditamos que funciona realmente o faz.

Quando desenvolvedores estão prontos para parar e fazer um check-in, eles devem atualizar a cópia local com a versão mais recente do repositório. Isso deve gerar um processo de compilação local e a execução dos testes de commit. Somente quando estes observarem resultados positivos, o desenvolvedor estará pronto para fazer o check-in de suas mudanças no sistema de controle de versão.

O sistema de IC é um recurso compartilhado pela equipe. Quando a equipe está usando IC efetivamente, seguindo boas práticas e fazendo check-ins frequentemente, qualquer quebra no processo de compilação é apenas um inconveniente para o time e para o projeto como um todo. Entretanto, quebras são uma parte normal e esperada no processo. O objetivo é encontrar os erros e eliminá-los assim que possível, sem esperar perfeição ou ausência total de erros.

São seis horas de uma sexta-feira e todos os seus colegas estão saindo, mas você acabou de fazer um check-in e o processo de compilação quebrou. Você pode se conformar com o fato de que vai sair mais tarde e tentar corrigi-lo, reverter as mudanças e tentar novamente na próxima semana ou simplesmente sair e deixar a compilação quebrada.

Se escolher a última opção, não se lembrará com clareza das mudanças feitas quando voltar, e demorará bem mais para entender o problema e corrigi-lo. Se você não for a primeira pessoa a chegar para corrigir a compilação, perderá o respeito do time quando seus colegas chegarem e descobrirem que você quebrou a compilação, e que a capacidade de trabalho deles foi comprometida. Se você ficar doente durante o fim de semana e não puder ir trabalhar, pode esperar vários telefonemas para obter detalhes sobre como você quebrou o processo de compilação e como corrigi-lo, ou verá seu commit ser revertido sem a menor cerimônia por seus colegas.

Como descrevemos anteriormente, apesar de tentarmos ser esforçados sempre, todos cometemos erros, e temos certeza de que o processo de compilação às vezes será́ quebrado. Em projetos maiores, isso geralmente acontece todos os dias, embora commits pré-testados aliviem bastante o sofrimento. Nessas circunstâncias, as correções são simples, serão reconhecidas quase que imediatamente e envolvem uma ou poucas linhas. Entretanto, às vezes o problema é bem maior, e não é possível encontrá-lo rapidamente. Há ocasiões em que só́ após o commit percebemos que esquecemos algo fundamental na mudança que foi feita.

Estabeleça uma regra para o time: se o processo de compilação quebrar, tentaremos consertá-lo durante dez minutos. Se, depois de dez minutos, não tivermos terminado, reverteremos para a versão anterior. Dependendo do caso, pode-se permitir uma pequena tolerância. Se você está no meio de uma compilação local, preparando-se para um check-in, por exemplo, permitiremos que continue para ver se funciona. Se funcionar, pode fazer um check-in e, com sorte, a mudança será́ boa; se falhar localmente ou no próximo check-in, voltaremos ao estado anterior conhecido.

Quando você começa a seguir a regra anterior, os desenvolvedores geralmente começam a comentar testes que estão falhando para que o check-in possa ser feito. Esse impulso é compreensível, mas incorreto. Quando testes que foram bem-sucedidos por um tempo começam a falhar, pode ser difícil entender o porquê. Realmente foi encontrada uma regressão? Talvez algo que o teste está assumindo não valha mais, ou a aplicação realmente mudou e a funcionalidade testada está diferente por algum bom motivo.

Descobrir quais dessas condições são aplicáveis requer um esforço considerável, tanto de tempo quanto de pessoas, mas é essencial descobrir o que está acontecendo e corrigir o código (se uma regressão foi descoberta), modificar o teste (se uma das premissas mudou) ou removê-lo (se a funcionalidade não existe mais).

Se você introduz uma mudança no código e todos os seus testes são bem-sucedidos, mas os outros quebram, a compilação ainda está quebrada. Normalmente isso significa que você introduziu uma regressão na aplicação. Já que foi você quem fez a mudança, é sua responsabilidade corrigir todos os testes que não estão tendo sucesso como resultado dela. No contexto de IC, isso é obvio, mas não é uma prática realmente comum em muitos projetos.

Um conjunto abrangente de testes é essencial para integração contínua. O resultado central da integração contínua é possível somente com cobertura excelente de testes unitários (cobertura excelente de testes de aceitação também é essencial, mas esses demoram mais para executar). A única maneira eficaz de obter cobertura excelente é por meio de TDD (Test-Driven Development, ou desenvolvimento guiado por testes).