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

Integração Contínua com o Hudson

A ferramenta que começa onde o Ant e Maven pararam

Automatize completamente seus builds, testes e outras atividades de desenvolvimento

De que se trata o artigo:

Apresentamos o Hudson, ferramenta de Integração Contínua open source e focada em projetos Java, que se destaca pela facilidade de configuração e uso.

Para que serve:

A Integração Contínua automatiza ersas tarefas que normalmente são executadas aquém do ideal, por exigir muita disciplina para sua realização manual. Em especial, a execução freqüente de builds e testes de integração, e o uso de ferramentas de validação de código / detecção de bugs. Se você já é fã de ferramentas de automação de builds como o Ant ou Maven, que permitem realizar estas tarefas de forma bem organizada, um sistema de IC é a peça que faltava, adicionando funcionalidades que faltam em tais ferramentas.

Em que situação o tema é útil:

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 ersos 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 iniduais 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

ATENÇÃO! A exibição deste artigo foi interrompida.

  #Este é um post fechado

Este post está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!