Em projetos de software, é muito comum que uma equipe de desenvolvimento seja composta por um grupo de pessoas onde elas, por sua vez, ficam responsáveis pela criação de determinadas User Stories que compõem o projeto. Em adição a isso, é sabido que no dia-a-dia desse desenvolvimento, há momentos em que, por alguma necessidade, é necessário que se altere parte do código que foi escrito anteriormente para que o sistema passe a funcionar de uma nova maneira. Em momentos como esse, surge a grande questão: “Como garantir que esse trecho de código que está sendo alterado não irá quebrar outra parte do sistema?”
Num post anterior, Igor Araújo levantou excelentes pontos sobre os conceitos de Integração Contínua. Para quem quiser saber mais sobre o assunto, a leitura é altamente recomendada. No post de hoje, vamos ver um pouco da prática e de como utilizar no nosso dia-a-dia de desenvolvimento de software. Abaixo, alguns passos sobre o que fazer antes de finalmente ter um sistema continuamente integrado:
1. O que será integrado
Antes de tudo, é preciso ter em mente que a utilização da integração contínua deve estar diretamente ligada ao uso de testes automatizados. Ok, há quem possa dizer que se pode verificar integrações vendo se todo o código do projeto continua compilando, por exemplo, mas acredito que este não é o tipo de verificação que busque solucionar os maiores problemas, visto que este tipo de coisa pode ser percebida no momento do desenvolvimento. Portanto, pensou em integração contínua, pensou em testes automatizados. E quando se pensa em testes automatizados, existem diferentes conceitos e tipos de testes. Alguns dos mais conhecidos e utilizados, são os testes unitários (que vistam testar uma unidade de código, ex.: um método), os testes funcionais ou de integração (que visam testar uma funcionalidade, ex: um cadastro de usuários) e os testes de aceitação ou de interface (que é um teste de mais alto nível que visa testar os diversos fluxos de execução a nível de interface, se for preciso).
Escolhidos os testes, será papel da ferramenta de integração contínua rodar os testes automatizados periodicamente para garantir que todos eles continuam passando.
2. A escolha da ferramenta
A ferramenta de integração contínua é outra escolha que a equipe de desenvolvimento precisa fazer. Há algumas mais fáceis de configurar e outras mais complexas. Umas mais simples e outras mais completas. Enfim, é uma escolha. Entre as mais completas, estão: Continuum, Cruise Control, Hudson, TeamCity e Jenkins. Todas elas com diversas formas de configuração e algumas com possibilidade de utilização de diversos plugins que dão uma visibilidade maior ainda ao executar a integração.
3. Configurações da integração
Após ter feito a escolha da ferramenta que será utilizada, é hora de configurar a integração. Basicamente, é preciso informar à ferramenta o repositório onde o projeto está sendo armazenado (entende-se como repositório a URL onde o projeto está sob um controle de versão, seja ele SVN, CVS, Git, Mercurial ou outro) e um conjunto de tarefas que devem ser executadas para garantir que a integração ocorreu com sucesso. Em geral, criam-se tarefas para a realização do build (quando necessário) e execução de um determinado tipo de teste. Por exemplo, se estamos desenvolvimento um projeto fictício chamado XPTO, criamos uma entrada na ferramenta chamada XTPO-Unit que, de tempos em tempos, irá baixar o código do repositório do controle de versão, executará o build e, após, executará todo o conjunto de testes unitários existentes no projeto. Caso todos os testes passem, nossa integração ocorreu com sucesso. Em caso contrário, não. O fato de separar as entradas por tipo de teste, é apenas uma opção. Esta dica é aconselhável pelo fato de termos geralmente diferentes comandos para executar cada tipo de teste desse e além disso, saber que tipo de teste está acusando uma falha no sistema.
Além das configurações básicas, algumas das ferramentas mencionadas dão a possibilidade de inclusão de plugins que auxiliam ainda mais na integração. Algumas delas como:
– Relatório de cobertura de testes (ou seja, o quanto de seu código está coberto por testes);
– Envio de e-mail (em caso de falha na integração, os desenvolvedores recebem um e-mail com o aviso);
– Integração com o Twitter (mensagens com o status de cada integração realizada), etc.
4. A execução contínua
Configurado todo o esquema de integração, é hora de rodar as tarefas que irão nos dizer se ela foi realizada com sucesso ou não. Algumas ferramentas realizam a integração em intervalos de tempo definidos, outras não. Essas outras, identificam de tempos em tempos, se o repositório de código recebeu algum novo commit, ou seja, se há de fato algo novo no código do projeto que precisa ser testado novamente. Em caso positivo, então a ferramenta executa a integração. Em caso negativo, apenas espera até a nova verificação.
É preciso ter em mente que a utilização da integração contínua no dia-a-dia do desenvolvimento de software requer muita atenção de todo o time. Isto porque o principal intuito de uma ferramenta como essa é, além de garantir a integridade do projeto, dar um feedback rápido sobre a não conformidade de alguma parte dele. Portanto, avisos por email ou por Twitter, são altamente recomendados.
Uma outra forma de dar essa visibilidade de maneira clara, é deixar a tela de resumo de últimos resultados de integração bem exposta aos olhos do time, seja através de uma televisão, monitor ou até mesmo sendo projeto em algum lugar. Essa visibilidade se faz necessária pois é imprescindível que o time de desenvolvimento pare o que está fazendo para identificar o que fez o código “quebrar”. Após a verificação do trecho “defeituoso” e sua correção, o time está apto a integrar novas funcionalidades novamente ao projeto, com a garantia que a última integração foi executada com sucesso. Ferramentas como as mencionadas costumam usar as cores verde (ou azul) e vermelha para identificar o status da integração como sucesso e falha, respectivamente.
Bem, de maneira bem geral, este foi um resumo sobre os passos principais da utilização da integração contínua no dia-a-dia do desenvolvimento ágil de software. Espero poder ter esclarecido alguma dúvida e ainda havendo alguma, é só entrar em contato. Até a próxima!
Muito bom o post!
A parte do texto que chamou minha atenção foi com relação aos testes. Uma das dificuldades que tivemos ao utilizar a integração contínua em um de nossos projetos foi quanto à execução dos testes automatizados, pois estes ainda não estavam funcionando corretamente. Daí ficamos na dúvida se valia a pena ou não configurar o serviço de integração contínua mesmo sem os testes. A estratégia que adotamos foi de acordo com o que foi exposto neste post, pois decidimos realizar os ajustes nos nossos testes e aí sim passar a usar o serviço de integração contínua, pois também acho que “pensou em integração contínua, pensou em testes automatizados”!
Abraço!