Artigo Java Magazine 62 - Integração Contínua com o Hudson

Se o leitor já visitou sites de projetos open source high-profile, como os projetos da Fundação Apache, Fundação Eclipse ou da Java.Net, já observou a operação de sistemas de Integração Contínua, que coordenam desde a geração de “builds noturnos” até a atualização de sites dos projetos contendo diversos relatórios – tudo em tempo real, sem nenhuma intervenção humana. Mas se você acha que é muito difícil fazer algo parecido para seu projeto (seja qual for o tamanho do projeto), pode estar enganado.

O leitor que acompanha a JM está bem informado sobre ferramentas para teste, automação de builds, metodologias ágeis e afins – temas que cobrimos com freqüência e desde nossas primeiras edições. Já a Integração Contínua (IC) é uma evolução mais recente, que vem complementar todas as outras técnicas e ferramentas nesta área.

Este artigo introduz o Hudson, ferramenta de IC desenvolvida por um projeto open source da Sun. Vamos guiar o leitor pela instalação, configuração e uso do Hudson, mostrando suas vantagens e funcionalidades.

Integração Contínua

Uma metodologia de desenvolvimento orientada a testes (TDD), ou mesmo qualquer metodologia séria, presume que o código seja testado e que o resultado desse teste alimente o processo, guiando correções e melhorias do código. Mas na prática isso nem sempre é feito de forma tão completa quanto desejável, pois o desenvolvimento, execução e análise de testes é uma atividade que também exige esforço – e pior, é uma atividade tipicamente repetitiva, que exige uma grande disciplina (ou profissionais dedicados) para garantir que sempre será executada. Devemos considerar que em muitos projetos, essa atividade de teste pode ser bem mais complexa do que simplesmente clicar um botão que dispara uma test suite “Testa Tudo” do JUnit.

Alguns fatores que complicam os testes em projetos de médio a grande porte são:

• Há um número muito grande de testes, o que torna a execução de todos os testes uma tarefa muito demorada para exigir sua repetição rotineira (ex.: antes de cada commit no repositório);
• Há alguns testes individuais cuja execução é muito demorada, por exemplo, testes que exigem a manipulação de grandes volumes de dados numa database;
• A execução dos testes exige procedimentos de preparação demorados, como fazer um checkout “limpo” do repositório, carregar uma database de teste, e fazer deploy de vários EARs;
• A execução de todos os testes exige uma grande quantidade de infra-estrutura – por exemplo, um servidor Java EE, mais um servidor JMS, mais um SGBD, mais uma aplicação externa à qual o sistema se integra... softwares que precisam estar instalados, em execução, e talvez dedicados ao teste. Alguns desses softwares podem ser complexos de configurar, ocupar muitos recursos do sistema, ou exigir novas licenças para cada instalação. Pode ser inviável exigir que toda essa infra seja disponibilizada nas máquinas de cada desenvolvedor.

Para resolver estes problemas, surge a idéia de um “servidor de testes”. O conceito é simples. Primeiro, os desenvolvedores não precisam arcar com todo o peso da rotina completa de testes. Podem executar apenas os testes unitários das funcionalidades afetadas pelas suas alterações. Feito isto, o desenvolvedor pode fazer commit das suas alterações no repositório de versões do projeto.

Existirá um servidor de testes que, periodicamente, verifica o repositório. Quando há novidades, o servidor faz um novo checkout, compila o projeto, e executa os testes. Todos os testes: unitários, funcionais, de integração, de carga / desempenho – todos os que forem automatizados. Se houver alguma falha de testes, o servidor gera alguma notificação ou relatório para os desenvolvedores.

Podemos ver claramente algumas vantagens neste sistema:

• Nenhum desenvolvedor precisa interromper seu trabalho para aguardar a execução de testes demorados. Basta rodar os testes unitários mais “essenciais” (que testam especificamente o código que foi alterado), fazer o commit, e seguir trabalhando;
• Não há redundância de esforço ou recursos de teste. Um único computador fica carregado com a carga da execução dos testes. Os softwares de infra-estrutura de teste só precisam ser instalados, configurados e administrados nesse único servidor de teste. (Ou no caso de empresas com muitos projetos, um pequeno número de servidores.);
• Não há dependência da disciplina (ou paciência) dos desenvolvedores. Nenhum bug passa despercebido porque “eu estava atrasado para a deadline, não tinha como interromper meu trabalho a cada quinze minutos para rodar uma enorme bateria de testes”.

Os softwares que implementam essa funcionalidade de “servidor de testes” são chamados sistemas de Integração Contínua (I.C.). Integração devido ao foco de tratar o projeto como um todo: realizando a compilação de tudo, teste de tudo, análise de tudo – em oposição aos desenvolvedores que, tipicamente, só testam e se preocupam com a parte do projeto na qual estão trabalhando. Contínua devido ao funcionamento cíclico que descrevemos: basicamente o servidor de I.C. fica num loop infinito, aguardando novos commits do projeto e repetindo eternamente todos os testes. Não só testes, aliás, mas também uma grande variedade de outras atividades de construção, como a execução de ferramentas de validação de código ou geração de artefatos de distribuição.

Instalando o Hudson

Não terminamos os conceitos, mas vamos logo à prática para tornar as coisas concretas. Comece instalando a versão mais recente do Hudson (ver ...