Em projetos de desenvolvimento de software é comum encontrarmos equipes nas quais dois ou mais desenvolvedores trabalham sobre um mesmo conjunto de artefatos de software. Segundo a metodologia Scrum, por exemplo, é comum que toda a equipe trabalhe junta na resolução de uma história de cada vez, visando um maior número de entregáveis ao final da Sprint. Uma forma de controlar e juntar as alterações de todos os desenvolvedores é utilizar o controle de versão, que foi o assunto abordado nos posts Vantagens do controle de versão no desenvolvimento ágil e Algumas Boas Práticas no Controle de Versão. Mas e se a implementação de uma nova funcionalidade impactar no funcionamento de uma outra já existente? E se as alterações feitas por diferentes desenvolvedores conflitarem quanto ao funcionamento do sistema? E mais, como realizar este controle em projetos ágeis?
Para isso utiliza-se uma prática de desenvolvimento de software chamada Integração Contínua. Segundo Martin Fowler, Integração Contínua é:
“Uma prática de desenvolvimento de software onde os membros de uma equipe integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver multiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitas equipes acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que uma equipe desenvolva software coeso mais rapidamente.”
Devido à velocidade de desenvolvimento de um sistema segundo alguma metodologia ágil, com o passar do tempo pode se tornar necessário melhorar o design e a legibilidade do código, ou seja, pode se tornar necessário realizar uma refatoração (mais informações sobre refatoração no post A importância da refatoração). Entretanto ao mesmo tempo é preciso que após o processo de refatoração o sistema esteja em perfeito funcionamento. A prática da Integração Contínua identifica imediatamente erros que possam ter sido introduzidos por conta do processo de refatoração, por exemplo.
Não apenas erros no funcionamento do sistema, mas também erros de compilação são alvos da Integração Contínua. Através do build automático a cada commit, a Integração Contínua verifica se o sistema está coeso, se todas as partes do sistema estão “falando a mesma língua”.
Uma prática importante prevista pela Integração Contínua é a execução dos testes automatizados a cada integração. Principalmente em projetos grandes é mais difícil e custoso que cada desenvolvedor fique responsável por executar os testes automatizados localmente em sua estação de trabalho. A prática da Integração Contínua traz agilidade ao processo de desenvolvimento uma vez que tira do desenvolvedor a responsabilidade de executar os testes automatizados (que podem levar horas ou até dias) em sua máquina local, liberando-o para trabalhar diretamente no desenvolvimento do sistema. Além da questão do tempo, vale lembrar que uma vez que os testes automatizados são executados a cada integração, as chances de os testes caírem no esquecimento ou até serem deixados de lado torna-se bem menor, garantindo sempre um produto de qualidade ao longo de todo o tempo de desenvolvimento.
Portanto, a Integração Contínua é uma forma de trazer segurança em relação às mudanças, que são muito comuns em projetos ágeis. Uma vez que alguma alteração no código provoque a quebra do build ou de algum teste, a equipe toma ciência do ocorrido imediatamente, evitando que as mudanças introduzam erros no projeto que está sendo desenvolvido.
Referências:
