Integração Contínua

Introdução

O termo “integração continua” originou-se, segundo Fowler [1], com o processo de desenvolvimento Extreme Programming (XP), como uma das suas doze práticas originais. Nesse sentido, Beck [4], um dos criadores do XP, informa que a prática de integração contínua é aquela onde o código é integrado e testado após algumas horas – no máximo um dia de desenvolvimento. Uma maneira simples de fazer isso é ter uma máquina dedicada apenas à integração. Quando a máquina estiver livre, um par com código para ser integrado a ocupa, baixa a versão atual, baixa as modificações (conferindo e resolvendo qualquer colisão) e executa os testes até que eles passem (100% corretos).

Podemos definir Integração Contínua (IC) como um conjunto de procedimentos desenvolvidos pelos membros de uma equipe com a finalidade de integrar seus trabalhos frequentimente, de tal forma que cada pessoa integre pelo menos uma vez ao dia e, no âmbito da equipe, sejam geradas várias integrações por dia.

A maneira como se realiza integração mudou desde a concepção original do XP supracitada, atualmente envolve construir e testar uma aplicação de forma automática e em intervalos freqüentes em um servidor de integração. Os desenvolvedores realizam regularmente commit com pequenas atualizações e são notificados rapidamente se suas modificações provocam falha na build.

O Processo de IC

Paul Duvall, em seu livro Continuous Integration, descreve o cenário acima da seguinte maneira:

●O desenvolvedor envia o código para o controle de versão (SVN, CVS, etc). Enquanto isso a máquina de integração (servidor de Integração Contínua) está
“ouvindo” o repositório buscando por modificações;

● Logo após um commit ser efetuado, o servidor identificará a mudança no código. Inicia-se o processo de build baixando os arquivos do Servidor de Controle de Versão. Assim, o script de build é executado, testes são realizados, relatórios gerados, e todo o projeto é integrado;

●O Servidor de Integração envia por e-mail ou outros dispositivos o feedback sobre o build para usuários específicos do projeto;

●O servidor volta ao estado de Pull buscando por mudanças no repositório;

●Um comportamento importantíssimo: Esta arquitetura força a equipe a manter sempre em funcionamento todo o código fonte que existir no repositório, adicionando mais controle a possíveis problemas de implementação ou integração.

Melhores práticas da Integração Contínua

O mais importante na implantação de um ambiente de Integração Contínua é a mudança no comportamento da equipe. As principais práticas que devem ser postas em execução são, segundo Duvall [6]:

1. Realizar commit frequentemente

Os desenvolvedores membros da equipe devem realizar commit frequentemente. Uma técnica que ajuda nessa prática é executar pequenas mudanças por vez e já enviá-las para o repositório. Dessa forma não há perigo de todos realizarem commit ao mesmo tempo, como por exemplo, se todos deixarem para fazê-lo no final do dia de trabalho.

2. Não realizar commit de código com erros

Não se deve executar commit de código com erros para não comprometer a integração. Um padrão que precisa fazer parte da cultura da equipe é o de realizar build na máquina local e verificar se não há erros, antes de enviar o código para o repositório.

3. Corrigir problemas na builds imediatamente

Builds que apresentam problemas, tais como erro de compilação, falha na execução de testes ou problemas com banco de dados, devem ter prioridade máxima para correção.

4. Escrever testes automatizados

O build deve ser uma tarefa totalmente automatizada. Para que a ferramenta de IC possa executar os testes de forma automatizada é necessário escrever os testes usando um framework como JUnit ou NUnit.

5. Todos os testes deve obter sucesso

Em um ambiente de IC, uma determinada build só deve ter sucesso se todos os testes executarem sem nenhum erro.

6. Evitar retirar código com falhas

Se a build falhou, o desenvolvedor irá perder tempo se retirar o código do repositório. Deve-se esperar pela correção da falha ou ajudar na correção junto aos desenvolvedores que a provocaram.

Comparativo entre as ferramentas disponíveis

Objetivando escolher a melhor ferramenta de integração contínua para utilização na DADT, faremos uma discussão de alguns pontos importantes a serem observados em uma ferramenta de Integração Contínua, são eles: facilidade de uso, maturidade, formas de notificação, integração com ferramentas de build, integração com ferramentas de controle de versão e realização de build distribuido.

