Baixe Integração Contínua utilizando Jenkins e outras Trabalhos em PDF para Informática, somente na Docsity!
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 lelis.lucas@gmail.com
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 auto- organizadas 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
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:
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].
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
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
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 concentra- se 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.
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.
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.
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.
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
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
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
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 -
- Pack Publishing Ltd. Junho 2012.
CONTROLE DE VERSÃO. Disponível em <http://www.softwarepublico.gov.br/5cqualibr/xowiki/controleVersao >. 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: <http://www.openlogic.com/wazi/bid/188132/Jenkins-Continuous-Integration- Server-An-Essential-Software-Development-Tool>. 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
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: <
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
MOURA, Paulo. Disponível em < http://studiosecret.com.br/blog/development/conhecendo-um-pouco-sobre-o- jenkins>. 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 .McGraw- Hill , 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.
