Plugins para Integração

Transcrição

1 : : : : Adriano Di Foggi Oliveira (adriano.oliveira@venturus.org.br): é formado em Tecnologia em Processamento de Dados, pela FATEC-SP, e pós-graduado MBA em Gestão de TI, pela UNISA. Trabalha como desenvolvedor desde 1998 e com Java desde Atualmente é analista de desenvolvimento sênior do Venturus Centro de Inovação Tecnológica. Plugins para Integração Contínua com o Hudson Estenda o Hudson com um Post-Build plug-in para exibir resultados de acordo com a sua necessidade. O Hudson é um poderoso servidor de integração contínua open source que trabalha muito bem com sistemas Linux e Windows. Além de fácil utilização e manutenção, a estensibilidade é uma de suas principais características. Neste artigo vamos mostrar uma breve introdução sobre o que é o Hudson, como ele está preparado para integrar e utilizar plugins e aprender a escrever um Post-Build plug-in para imprimir os resultados de uma build de acordo com o nosso interesse. 42 uando a empresa para a qual eu trabalho decidiu implementar a integração contínua, o Hudson foi escolhido como a ferramenta para ser o CI-Server (servidor de integração contínua). No início, as funcionalidades oferecidas pela ferramenta eram suficientes, porém, conforme a sua utilização foi crescendo, novas necessidades surgiram. Para atender a essa nova demanda, iniciamos um estudo sobre como poderíamos estender o Hudson. Durante nossas pesquisas a maior dificuldade foi encontrar documentação que tratasse do assunto e que fosse suficiente para poder escrever os plug-ins que necessitávamos. Longe de ser uma referência única, esse artigo pretende apresentar brevemente o que é o Hudson e como é possível escrever um plug-in aproveitando os recursos oferecidos pelo seu framework. Além disso, vamos mostrar um complemento às instruções do site da ferramenta para criar um post-build plug-in que utiliza os recursos de relatório do Hudson para exibir os resultados da build.

