Transcript
Pág 1/20
Integração contínua utilizando Jenkins Lucas Lelis Bezerra, Sônia Santana Curso de Sistemas de Informação – Centro Universitário do Triângulo (UNITRI) CEP 38.411-106 – Uberlândia – MG – Brasil
[email protected]
Resumo: A integração contínua vem sendo utilizada como peça fundamental no processo de acompanhamento a construção de build ’s de forma automatizada. Este artigo tem como finalidade apresentar, de forma prática, uma ambiente de integração contínua guiado pela ferramenta Jenkins, plataforma open source desenvolvida em Java. Também descrever sua origem e através de pesquisas e desenvolvimento de aplicações, demonstrar seus principais recursos e características, atingindo o objetivo que é mostrar as vantagens da construção automatizada de buid’s, monitoração dos projetos e feedback, de forma a garantir mais produtividade através do feedback instantâneo e automação de buid’s para toda equipe. 1. Introdução Para que o desenvolvimento de um projeto possa ser baseado na utilização de metodologias ágeis, faz-se necessário utilizar do conhecimento de quatro tópicos-chave para a engenharia de software: a importância de equipes autoorganizadas que controlam o trabalho que executam; a colaboração e comunicação entre os membros da equipe e entre os profissionais e seus clientes; reconhecer que as modificações representam uma oportunidade; e ênfase na entrega rápida de softwares que satisfaçam ao cliente [FOWLER 2000]. Utilizando destes tópicos, um dos métodos ágeis mais conhecidos e utilizados por equipes pequenas e médias em todo mundo é conhecido como o XP (Extreme Programming), que carrega de forma resumida o conceito de desenvolvimento com mudanças constantes. Extreme Programming (XP), propõe uma série de práticas, e dentre estas práticas esta a Integração Contínua. A prática da integração contínua é definida por Fowler da seguinte maneira: “é uma prática de desenvolvimento de software onde membros de uma equipe integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente” – levando a múltiplas integrações por dia [FOWLER 2000]. Este trabalho apresenta uma aplicação com desenvolvimento acadêmico em Java utilizando da prática de integração contínua com a
Pág 2/20
ferramenta Jenkins, para demonstrar algumas de suas funcionalidades e benefícios.
2. Desenvolvimento de Software No conceito tradicional, metodologia de desenvolvimento de software é um conjunto de atividades e resultados associados que auxiliam na produção de software. Todas as metodologias de desenvolvimento tentam, entre outras coisas, reduzir o alto risco associado ao desenvolvimento do mesmo [CASTRO, 2012]. O cotidiano do desenvolvimento de software apresenta projetos cada vez maiores e mais complexos, entretanto o tempo disponível para a entrega desses sistemas está cada vez menor e com mudanças significativas desde a concepção até a finalização. Neste contexto, as metodologias de desenvolvimento tradicionais não conseguem adaptar-se a essa realidade já que nelas os processos são mais detalhados e exigem maior documentação [PRASS, PUNTEL, 2009]. Assim, a grande variedade de fatores presentes no processo de desenvolvimento utilizando-se métodos tradicionais, fez com que a grande tendência do mercado atual neste segmento viesse a utilizar recursos de metodologias ágeis pelo fato de também proporcionar qualidade, porém com um aumento significativo na produtividade. Neste contexto de aplicação das metodologias ágeis, o destacam-se as ferramentas open source que são financiadas por organizações e pesquisas onde o que é produzido e desenvolvido sempre é disponibilizado à sociedade com a finalidade de aprimorar e acrescentar benefícios às ferramentas de desenvolvimento e gerenciamento de software. Seguindo esta linha, ou seja, de aprimorar seus produtos, as empresas buscam sempre por aplicar em seus processos operacionais conceitos onde possam respaldar as estratégias de gerenciamento de riscos, fortalecimento de sua estrutura organizacional e elaboração e aplicação de métricas.
2.1. Manifesto Ágil No início da década de 1990 desenvolvedores de software decidiram propor novos métodos ágeis para desenvolvimento, pois, há um tempo o sentimento de insatisfação com as metodologias já os perturbavam [PÁDUA FILHO, 2009]. No entanto apenas em 11 de fevereiro de 2001, um grupo de profissionais e pesquisadores de Tecnologia da Informação se reuniu com a finalidade de criar uma mobilização em torno de uma série de valores e práticas de desenvolvimento de software que eles intitularam de Manifesto for Agile Software Development (Manifesto para Desenvolvimento Ágil de Software). Assim, os dezessete presentes assinaram o seguinte manifesto:
Pág 3/20
“Estamos descobrindo maneiras melhores de desenvolver software trazendo-o nós mesmos e ajudando outros a fazê-lo”. Através desse trabalho, passamos a valorizar: Indivíduos e interação entre eles mais que processos e ferramentas; Software em funcionamento mais que documentação abrangente; Colaboração com o cliente mais que negociação de contratos; Responder a mudanças mais que seguir um plano [LUNA, COSTA, MOURA, 2011]. Este manifesto também enuncia os doze princípios de um processo ágil, estes princípios são: P1 – A prioridade é a satisfação do cliente, mediante o rápido e contínuo fornecimento de software que agregue um valor ao negócio. P2 – As mudanças são bem-vindas, mesmo no final do desenvolvimento, principalmente se as alterações darão vantagem competitiva para os nossos clientes. P3 – Fazer entregas freqüentes de software que funcionem a partir de um par de semanas a um par de meses, sempre procurando o menor intervalo de tempo entre as entregas. P4 – As pessoas de negócio (executivos) e os desenvolvedores devem trabalhar juntos diariamente e ao longo de todo o projeto. P5 – Construir o projeto em torno de indivíduos motivados. Fornecer todo apoio necessário ao ambiente do projeto e confiar plenamente na equipe. P6 – O diálogo face a face é a mais eficiente e eficaz forma de comunicar as informações dentro da equipe de desenvolvimento. P7 – Software que funciona é a principal medida de progresso. P8 – Os processos ágeis promovem um desenvolvimento sustentável. Os promotores, usuários e desenvolvedores devem ser capazes de manter um ritmo de trabalho constante por tempo indeterminado. P9 – A atenção contínua à qualidade técnica e ao bom design melhora a agilidade. P10 – A simplicidade é essencial. É preciso saber maximizar o trabalho que não deve ser feito. P11 – As melhores arquiteturas, requisitos e desenhos surgem a partir da própria equipe através de sua pró-atividade e auto-organização (inteligência coletiva e colaborativa). P12 – Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficaz, e ajustar o seu comportamento para alcançar este objetivo [LUNA, COSTA, MOURA, 2011].
Pág 4/20
2.2. Metodologias Ágeis O termo Ágil ou Metodologias ágeis aborda uma nova forma de gestão e desenvolvimento de software, cujo foco para abordagem é o planejamento. O termo desenvolvimento ágil é muito comum quando se diz respeito a metodologias e frameworks que utilizam destes para desenvolvimento de forma iterativa e incremental. Iterativo e incremental consiste em métodos para o desenvolvimento de software que modela em torno de um aumento gradual no processo de desenvolvimento.
Iterativo: o modelo de desenvolvimento iterativo é uma mesclagem dos modelos cascata e prototipação. A idéia consiste em um desenvolvimento incremental, onde a cada etapa surgem novas funcionalidades até a finalização do desenvolvimento. Assim iterações podem ser definidas como passos em um fluxo de trabalho.
Incremental: a definição que pode ser aplicada ao processo incremental consiste na idéia de aumentar gradativamente o âmbito do software, seria a construção do software em pequenas etapas, denominadas incrementos.
No processo de desenvolvimento ágil, as principais propostas utilizadas pelos desenvolvedores são: XP (Extreme Programming), MSF (Microsoft Solutions Framework), SCRUM, FDD (Featura Driven Development). A adaptação de métodos ágeis dentro de uma empresa é uma tarefa desafiadora. Agilidade não é como um mero software que pode simplesmente ser instalado algum dia. A agilidade precisa ser adaptada ao contexto da empresa, incluindo seus aspectos culturais, técnicos e organizacionais [NARAYANAN, 2009]. Uma das vantagens das metodologias ágeis em contraposição às metodologias tradicionais é a flexibilidade que estas possuem quando inseridas em ambientes que têm características como: definição dos requisitos com grande volatilidade (mudanças constantes), onde as equipes são pequenas e os prazos são mais curtos, o que por fim caracteriza a necessidade de um desenvolvimento rápido [LUNA, COSTA, MOURA, 2011].
Pág 5/20
2.3. Integração Contínua Integração Contínua faz parte do que é conhecido como metodologia ágil e é considerada como um dos pilares da agilidade. Trata-se de uma prática que visa solucionar problemas que envolvem a unificação das alterações realizadas na base de códigos fonte de um projeto, em um cenário, onde vários desenvolvedores buscam um mesmo objetivo na elaboração de um sistema. Com o uso do modelo de desenvolvimento ágil, e com updates realizados de forma contínua e diariamente (várias vezes durante o período de trabalho), surge à necessidade de ferramentas de automatização desses build’s e, no mercado, existem várias opções para a realização dessa integração contínua como, por exemplo, as aplicações: Apache Continuum, Apache Gump, Bamboo, Beebox, Bittem, BuildBot, Cabie, Cerberus, Control Tier, Cruise Control, CDash, Draco.net, Hudson, Jenkins, jhBuild, LuntBuild, TeamCity, Selenium, Xvfb, entre outros [DIPPOLD, 2009] e, como princípio básico, cada integração é verificada por uma build automatizada (incluindo testes) para que possíveis erros possam ser detectados o mais rápido possível [FOWLER, 2006]. A utilização da integração contínua não está restrita apenas ao desenvolvimento de grandes projetos. Aqueles considerados pequenos e/ou médios, também podem utilizá-la, seguramente. Nos processos mais tradicionais, a integração era feita depois do desenvolvimento de todas as partes e de forma isolada, o que difere da integração contínua, introduzida como uma das práticas do processo XP (Extreme Programming) que é efetuada depois que cada parte de desenvolvimento é completada, ou mesmo em várias vezes durante a programação em um dia. Isso faz com que a organização tenha a possibilidade de controlar, de forma mais eficaz, o que está sendo feito por todos os desenvolvedores. Assim, para que haja sucesso no processo de desenvolvimento, uma comunicação eficiente e eficaz entre todos os envolvidos (stakeholders) é fundamental para o que o processo seja produtivo. Segundo os conceitos ditos por Martin Fowler [FOWLER, 2006], o processo de integração contínua consiste simplesmente em integrar código fonte, porém hoje em dia é muito discutido este processo de forma automatizada e seus benefícios. Existe um ciclo de desenvolvimento com integração contínua que gira em torno de alguns requisitos definidos por Fowler, que é fazer uma cópia local do repositório conhecida como checkout; desenvolver sua tarefa com testes unitários; atualizar a cópia local com a versão do repositório; montar uma build do projeto e passar por todos os testes (se alto der errado nos testes é preciso corrigir até que a versão esteja sincronizada com a versão principal); guardar suas alterações no repositório através do comando commit; montar uma build a partir de uma máquina de integração garantindo que todas as novas alterações foram submetidas corretamente, de preferência de forma automática com algum programa de
Pág 6/20
integração contínua. Assim, para que seja utilizado desta forma é necessário atentar-se a alguns requisitos que dentre estes citado são os principais:
Possuir um repositório de código fonte, pois a equipe de desenvolvimento precisa deste para manter os históricos de alterações e baixar as versões necessárias, recém-disponibilizadas e atualizadas ou não. Ferramentas como CVS (Sistema de Versionamento Concorrente), Subversion, GIT (Sistema de Controle de Versionamento de Arquivos), RCS (Sistema de Controle de Revisão), Mercurial, Rational ClearCase, entre outras [FILHO, 2009]. Essas ferramentas são conhecidas como ferramentas de gerenciamento de código fonte, gerenciamento de configuração, sistemas de controle de versão e repositórios.
Definição de testes a serem executados para que seja possível validar constantemente a real situação do código, economizando tempo no processo de validações. Para este requisito é importante ressaltar a relevância da utilização de testes automatizados, que podem verificar uma grande parte da base de código com bugs. A prática seria introduzir estes testes no processo de desenvolvimento, a fim de identificar as áreas com mais erros e problemas para expor as falhas.
A existência de build automatizado possibilita que todos os desenvolvedores possam e consigam instalar o projeto e executar os testes em suas estações de trabalho. Esta build é responsável por baixar e instalar as dependências, e compilar códigos-fonte.
Ambiente idêntico ao ambiente de produção para que os testes possam ser executados de forma precisa, e os problemas relacionados a versões de dependências, por exemplo, possam ser evitados antes que o código seja disponibilizado em produção.
A nova versão disponibilizada no diretório de integração trará ao responsável, um feedback instantâneo por meio de e-mails ou até SMS, caso seja adotada tal medida, através da configuração na ferramenta de integração contínua escolhida. Assim, o objetivo da aplicação da integração contínua será atingido, disponibilizando o resultado da versão, conforme é apresentado todo o fluxo na Figura 1. Uma vez que esta versão apresente erros, o problema será detectado e o empenho em solucioná-lo dependerá do desenvolvedor, que deverá disponibilizar uma correção da versão, de modo que não cause nenhum impacto a prejudicar os demais membros da equipe que dependem desta build. Um servidor de integração contínua irá automaticamente recuperar o código fonte do repositório, compilar, testar, empacotar e instalar o projeto, sinalizando qualquer erro que acontecer no processo. Isto ajuda para que o código seja gerado corretamente ou qualquer problema seja identificado cedo [BROWN, 2010].
Pág 7/20
Figura 1. Fluxo Integração Contínua
3. Controle de versão A utilização de um sistema de controle de versão é consideravelmente uma ação importante para que toda a equipe possa trabalhar com o mesmo projeto. Sempre que acontecer qualquer alteração no pacote de código fonte, será retratado ao repositório que fará o controle de versões do projeto. O mais praticado no mercado é que a localização do repositório seja em um servidor. Este servidor é acessado constantemente para realização de Checkouts, Updates, e Commits. Tais operações são aplicadas apenas na pasta do servidor de integração, onde está localizado todo código fonte do projeto, e também pode ser o repositório onde se encontra alguns arquivos de configuração do projeto junto à plataforma e framework. Estes arquivos não devem ser movidos para máquina do desenvolvedor no download do código para desenvolvimento, pois existem particularidades no pacote. O controle de versão apoia o desenvolvimento através de históricos nos quais se registra toda a evolução do projeto, todas as alterações sobre cada um dos arquivos do projeto permitindo saber o que, quando e onde foi feita uma determinada alteração [SOMMERVILLE, 2011].
4. Jenkins A ferramenta de integração contínua Jenkins surgiu de um projeto já existente (projeto Hudson) e mantido por um tempo pela empresa Sun Microsystems adquirida pela ORACLE em 2009 foi transferido para Eclipse Fundation e hoje é mantido pala CloudBess
Pág 8/20
O desfecho desta aquisição feita pela Oracle, foram constantes desentendimentos dos desenvolvedores do projeto Hudson com os novos proprietários sobre a infraestrutura de hospedagem, que cresceu rapidamente sobre o controle do projeto Hudson. Eventualmente, não conseguindo chegar a um acordo com a Oracle, a equipe do projeto bifurcou o código, mudando o nome do projeto para Jenkins, mudou-se a infraestrutura de desenvolvimento para o seu próprio repositório GitHub, e começou a produzir versões da ferramenta Jenkins que foi construída sobre a base de código original Hudson [FIORETTI,2011]. No início de 2011, grande parte da equipe original do projeto Hudson decidiu seguir com o projeto, porém fora das políticas adotadas para a então detentora Oracle. Assim, este grupo de desenvolvedores criou o Jenkins como uma ferramenta open source, cujo código fonte é escrito em Java, disponibilizando a toda a comunidade hoje patrocinada pela CloudBees. Dentre estes desenvolvedores está o renomado e premiado Kohsuke Kawaguchi conhecido como o criador do Jenkins, “a peça chave” [KAWAGUCHI, 2012]. A grande maioria dos desenvolvedores de plugins que antes trabalhavam no projeto Hudson seguiu Kohsuke Kawaguchi e levaram junto 70% dos usuários do Hudson a utilizarem o Jenkins [MOURA, 2012]. Com a quantidade expressiva de plugins disponíveis no portal da ferramenta e de crescente desenvolvimento pela comunidade seguidora, são raros e específicos os casos onde uma organização não encontra algo que a atenda. Nestes casos o desenvolvimento acontece para tratar de alguma regra de negócio mais específica, voltada à necessidade do cliente. A aplicação Jenkins monitora execuções de trabalhos repetidos, como a construção de um projeto de software. Atualmente essa ferramenta concentrase em duas vertentes [KAWAGUCHI, 2012].
Construindo e testando continuamente projetos de software, assim como CruiseControl ou DamageControl. A aplicação Jenkins fornece uma maneira fácil de usar o que é chamado de sistema de integração contínua, tornando mais fácil para os desenvolvedores integrar suas alterações no projeto.
Monitoramento de execuções de tarefas que, por sua vez, são agendadas e configuradas, como por exemplo, a compilação de um projeto e ou a execução de testes automatizados. Jenkins trabalha com uma abordagem qual prioriza as saídas, as informações de retorno referente a cada tarefa pré-determinada, e tudo aquilo que é executado/criado. Assim, essas saídas são mantidas para que possam ser perceptíveis todo e qualquer processo que esteja errado [JENKINS, 2011].
A ferramenta Jenkins é utilizada por equipes de todos os tamanhos, para projetos em uma ampla variedade de linguagem e tecnologias, inclusive .net, Ruby, Groovy, Grails, PHP, e outras, assim como Java.
Pág 9/20
Um fator importante a ser considerado é que a evolução do Jenkins está diretamente ligada à evolução e desenvolvimento dos plugins. Plugins estes que cobrem tudo desde sistemas de controle de versão, construir ferramentas, métricas de qualidade de código, construir notificadores, integração com sistemas externos, interface de personalização, jogos, integração com dispositivos móveis dentre outros. O trabalho realizado para este fim é divulgado tanto no portal da ferramenta jenkins como também nas conferências realizadas pelo então criador do Jenkins, Kawaguchi. A ferramenta Jenkins se integra com Git, SVN, CVS, Maven, Ant entre ouras aplicações que servem para apoiar diversas atividades em ambientes e em tempo de produção de projetos. Uma das vantagens da mesma, é que ela é altamente extensível, pois pode ser configurada para comunicar com diversas outras ferramentas [RAMOS, 2011]. Não somente o processo de instalação do Jenkins, quanto à ferramenta como um todo é muito simples, pois possui uma interface, intuitiva e visualmente atraente. Apesar de para instalação ser um arquivo cuja extensão é em .war, ele engloba um servelet container, assim não precisa instalar um container de aplicações, além de não utilizar um banco de dados, gravando tudo em XML no disco. Outra vantagem diz respeito aos procedimentos de backup que são realizados com muita facilidade; e a desvantagem é que a aplicação fica pesada caso não sejam apagados job’s antigos. Para os desenvolvedores todo o cenário deve conspirar ao seu favor, pois a produtividade fica visível aos coordenadores da equipe. Com a utilização da integração contínua o desenvolvedor terá um feedback referente ao código que subiu conforme definido na configuração de cada Job. A ferramenta Jenkins irá construir uma nova build e, assim, o desenvolvedor e outros membros da equipe poderão saber qual build foi quebrado decorrente de qual alteração. O processo de automatização de build surge de forma a beneficiar o desenvolvimento dia-a-dia. Uma vez que todo o pacote de código fonte esta em um repositório, a ferramenta Jenkins faz uma espécie de checkout deste código para que em meio a configurações específicas os plugins possam controlar todo o código fonte, e também relatórios de testes executados que foram automatizados. Como vantagem deve ser pontuada também a questão de retorno das execuções dos job’s configurados no Jenkins. Os retornos podem ser configurados para serem via e-mail, ou em plugins que fazem com que o retorno seja em SMS ou até postagens em redes sociais, sendo assim, qualquer problema existente na execução após tomar conhecimento do mesmo, é possível realizar as devidas correções antes que outro membro da equipe crie uma nova funcionalidade e gere mais problemas impactando de maneira considerável o projeto. 5. Aplicação da ferramenta
Pág 10/20
Em uma visão geral é possível entender que o processo de integração contínua consiste em unificar partes do desenvolvimento de um projeto para que se atinja um ideal. A junção de tais partes pode ser exemplificada como sendo o produto final. Partindo deste princípio a ideia é que a cada etapa de desenvolvimento seja gerada uma versão do projeto, nomeada como build. Uma versão será gerada a cada construção do projeto, estando a build com falhas ou não. Para compreensão e exemplificação da funcionalidade desta prática ágil foi utilizado: a ferramenta VisualSVN v.2.5.9, para a criação e controle de repositórios de código fonte, a ferramenta TortoiseSVN v.1.7.6 para controlar os arquivos no repositório e a ferramenta Jenkins para criação de alguns job’s, cujo objetivos é manter um projeto no servidor, controlando suas execuções e configurações. Os testes foram realizados sobre códigos de duas origens distintas: a primeira, é composta de três projetos distintos desenvolvidos em Java e a segunda, é composta por alguns códigos disponibilizados pela Apache, utilizados, por sua vez, para demonstração do funcionamento da ferramenta Jenkins. Para que sejam apresentados os feedback’s após execução dos job’s que irão gerar build’s dos projetos em questão a serem configurados na ferramenta Jenkins, é imprescindível que seja atendido aos requisitos mínimos para montagem do ambiente de integração contínua. 5.1. Pré-requisitos Antes de iniciar a montagem e configuração da ferramenta Jenkins, deve-se realizar a configuração do ambiente de integração contínua. Prérequisito:
Possuir a IDE de desenvolvimento Java, Eclipse ou NetBeans;
Possuir instalado a versão mais recente de JDK (Java Development Kit), compatível com o sistema operacional do servidor;
Instalar a ferramenta TortoiseSVN;
Instalar o VisualSVN Server;
Instalar a ferramenta Jenkins;
Instalar o pacote Maven.
5.2. Montando ambiente Após a instalação das ferramentas acima especificados já em posse do código fonte a ser utilizado para a criação dos job’s, é necessário a configuração das ferramentas TortoiseSVN, VisualSVN Server e Jenkins.
Pág 11/20
5.3. Controle de Versão TortoiseSVN Server Para Instalação da ferramenta ToroiseSVN, os procedimentos a seguir são muito simples. Basta se atentar para a versão, que deve ser a mais recente e se o executável de instalação é para sistemas operacionais 32 ou 64-bits. A ferramenta TortoiseSVN foi utilizada para realização do controle de versão de código fonte dos projetos desenvolvidos em Java. Para o desenvolvedor iniciar sua parcela de implementação do projeto é necessário a realização de um Checkout para que a última versão disponibilizada do projeto seja transferida para sua estação de trabalho. Após realizar todas as alterações o desenvolvedor tem a opção de gerar uma build local antes de enviar a versão alterada ao repositório. O fato de gerar uma build local garante que não será disponibilizada uma versão com erros. O comando Commit tem a funcionalidade de salvar a nova versão no repositório de código fonte. Assim como também quando necessário acrescentar um novo documento ao repositório é utilizado o comando Add... + Commit. Na figura 2, são apresentadas as opções de quando já existe uma pasta do projeto sincronizada entre o repositório de códigos e a estação de trabalho do desenvolvedor.
Figura 2. TortoiseSVN
5.4. Controlador de Versão VisualSVN O controle de versão com a ferramenta VisualSVN permite instalar e gerenciar facilmente um servidor de controle de versão totalmente funcional no sistema operacional Windows. Conforme figura 3, o repositório é criado e configurado diretamente pela aplicação e também disponibilizado na web conforme URL apresentada na figura.
Pág 12/20
Através desta URL é possível para realizar o checkout de todo o projeto, utilizando a ferramenta TortoiseSVN para qualquer estação de trabalho, desde que esteja em posse das credenciais de acesso ao repositório.
Figura 3. VisualSVN Server
5.5. Integração contínua com Jenkins Para criação de um servidor de integração contínua utilizando o Jenkins, no portal da ferramenta são disponibilizadas opções para download do instalador para os sistemas operacionais: Windows, Ubuntu/Debian, RedHat/Fedora/CentOS, Mac OX S, openSUSE, FreeBSD, OpenBSD, Solaris/OpenIndiana, Gentoo. Desta forma, após optar pela instalação em um ambiente de sistema operacional Windows foi necessário a realização do download do pacote. A instalação consiste em selecionar o arquivo setup e apenas seguir os passos. A única parte no processo em que é solicitado o preenchimento de uma informação é referente à pasta qual quer que seja criado o repositório Jenkins, onde ficaram as configurações, dependências e job’s (código fonte). Depois de finalizado o processo de instalação foi possível iniciar as configurações que se dão pela própria interface web da ferramenta Jenkins, sendo que os preenchimentos requeridos deverão ser efetivados conforme necessidade de usabilidade para cada servidor. Vale à pena ressaltar algumas configurações que são mais importantes como, por exemplo, o item configuração do sistema onde são apontados os
Pág 13/20
diretórios JAVA_HOME e MAVEN_HOME. A configuração do diretório do Java é necessária ser apontado devido à dependência da ferramenta Jenkins na utilização da JDK. E a configuração do diretório do Maven é necessária a ser apontada devido à utilização das dependências dos projetos criados com Maven. O apontamento destas configurações é imprescindível para que aconteça a geração das build’s.. A configuração do item, gerenciar plugin, pois em alguns casos projetos irão necessitar de um plugin específico como, por exemplo: nos casos de projetos que utilizarem o Maven faz-se necessário a instalação do plugin: Maven Integration plugin. Também para o que diz respeito ao gerenciamento de código fonte, onde na configuração das job’s é apontado o diretório qual foi criada a árvore de repositório do código fonte daquele projeto em questão. Para configuração da ferramenta Jenkins é imprescindível o preenchimento das configurações que foram pontuadas acima. Os demais itens do menu, não menos importantes, serão preenchidos conforme parametrização de utilização definida pela equipe responsável pelo ambiente, manutenção e monitoramento da integração contínua como um todo. Estas configurações implicam diretamente no funcionamento da ferramenta. 5.5.1. Criando um JOB Um Job nada mais é que um trabalho a ser executado pela aplicação Jenkins. É o vulgo módulo gerador de build, é o processo que irá manter o projeto no servidor. Uma vez que o código fonte do projeto esteja disponível no repositório, já é possível configurar um job. Conforme ilustrado na figura 4, é necessário definir em uma etapa inicial de criação, o nome do job e qual tipo será sua estrutura. Dentre estes tipos estão marcados na figura 4 as opções 01 e 02 que foram os tipos de estruturas utilizadas na criação dos job’s para desenvolvimento deste artigo. No item 1, marcado na figura abaixo, o Jenkins construirá o projeto. O projeto poderá ser criado com qualquer sistema de construção que entre os mais utilizados estão o Maven e o Ant; e no item 2, para quando for decidido criar um projeto Maven, qual irá precisar das dependências do Maven.
Pág 14/20
Figura 4. Criando um Job
A segunda etapa de configuração consiste em definições mais específicas de cada projeto, de cada job. Atribuir uma descrição ao job, opções avançadas do projeto, definições sobre gerenciamento de código fonte (repositório de código fonte/ferramenta utilizada), disparadores de construção, construir (se o workspace do projeto possui um arquivo pom.xml), configurações de construção (feedback), ambiente de construção (configuração específica para projetos que utilizam o Maven para construção) e ações pós-construção, que estão relacionadas a funcionalidades a serem executadas por plugins instalados, e ou funcionalidades de testes, arquivamento e feedback. A ferramenta Jenkins irá controlar a geração das build’s conforme definido na configuração do job. A figura 5 ilustra a configuração de disparadores de construção, que nada mais é que, a forma e em qual intervalo de tempo aquele job irá gerar uma build.
Figura 5 – Disparadores de construção
Pág 15/20
Na tabela 1, foram listados os projetos desenvolvidos para os testes a serem utilizados neste artigo sendo que, para os três projetos em questão, a ferramenta TortoiseSVN é que foi configurada para controlar as transações ao repositório de código fonte. A ferramenta Maven foi configurada como sistema de construção das build’s. O cenário envolve a apresentação dos três projetos, sendo que, um sem testes e com resultado de build em falha, outro sem testes com o resultado de build em sucesso, e o último com testes com resultado de build em falha. Tabela 1. Configuração dos projetos PROJETO
CONTROLE DE VERSÃO
TESTE INTEGRADO
EXECUÇÃO BUILD
jsf-scrumtoys
Subversion TortoiseSVN
X
30 * * * *
mavenproject1
Subversion TortoiseSVN
X
30 * * * *
projeto.unitri
Subversion TortoiseSVN
30 * * * *
MAVEN
STATUS BUILD
Falha Sucesso Falha
5.5.2. Monitoramento e manutenção A interface da ferramenta possibilita que seja visto pelo usuário quando um job está ativo ou inativo, se falhou ou retornou sucesso, a estabilidade de execução das construções da build e o tempo de duração da execução, conforme figura 6.
Pág 16/20
Figura 6 – Painel Job’s
Nesta figura é apresentado que o software utiliza de símbolos representados por sol e nuvens, que têm o significado de relatório de clima mostrando o status consolidado das construções recentes. Por exemplo, o Job que possuir a figura do apenas do “sol” significa que nenhumas das construções falharam e já o que possui a imagem de “uma nuvem com raios” significa que todas as construções falharam ou que os testes automatizados não foram executados com sucesso. Para descrição de funcionalidades da ferramenta Jenkins e aplicação de alguns plugins, foram utilizados projetos (código fonte) disponibilizados em repositórios da Apache e projetos acadêmicos desenvolvidos em Java que, por sua vez, estão listados na figura 6 (jsf-scrumtoys, mavenproject1 e projeto.unitri). As duas vertentes de projetos abrangem a finalidade de realizar uma pesquisa para validações e comportamentos da ferramenta Jenkins, conforme já mencionado. Os projetos encontram-se em repositórios, situações e status diferentes, onde a intenção foi justamente sinalizar estes cenários. Para os projetos cujo código fonte disponibilizado pela Apache, foram configurados apenas: caminho de qual repositório foi feito o checkout do código fonte; o intervalo de execução das construções de build’s em disparadores de construção. Para os projetos cujo código fonte foi desenvolvido de forma simplificada para apresentação deste artigo, a fim de contemplar as construções das build’s pela ferramenta Jenkins, as configurações abordadas foram: retorno de notificação referente a build gerada, e o acréscimo dos plugins (Maven Integration plugin, Subversion Plubin).
5.5.3. Construção de build’s
Pág 17/20
Um dos objetivos desse estudo foi fazer com que as construções fossem iniciadas de modo automático, fazendo assim com que o conceito de “automatização de build” fosse exemplificado de modo explícito. A ferramenta Jenkins oferece ao administrador do ambiente de integração contínua a opção de acompanhar todo o processo em tempo real de geração da build do projeto. Apenas acessando a opção “Resultados no Console”, é possível verificar na saída do console que a ferramenta faz uma espécie de scanner em toda árvore de arquivos do projeto. Esta verificação é realizada para identificação de algum tipo de alteração no projeto. Uma vez que o projeto não sofreu nenhum tipo de modificação são acionados os construtores para que o projeto seja compilado. Na figura 7 é apresentado o caso onde é obtido sucesso em retorno da construção.
Figura 7 – Build executado com sucesso
Em cenários onde, decorrentes de alguma alteração a qual fez com que a build fosse quebrada, ou seja, o desenvolvedor realizou o commit no repositório de dados de um código com erros, a build é retornada com falha. O fato de subir uma alteração que comprometa a compilação do projeto ou parte dele ao repositório, faz com que conforme, apresentado na figura 8, seja retornado com erro à construção. É possível obter o retorno de uma build com falha, desde o processo de configuração de um plugin feito de forma incorreta até, como já citado neste artigo, quando um desenvolvedor realiza um commit com código fonte incoerente a última verão disponibilizada no repositório.
Figura 8 – Build executado com erro
Para que uma nova build possa ser gerada através da ferramenta Jenkins, internamente faz-se um checkout do código fonte do repositório
Pág 18/20
configurado na job para o repositório Jenkins, configurado no processo de instalação. Logo após o checkout é executada uma build do sistema, utilizando o Maven como construtor, qual foi definido no processo de desenvolvimento. 6. Considerações Finais A utilização do processo de integração contínua passa a agregar, em uma instituição, a cultura de organização e utilização de metodologias ágeis. Independente da tecnologia adotada, em um contexto geral, tal utilização pode ser abordada como uma quebra de paradigma por ser uma nova técnica de desenvolvimento de software e também pode estar diretamente relacionado à evolução de padrões e qualidade nos processos, pois se trata de um dos requisitos para que seja atingido o level 3 para certificação CMMI. A vantagem de montar um servidor de integração contínua está no controle na geração e construção de build’s. Uma vez que a equipe de desenvolvimento realizar alterações nos códigos fonte disponíveis no repositório, o Jenkins irá acessar conforme configuração na job e o retorno é obtido conforme objetivo da utilização da ferramenta Jenkins. Com a utilização de recursos nativos, é possível identificar a situação do projeto/job e o status da construção e com a utilização de recursos como plugins que controlam testes escritos em código fonte, e também plugins que controlam as gerações das build’s, é possível agregar ao produto final toda uma cadeia de gerenciamento do projeto. 7. Conclusão A visão de feedback de utilização do Jenkins é formada pela opinião de que trata-se de uma ferramenta relativamente estável visto pelo cenário criado neste artigo, onde foram monitorados 09 projetos(03 acadêmicos + 06 disponibilizados pela Apache) completamente distintos e de diferentes tamanhos, com execuções de geração de build simultâneas e também intercaladas. As vantagens vistas durante o período de monitoramento estão ligadas ao princípio de que se a build é executada em um servidor, uma máquina dedicada a tal processo, irá trazer liberdade ao desenvolvedor, pois possibilita a uma equipe de desenvolvedores trabalharem com projetos aleatórios e acompanharem as alterações e construções feitas por toda a equipe durante todo o processo de desenvolvimento daquele projeto. Assim, conclui-se que durante o desenvolvimento de software a utilização de metodologias ágeis mesmo que contraditório entre alguns autores pode ser bem rentável a um projeto quanto à produtividade da equipe. Além disso, a integração das partes é necessária para a redução de conflitos quanto a alterações realizadas, uma vez que apenas quando o desenvolvedor aplicar um commit a uma alteração, que esta será enviada para geração da build. Isto
Pág 19/20
faz com que a entrega do produto final ao cliente esteja conforme escopo do projeto. Como sugestões para trabalhos futuros pode se destacar o uso da ferramenta de integração contínua Jenkins com o plugin Sonar para processos de code review com ênfase em feedback instantâneo, para se avaliar o nível de maturidade no desenvolvimento de software.
8. Referências BERG, Alan Mark. Jenkins Continuous Integration Cookbook, Kindle p. 83 115. Pack Publishing Ltd. Junho 2012. CONTROLE DE VERSÃO. Disponível em
. Acesso em 03 de outubro de 2012. CONTINUOUS INTEGRATION – FOWLER, Martin, (2006). Disponível em < http://martinfowler.com/articles/continuousIntegration.html >. Acesso em 02 agosto 2012. EXTREME PRGRAMMING. Extreme Prgramming: A gentle introduction. Disponível em: < http://www.extremeprogramming.org/index.html >. Acesso em 17 de setembro de 2012. FILHO, Wilson de Pádua P. Engenharia de Software: Fundamentos, métodos e padrões. 3ª Edição, p.435 - 438. LTC – Livros Tecnicos e Científicos, 2009. FIORETTI, Marco. Jenkins Continuous Integration Server: An Essencial Development Tool. Disponível em: . Acesso em 10 de Junho de 2011. INTEGRAÇÃO CONTÍNUA- DIPPOLD, Fábio (2009). Disponível em < http://fabiodippold.blogspot.com/2009/09/integracao-contínua.html >. Acesso em 02 de Março de 2012. INTEGRAÇÃO CONTÍNUA. Disponível em < http://www.softwarepublico.gov.br/5cqualibr/xowiki/integracaoContínua >. Acesso em 06 de outubro de 2012. JENKINS. Disponível em: < http://jenkins-ci.org/ >. Acesso em 22 de abril de 2013. KAWAGUCHI, Kohsuke. Who’s Koshuke?. (2012). Disponível em < http://kohsuke.org/about/ >. Acesso em 29 de setembro de 2012. LUNA, Alexandre José H. O.; COSTA, Cleyverson Pereira; MOURA, Hermano Perrelli (2011).Engenharia de Software Magazine, edição 37, p. 05 – 19. A necessidade de ser ágil – Uma análise crítica sobre novos métodos ágeis. Disponível em: <
Pág 20/20
http://www.devmedia.com.br/websys.4/webreader.asp?cat=48&revista=esma gazine_37#a-3674 >. Acesso em 17 de setembro de 2012. MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT. Disponível em < http://manifestoagil.com.br/principios.html >. Acesso em 08 de outubro de 2012. MOURA, Paulo. Disponível em < http://studiosecret.com.br/blog/development/conhecendo-um-pouco-sobre-ojenkins>. Acesso em 31 de março de 2013. NARAYANAN, Vijay. Traduzido por MARQUES, Marcelo; ANDRADE, Marcelo(2009). Superando os Desafios Técnicos para a Adição de Métodos ágeis nas Empresas. Disponível em < http://www.infoq.com/br/articles/technical-challenges >. Acesso em 15 outubro de 2012. PRASS, Fernando Sartuni; PUNTEL, Márcio Daniel. Controle de código com TFS e VS. .net magazine, DevMedia, ano VI, edição 68, p. 201 – 221. PRESSMAN, Rogers S. Engenharia de Software. 6ª Edição, 59 – 74 .McGrawHill , 2006. RUSS, Miles; PILONE, Dan. Use a Cabeça: Desenvolvimento de software. 1ª Edição, p.212 – 214. Alta Books, 2008. SMART, John Ferguson. Jenkins The Definitive Guide. Creative Commons Edition. O’Really Media,July - 2011, First Edition, p. 195 – 223. Sebastopol. SOFTWARE CARPENTRY – Version Control(2006). Disponível em < http://www.cgl.ucsf.edu/Outreach/bmi280/slides/swc/lec/version.html>. Acesso em 23 de setembro de 2011. SOMMERVILLE, Ian. Engenharia de Software. 9ª Ed.2011, p. 73 - 97. Person/Prentice Hall, 2011.