Dentre as ferramentas analisadas, escolheu-se as ferramentas mais conhecidas e citadas em diversos artigos, são elas: Cruise Control, Continuum, Hudson e o Team City.

1. Facilidade de instalação, configuração e uso

No quesito de instalação, todas são bem fáceis de instalar. De forma bem sucinta a instalação ocorre como descrito abaixo.

O Cruise Control apresenta uma instalação que já incuí o Jetty Web Server e realiza uma instalação como serviço do Windows.

O Continuum pode ser baixado na forma de arquivo compactado (zip ou tar) e tanto pode ser instalado com o servidor Jetty Web Server e o banco de dados Apache Derby embutidos como também sobre os servidores Tomcat, JBoss, Geronimo ou Glassfish. Na primeira opção, depois de extraídos os arquivos, deve-se executar um script que instala o Continuum como serviço do Windows.

No caso do Team City, a instalação é semelhante aquela do Cuise Control, sendo que após finalizado o processo de instalação, ocorre a instalação de um agente padrão para realizar a build.

Por outro lado, o Hudson é distribuído na forma de arquivo com extensão WAR e tanto permite a instalação nos servidores Tomcat, JBoss, Geronimo ou Glassfish como também a instalação com servidor embutido. Neste último caso, para instalar basta executar o comando “Java –jar Hudson.war”, instalando dessa forma o servidor Winstone embutido.

Todavia no campo da utilização, configuração e administração existem grandes diferenças entre as ferramentas analisadas.

O Hudson, o Team City e o Continuum apresentam a maior facilidade de configuração e uso, uma vez que existe interface web bastante intuitiva que gerencia toda a configuração e administração. Todas elas disponibilizam controle de autenticação e gerenciamento de usuários, todavia o Continuum e o Team City possuem mais opções de papéis que podem ser atribuídos aos usuários.

A configuração do Cruise Control apesar de ser bem flexível é também bastante difícil, uma vez que se deve utilizar um arquivo XML para todas as configurações. Apesar de existir uma ferramenta GUI Swing que tenta automatizar esta tarefa, essa ferramenta gráfica também é bem confusa. Não foi localizado nenhum controle de acesso ou gerenciamento de usuários para o Cruise Control, apenas existe acesso anônimo.

2. Maturidade

Analisaremos aqui o tempo de uso, ou seja, quantos anos as ferramentas estão disponíveis no mercado, bem como a comunidade de usuários que trabalham ativamente nesses projetos.

Nesse sentido, segundo Duvall [3], o projeto mais antigo é o Cruise Control que foi disponibilizado desde 2001. Em seguida temos o Continuum e o Team City que foram liberados inicialmente em 2005 e, por ultimo, o Hudson em 2006.

Quanto à comunidade de desenvolvedores que participam ativamente, de acordo com matriz disponível em [5], temos a comunidade do Hudson como a mais ampla, tendo entre 5 e 10 desenvolvedores no core do projeto e mais de 20 trabalhando nos plugins, em seguida temos a comunidade do Team City, com aproximadamente 5 a 7 desenvolvedores ativos, posteriormente temos o Cruise Control que possui em torno de 5 desenvolvedores e aquela do Continuum que possui aproximadamente 4 pessoas.

3. Formas de notificação

São possibilidades de fornecer feedback para os desenvolvedores sobre suas builds. Estas notificações podem ser feitas, por exemplo, através de e-mail, mensagens instantâneas, blogs, etc.

O Cruise Control, segundo Smart [2], tem como um dos pontos fortes as notificações, oferecendo feedback meio de e-mail, Windows System Tray, Jabber IM, RSS, Logging, Yahoo Messenger e até via blogs.

No que se refere ao Continuum, as possibilidades são e-mail, IRC, Jabber IM e MSN Messenger.

Já o Hudson suporta notificação através de e-mail, IRC (requer instalação de plugin), Jabber IM (requer instalação de plugin), RSS e Windows System Tray.
Por último, temos o Team City que permite envio de notificações via e-mail, Jabber IM, RSS e Windows System Tray.

4. Integração com ferramentas de build