2 Ambientes de Integração Contínua (CI) Com o aparecimento das técnicas de desenvolvimento de software ágeis surgiu a necessidade de obter maior controle sobre o que está sendo produzido e de novos meios para garantir a qualidade do software que está sendo desenvolvido. Tudo isso sem interferir na velocidade de produção. Para atender a esses requisitos foi criado o conceito de integração contínua. Segundo Martin Fowler, Integração Contínua é uma prática de desenvolvimento de software em que os membros de uma equipe integram seu trabalho com frequência, geralmente cada pessoa integra pelo menos diariamente levando a várias integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais cedo possível. Muitos times acham que essa abordagem leva a problemas de integração significativamente reduzidos e permite que uma equipe desenvolva software coeso mais rapidamente. Entre as práticas da integração contínua estão: manter um único repositório de códigos; automatizar a build; construir builds autotestáveis; permitir que todos os desenvolvedores submetam código na linha principal de desenvolvimento; compilar em uma máquina de integração todo o código submetido (onde o projeto deve ter um processo de build rápido); testar o projeto em um ambiente de produção clonado; disponibilizar para qualquer um dos envolvidos no projeto o último executável; publicar o estado do desenvolvimento do projeto e suas métricas de qualidade; e distribuir o produto de forma automática. Hudson O Hudson é um produto livre e open source hospedado no Java. net. Escrito originalmente por Kohsuke Kawaguchi, engenheiro da Sun Microsystems, e lançado em fevereiro de É uma ferramenta de integração contínua escrita em Java. Funciona em um contêiner de servlet, tal como o Apache Tomcat ou o servidor de aplicação GlassFish. O mesmo suporta ferramentas de SCM, jetos em Ant, Maven, bem como shell scripts ou arquivos batch do Windows. Desenhado para o desenvolvimento colaborativo de software pode, também, contribuir com o desempenho individual dos desenvolvedores. Automatiza processos, eliminando tediosas tarefas manuais e diminuindo o tempo de manutenção dessas atividades; centraliza o trabalho no servidor, maximizando o custo-benefício do ambiente de desenvolvimento; melhora a comunicação entre os membros da equipe e faz com que o processo colaborativo seja mais transparente. Igualmente importante, o Hudson protege o projeto e a equipe toda de erros cometidos por um indivíduo. Conforme o time cresce, geralmente aumenta o número de membros com menos experiência e, conforme os módulos são integrados de um número maior de origens, o risco de erros se multiplica. A capacidade de realizar builds rapidamente ajuda os desenvolvedores a detectar erros antes que eles sejam espalhados para outros times e componentes. A configuração dos projetos a serem mantidos no servidor é bem simples e intuitiva. Os projetos são criados como jobs no servidor. Os jobs são compostos por build steps, que podem ser um plugin, uma linha de comando ou um script. A execução de um job é chamada de build. Não existe limites para o número de execuções de um job. Hudson plug-ins Para o Hudson, o termo plug-in pode significar tanto as bibliotecas de extensões funcionais existentes quanto o método para fornecer estensibilidade para desenvolvedores que desejam adicionar novas funcionalidades à ferramenta. Alguns plug-ins podem ser simplesmente adições úteis para o seu processo de criação, enquanto outros, como o SCM plug-in, que implementa o suporte para os podem ser necessários para usar o Hudson com sua configuração. O servidor já possui uma série de plug-ins incorporados que atendem a muitos ambientes de integração, porém sempre podem surgir necessidades específicas. Para esses casos, o Hudson oferece uma interface e um conjunto de classes que permitem desenvolver plug-ins que estendam suas funcionalidades. Um plug-in já existente pode ser estendido ou pode-se criar um plug-in totalmente do zero. O site do Hudson traz uma seção específica sobre extensão. O projeto Sample foi criado para este artigo usando o JDK 6.0 e o Maven (para mais informações sobre o Maven, consulte o artigo Usando o Maven para Melhorar a Qualidade dos seus Projetos na edição 31 da MundoJ). A IDE utilizada foi o NetBeans 6.8, que já possui integração com o Maven e facilita a depuração de projetos do tipo plug-in para o Hudson. O artigo será dividido em duas partes. Na primeira, seguiremos os passos do tutorial do Hudson que terminará com o esqueleto do projeto. Na segunda, veremos como utilizar os objetos do framework do Hudson para gerar o relatório para o plug-in. Criando o projeto Certifique-se que o plug-in group para o Hudson está declarado no arquivo de configuração do Maven, conforme a Erro: Origem da referência não encontrada. Para usuários do Linux ~/.m2/settings.xml, para usuários do Windows %USERPROFILE%\.m2\settings.xml. Listagem 1. Configuração do Hudson no Maven. <settings> <plugingroups> <plugingroup>org.jvnet.hudson.tools</plugingroup> </plugingroups> </settings> Usando o Maven para criar o projeto do plug-in. Crie uma pasta de trabalho (para este artigo criei a pasta /home/ mvn -cpu hpi:create. Isto vai fazer com que o Maven faça o download dos pacotes necessários para a criação do plug-in do Hudson e então perguntará 43

3 : : : : algumas coisas como o groupid (o jargão Maven para o nome do pacote, para este artigo: br.org.venturus) e artifactid (o jargão Maven para o seu nome do projeto, para este artigo: Sample), em seguida, criar um esqueleto do plug-in. Entre na pasta criada com o nome do projeto (artifactid) e verifique que o projeto pode ser compilado: cd Sample mvn package Estes comandos deverão instruir o Maven para novamente realizar o download dos pacotes necessários para a compilação do projeto. Ao término, deverá ser apresentada uma mensagem conforme a Listagem 2. Listagem 2. Resultado da compilação do esqueleto do projeto. [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 14 seconds [INFO] Finished at: Sat Apr 24 15:11:03 BRT 2010 [INFO] Final Memory: 32M/60M [INFO] Estamos prontos para abrir o projeto usando a IDE. Observe que o NetBeans já reconhece o projeto Maven. Source Packages: onde ficam os pacotes contendo as classes do projeto. O pacote criado automaticamente pelo Maven já vem com o nome dado ao artefato. Dentro dele a classe HelloWorldBuilder com o mínimo de código necessário para que o seu plug-in possa fazer um build. Other Sources: onde ficam os recursos do projeto. Entre eles, os arquivos jelly que definem as interfaces do plug-in com o usuário. Os arquivos jelly são mapeados utilizando o mesmo nome de pacote e classe das actions que os utilizarão. Project Files: onde fica o arquivo pom.xml, que é o arquivo utilizado pelo Maven para compilação do projeto. Desenvolvendo o post-build plug-in Os post-build plug-ins são os últimos plug-ins a serem executados pelo Hudson. Ao serem invocados eles têm acesso a todo o workspace criado pelo job com as ações de todos os plug-ins que executaram anteriormente. Um post-build plug-in tem como principal objetivo analisar o resultado das ferramentas executadas durante o build. Dentre outras ações que um post-build plug-in pode executar estão o envio de s, a execução de outro job, o arquivamento dos artefatos gerados e a publicação de relatórios que veremos em mais detalhes. Como o esqueleto de plug-in gerado não é para um post-build plug-in, deve-se remover todos os arquivos gerados automaticamente, inclusive a estrutura de pastas, e inserir as novas classes. Além dos arquivos de código java ainda existem os arquivos de recursos que, para este artigo, é somente o ícone do plug-in e encontra-se em src/main/webapp/images/sample.png. Utilizaremos o esqueleto como ponto de partida. O que é cada arquivo novo e quais as mudanças nos existentes será exibido em cada item que se segue. No final, o projeto deverá ficar conforme mostrado na figura 3. Figura 1. Abrindo o projeto. Analisando o esqueleto do plug-in. O código gerado como esqueleto para o plug-in deverá estar organizado na estrutura apresentada na figura 2. Figura 3. Visão do esqueleto do projeto com as novas classes. 44 Figura 2. Visão do esqueleto do projeto.

4 Project Files No arquivo pom.xml, o elemento <name> foi adicionado para facilitar a visualização do nome do projeto na IDE, mostrado na versão do Hudson para a qual o plug-in está sendo desenvolvido. Listagem 3. Arquivo pom.xml. <project xmlns= xmlns:xsi= xsi:schemalocation= > <modelversion>4.0.0</modelversion> <parent> <groupid>org.jvnet.hudson.plugins</groupid> <artifactid>plugin</artifactid> <version>1.354</version><!--which version of Hudson is this plugin built against? --> <relativepath>../pom.xml</relativepath> </parent> <groupid>br.org.venturus</groupid> <artifactid>sample</artifactid> <version>1.0-snapshot</version> <packaging>hpi</packaging> <!-- get every artifact through maven.glassfish.org, which proxies all the artifacts that we need --> <repositories> <repository> <id>m.g.o-public</id> <url> </repository> </repositories> <pluginrepositories> <pluginrepository> <id>m.g.o-public</id> <url> </pluginrepository> </pluginrepositories> <name>venturus-sample</name> </project> Source Packages Listagem 4. SamplePluginImpl.java. package br.org.venturus; import hudson.plugin; * Ponto de entrada para o plugin. * public class SamplePluginImpl extends Plugin { * Método inicial. Ele é chamado pelo Hudson na inicialização. public void start() throws Exception { load(); Nesta seção se descreve com mais detalhes a interação com o framework do Hudson. SamplePluginImpl A classe SamplePluginImpl é responsável pela inicialização do plug-in e é chamada pelo Hudson na sua inicialização, tendo a responsabilidade apenas de sobrescrever o método start, onde é invocado o método load da superclasse, conforme a Listagem 4. SamplePublisher Pode-se dizer que a SamplePublisher é o core do plug-in. Essa classe que é responsável por disponibilizar o plug-in na página de configuração do job, através da implementação da classe interna DescriptorImpl, que estende a BuildStepDescriptor e ainda recebe a notação Extension, conforme a Listagem 5. O resultado da implementação da DescriptorImpl é mostrado na figura 4. Figura 4. Plug-in publicado na página de configuração do job. A classe SamplePublisher implementa também o método perform, que é invocado durante a build para que o plug-in possa realizar seu trabalho. No método perform, registra-se a action que é responsável por exibir o resultado da execução na lista de actions da build. Neste caso, registra-se a action SampleTestResultAction, que será mais detalhada adiante. O resultado do job é armazenado no objeto SampleTestResult criado pela action SampleTestResultAction durante a build, conforme Listagem 6. Listagem 5. A classe interna public static class DescriptorImpl extends BuildStepDescriptor<Publisher> { * Nome que será utilizado na tela de configuração public String getdisplayname() { return Venturus-Sample ; * newinstance é usado para criar o objeto Publisher para o plugin public SamplePublisher newinstance(staplerrequest req, JSONObject json) throws FormException { return new SamplePublisher(); 45

5 : : : : Cont. Listagem 5. A classe interna DescriptorImpl. Listagem 6. Implementação do método perform. public boolean perform(abstractbuild<?,?> build, Launcher launcher, BuildListener listener) throws InterruptedException, IOException { * Verifica se é aplicável perguntar por um tipo específico de projeto. jobtype o tipo de projeto. true se o tipo de projeto é aplicável. public boolean isapplicable(class<? extends AbstractProject> jobtype) { return true; //vamos notificar no console que o plug-in está trabalhando listener.getlogger().println("[venturus Sample] Executando..."); //precisamos construir um objeto TestResultAction que será responsável //por manusear a manutenção e exibição do resultado do plug-in. SampleTestResultAction sampletestresultaction = new SampleTestResultAction(build); //adiciona esse TestResultAction na build. build.getactions().add(sampletestresultaction); //agora vamos realizar alguma tarefa. dosomework(build); //vamos notificar no console que o plug-in está trabalhando listener.getlogger().println( [Venturus Sample] Fim. ); return true; Durante a execução do job é possível gerar um log do que está sendo executado. O log é exibido no Console Output do job, conforme a figura 5. Listagem 7. Implementação do método gettarget em Sample- TestResultAction.java. public class SampleTestResultAction implements StaplerProxy, Action { // * O objeto que carrega as informações do resultado. private SampleTestResult sampletestresult; Figura 6. Link para o relatório do plug-in. Essa classe é responsável também por manter toda a hierarquia de classes com os resultados da execução. Neste artigo, utiliza-se somente um nível de relatório. O acesso ao objeto para preenchimento do relatório é realizado através do método gettarget(), conforme a Listagem 7. * Retorna o objeto que contém as informações para preencher o relatório. public Object gettarget() { return sampletestresult; * Construtor. build a Build em execução. public SampleTestResultAction(AbstractBuild<?,?> build) { this.sampletestresult = new SampleTestResult( Sample Report ); // SampleTestResult SampleTestResultAction Figura 5. Log no Console Output. A classe SampleTestResultAction é responsável por exibir o link, conforme figura 6, para acesso ao relatório na página do resultado da build. A SampleTestResult é a classe que manterá as informações com o resultado da tarefa executada pelo plug-in durante a build. Estende a classe TestResult, indicando ao Hudson que deverá ser invocada durante o fluxo de mensagens de criação e exibição do relatório. Neste contexto, o Hudson é responsável pela serialização e deserialização dessa classe. Sendo assim, um grande esforço de desenvolvimento é salvo para garantir a persistência dos resultados. Quando o usuário seleciona um link na página de resultado o Hudson irá resolver o objeto responsável por gerar a página solicitada. É através do método findcorrespondingresult que a SampleTestResult define a classe responsável por fornecer os dados para renderizar a página principal do relatório deste plug-in (figura 7). 46

6 Listagem 8. O método findcorrespondingresult. public class SampleTestResult extends TestResult { // public TestResult findcorrespondingresult(final String id) { if (id.equals(getname())) { return this; return null; //... Other Sources Esta pasta deverá conter somente um arquivo index.jelly. Este arquivo é o template para a página HTML do relatório de arquivos do projeto em desenvolvimento, sendo mapeado com a classe br. org.venturus.sampletestresult. O nome deste arquivo deverá sempre ser index.jelly e o nome da package é o nome completo para a classe que ele está mapeando. O seu conteúdo é simples, conforme ilustra a Erro: Origem da referência não encontrada. Listagem 9. Arquivo index.jelly. <j:jelly xmlns:j= jelly:core xmlns:st= jelly:stapler xmlns:l= /lib/layout > <l:layout norefresh="true"> <!--Inclui o painel esquerdo do Hudson na página do relatório--> <st:include it= ${app page= sidepanel.jelly /> <l:main-panel> <h1>sample Report</h1> <p></p> <!--Percorre a lista de arquivos e imprime cada arquivo.--> <j:foreach var="arquivo" items="${it.arquivos"> <p>${arquivo</p> </j:foreach> </l:main-panel> </l:layout> </j:jelly> A propriedade it representa o objeto que contém as informações do resultado que se deseja exibir. Sendo assim, acessamos os seus valores chamando diretamente seus atributos, que serão mapeados para o método get correspondente. Neste exemplo, ${it.arquivos codifica a chamada do método SampleTestResult.getArquivos(). Finalmente, esta marcação é apresentada no ambiente Hudson conforme ilustrado na figura 7. Considerações finais A integração contínua é um conjunto de ferramentas e práticas que permitem a produção de software em uma velocidade superior à encontrada em métodos tradicionais de desenvolvimento, porém sem perder a qualidade. De fato, as ferramentas de integração contínua são agentes que ajudam a promover a qualidade do produto. A otimização dos recursos, a agilidade na comunicação entre os envolvidos no projeto, a facilidade de uso e a flexibilidade do Hudson fazem com que seja o servidor de integração referência do mercado. O Hudson foi concebido para estensibilidade e, embora possua inúmeros plug-ins já embarcados (são mais de 160 plug-ins incorporados à ferramenta), oferece também uma madura interface para o desenvolvimento de novos plug-ins. A gama de serviços realizados pelo Hudson permite aos desenvolvedores estendê-lo para realizar tarefas específicas sem muito esforço. Para que o reúso dos componentes de desenvolvimento de plug-ins seja efetivo, é necessário conhecer as particularidades do framework do Hudson, de forma a não redefinir serviços já existentes. Neste contexto, o projeto deste artigo serve como referência inicial para o desenvolvimento de plug-ins que atendam a necessidades específicas de integração contínua dentro do processo de desenvolvimento da organização. O projeto completo criado para este artigo pode ser Referências nuousintegration.html Continuous integration with Hudson Open source CI server offers easy setup and configuration DEVELOPING SOFTWARE COLLABORATIVELY WITH HUDSON White Paper September 2009 Stephen's Java Adventures Writing a Hudson plug-in Figura 7. Resultado do relatório gerado pelo index.jelly. 47