Ferramentas de build permitem automatizar tarefas envolvidas na distribuição de software, como compilação, testes e empacotamento dos arquivos em um formato de distribuição. Dentre as ferramentas de build mais conhecidas estão o Ant e Maven do projeto Apache.

O Hudson oferece suporte nativo ao Ant, Maven, Maven2 e Shell Script e com alguns plugins suporta também o NAnt(.NET) e o Rake (Ruby). Alem do mais, o Hudson permite tanto o agendamento de builds como também possibilita a opção de pull, ou seja, “observar” a ferramenta de controle de versão e disparar buids quando houver modificação no repositório.

Já quanto ao Continuum e ao Cruise Control, observamos que estes trabalham com Ant, Maven, Maven2, Shell Script, NAnt, todos de forma nativa, contudo não oferecem suporte ao Rake (Ruby). O Cruise Control trabalha de forma semelhante ao Hudson, permitindo tanto o agendamento de builds como “observação” do repositório e disparar builds quando da ocorrência de mudanças. No caso do Continuum, este apenas oferece suporte ao agendamento de builds, dessa forma ela é menos reativa que as demais.

E o Team City suporta Ant, NAnt, Maven 1, Maven 2, IntelliJ IDEA project e o Visual Studio 2005 solution.

5. Integração com ferramentas de controle de versão

Sistemas de controle de versão gerenciam as diversas versões de artefatos envolvidos no desenvolvimento de software, bem como mantém um histórico com as modificações efetuadas.

A integração com esses sistemas é outra grande força do Cruise Control já que suporta uma ampla gama de ferramentas, tais como: SVN, CVS, BitKeeper, IBM Rational ClearCase, MKS, Perforce, Serena PVCS, Borland StarTeam, Visual SourceSafe.

Quanto ao Continuum, este oferece suporte aos sistemas Subversion, CVS, Borland StarTeam, Perforce, Bazaar e IBM Rational ClearCase.

No caso do Hudson, existe integração nativa com o Subversion e CVS. A integração com Borland StarTeam, Perforce, Bazaar, MKS, Serena PVCS e IBM Rational ClearCase requer a instalação de plugins.

Para o Team City as opções são o CVS, o Perforce e o Subversion.

6. Build distribuídos

Esta funcionalidade é importante principalmente quando existem builds demoradas, os quais podem ser quebrados e distribuídos entre várias máquinas que são chamadas de agentes.

Neste ponto, apenas o Hudson e o TeamCity apresentam funcionalidades de build distribuídos, contudo o Team City restringe o número de agentes a um número de três.

A seguir apresentamos um quadro que resume os pontos analisados neste documento.

Ferramentas Facilidade de uso e configuração Maturidade Formas de notificação Integração com ferramentas de build Integração com ferramentas de controle de versão Build distribuidos
Cruise Control Apresenta uma instalação bem simplificada. Contudo, sua configuração é difícil e não possui controle de acesso. Liberado em 2001. É a opção mais antiga e com boa base de desenvolvedores ativos. E-mail, Windows System Tray, Jabber IM, RSS, Logging, Yahoo Messenger e até via blogs. Ant, Maven, Maven2, Shell Script, NAnt. Permite agendamento de builds e observação por modificações. SVN, CVS, BitKeeper, IBM Rational ClearCase, MKS, Perforce, Serena PVCS, Borland StarTeam, Visual SourceSafe. Não existe.
Continuum Instalação simplificada. Configuração e uso simples e intuitivos, bem como possui controle de acesso e opções avançadas de papeis para os usuários. Liberado em 2005. Conta com uma boa comunidade de desenvolvedores ativos. E-mail, IRC, Jabber IM e MSN Messenger. Ant, Maven, Maven2, Shell Script, NAnt. Permite só agendamento de builds. Subversion, CVS, Borland StarTeam, Perforce, Bazaar e IBM Rational ClearCase. Não existe
Hudson Instalação mais fácil dentre as ferramentas. Configuração e uso simples e intuitivos, bem como possui controle de acesso simples. Liberado inicialmente em 2006. Possui uma grande comunidade de usuários e muitas opções de plugins. E-mail, IRC (requer instalação de plugin), Jabber IM (requer instalação de plugin), RSS e Windows System Tray. Ant, Maven, Maven2 e Shell Script e, com instalação de plugins, o NAnt(.NET) e o Rake (Ruby). Permite agendamento de builds e observação por modificações. Subversion e CVS e, com a instalação de plugins, o Borland StarTeam, Perforce, Bazaar, MKS, Serena PVCS e IBM Rational ClearCase requer a instalação de plugins. Existe, através de agentes distribuídos.
Team City Instalação simplificada, mas requer ainda a instalação de agente quando finalizada a instalação do servidor. Configuração e uso simples e intuitivos, bem como possui controle de acesso e opções simples de papeis para os usuários. Liberado em 2005. Conta com uma boa comunidade de desenvolvedores ativos. E-mail, Jabber IM, RSS e Windows System Tray. Ant, NAnt, Maven 1, Maven 2, IntelliJ IDEA project e o Visual Stusio 2005 solution. CVS, o Perforce e o Subversion. Existe, através de agentes distribuídos (limitados a três agentes).

Para concluir esta análise comparativa das ferramentas de IC devem-se observar as características específicas do projeto SIEP. Primeiramente, descartou-se o Cruise Control em virtude da complexidade envolvida na sua configuração, que é realizada exclusivamente através de arquivo XML.

Em segundo lugar, depois de estudar com mais detalhes o Team City, chegou-se a conclusão que a licença free da versão Professional possui restrições quanto ao número de agentes que executam o build distribuído, bem como ao número de usuários e de projetos que se limita a 20 (vinte). Sendo assim, optou-se por descartar também o Team City.

Por fim, restaram apenas o Hudson e o Continuum, que são ferramentas open source de ótima qualidade e grande facilidade de uso. No entanto, apesar do Continuum apresentar mais opções de notificação, este é deficiente nos quesitos de build distribuído e opção de build através de “escuta” do repositório por modificações.

Concluindo e tendo em vista todos esses fatos e informações, sugerimos a adoção do Hudson como ferramenta de IC para o SIEP.

Para um comparativo mais amplo, consultar o site da Thought Works [5] que exibe uma extensa lista de funcionalidades das várias ferramentas de IC disponíveis.

Guia de Instalação e Configuração do HUDSON

Guia de Utilização do HUDSON

Referências

1. Fowler, Martin. Continuous Integration. Acesso em 27 de Outubro de 2009, disponível em: http://martinfowler.com/articles/continuousIntegration.html.
2. Smart, John Ferguson. Which open source CI tool is best suited for your application’s environment?. Acesso em 28 de Outubro de 2009, disponível em: http://www.javaworld.com/javaworld/jw-11-2006/jw-1101-ci.html.
3. Duvall , Paul. Automation for the people: Choosing a Continuous Integration server. Acesso em 27 de Outubro de 2009, disponível em: http://www.ibm.com/developerworks/java/library/j-ap09056/index.html.
4. Beck, Kent. Programação Extrema (XP) Explicada. tradução Adriana P.S. Machado e Natália N.P. Lopes. Porto Alegre: Editora Bookman, 2004.
5. Continuous Integration Feature Matrix. Acesso em 03 de Novembro de 2009, disponível em: http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix
6. Duvall , Paul. Introducing continuous integration. Acesso em 27 de Outubro de 2009, disponível em: http://www.javaworld.com/javaworld/jw-06-2007/jw-06-awci.html

  1. Patricia Lopes May 14th, 2013 @ 10:45 | #-49

    Adorei Anderson, excelente post. Se me permitir queria indicar o post de um amigo que eu gostei muito também e me ajudou.
    http://www.devmedia.com.br/integracao-continua-uma-introducao-ao-assunto/28002

  2. anderson May 20th, 2013 @ 11:24 | #-48

    Obrigado. Nas férias vou ver se atualizo o conteúdo pois está defasado.

  3. Pedro Rodrigues Jul 15th, 2013 @ 16:51 | #-47

    Muito bom post, esclareceu bastante.

Submitting Comment, Give me a second...

Leave a comment

 

Allowed tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>
Trackbacks & Pingbacks ( 0 )
  1. No trackbacks yet.