Integração Contínua e o processo Agile

Postado em 04. nov, 2008 por Cauê Guerra em Agile

“Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver multiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente.” Martin Fowler

Integração Contínua tornou-se muito importante na comunidade de desenvolvimento de software e isso provavelmente ocorreu devido ao grande impacto causado pelas metodologias ágeis. Em equipes que adotaram tais metodologias (eXtreme Programming, Scrum, entre outras), integração contínua é um dos pilares da agilidade, garantindo que todo o sistema funcione a cada build de forma coesa, mesmo que sua equipe seja grande e diversas partes do código estejam sendo alteradas ao mesmo tempo.

Mas porque fazer Integração Contínua ? Quais os benefícios que isso pode trazer ?

Basicamente, a grande vantagem da integração contínua está no feedback instantâneo. Isso funciona da seguinte forma: a cada commit no repositório, o build é feito automáticamente, com todos os testes sendo executados de forma automática e falhas sendo detectadas. Se algum commit não compilar ou quebrar qualquer um dos testes, a equipe toma conhecimento instantâneamente (através de email, por exemplo, indicando as falhas e o commit causador das mesmas). A equipe pode então corrigir o problema o mais rápido possível, o que é fundamental para não introduzir erros ao criar novas funcionalidades, refatorar, etc. Integração contínua é mais uma forma de trazer segurança em relação a mudanças: você pode fazer modificações sem medo, pois será avisado caso algo saia do esperado.

Mas porque eu não rodo pessoalmente os testes na minha máquina e só então faço o commit?
Simples: seu projeto pode ser tão grande, que os testes (em especial os de aceite) demoram um tempo considerável para serem executados e você não vai querer esperar todo esse tempo a cada commit pra poder continuar a trabalhar. Nesse caso, o recomendado é rodar os testes que envolvem as partes que você modificou e só então commitar, deixando para o servidor de integração contínua o trabalho de realizar todos os testes do sistema e garantir que tudo esteja funcionando. Além disso, não estamos falando apenas de testes, estamos falando de builds completos: a cada commit temos uma versão que teoricamente está pronta para entrar em produção, e isso pode envolver a realização de tarefas que não faríamos se estivessemos só testando, como por exemplo gerar um arquivo .war. O projeto pode ainda ser implantado automaticamente num servidor de desenvolvimento/homologação, e então com isso a cada commit temos o projeto rodando na web instantaneamente refletindo nossas mudanças!

Um outro exemplo interessante é o processo de geração das apostilas dos nossos cursos: a cada commit feito no repositório, o servidor faz o check-out, executa o Tubaina, que transforma o fonte em latex, convertendo o latex gerado em pdf e por fim copiando esse pdf num diretório interno, pronto para impressão na gráfica. Dessa maneira, garantimos que disponibilizamos para nossos alunos o material mais atualizado disponível.
Para tudo isso funcionar, no entanto, é preciso agarrar a idéia de commits pequenos. Fica mais fácil saber onde foi introduzido um erro quando o build quebrar se houveram pequenas mudanças, do que ter de verificar as ultimas 50 classes alteradas no ultimo commit. Outro ponto importante, é garantir ao menos um build limpo, com todos os testes passando, ao final de cada dia. Assim, teremos software pronto para entrar em produção tão cedo seja necessário.

Em outras palavras, podemos descrever Integração Contínua como integração automática com processo de build automático e que roda testes de forma automática e automaticamente detecta falhas em cada pedaço.

Abaixo as ferramentas que usamos aqui na Caelum:

  • CruiseControl.rb: desenvolvida pela ThoughtWorks, é a aplicação de integração contínua. Capaz de constantemente verificar os repositórios em busca de novos commits, fazendo check-out e rodando tarefas pré-determinadas. O interessante dessa ferramenta é que ela trabalha com qualquer tipo de projeto: ruby, java, ou qualquer outro cujo build possa ser feito através da linha de comando. Além disso, tem sua interface extremamente simples e funcional :) .
CruiseControl.rb

CruiseControl.rb

CruiseControl.rb build report

CruiseControl.rb build report

  • CCMenu, ou CCTray: permite acompanhar o build de cada projeto sem ter de entrar no site do CruiseControl.rb. Isso é feito através de um ícone alertando quais projetos estão com o build quebrado.
  • Selenium: também desenvolvida pela ThoughWorks, provê maneira de realizar testes de integração em projetos Web, simulando a navegação do usuário pelas páginas do site, realizando diversas ações como clicar o mouse, prencher campos, etc… Usado para validar se o resultado de determinadas ações do usuario correspondem às que esperamos.
  • Xvfb: Servidor X11 que permite realizar todas as operações gráficas em memória, não exibindo nada na tela. Com essa ferramenta, é possível rodas os testes com Selenium sem ter as janelas do Firefox pulando na tela do nosso servidor a cada teste. Além disso, podemos rodar os testes mesmo em ambientes sem X instalado (como é o caso de servidores, por ex).

Ainda usamos plugins Maven e Ant para a geração de relatórios de cobertura e testes, que publicamos a cada novo build. Assim, conseguimos além de garantir que o código está todo integrado, garantir que está com uma cobertura adequada; afinal, de que adianta ter o sistema sem testes falhando, se ele possui menos testes que o necessário?

JUnit Report

JUnit Report

Cobertura Report

Cobertura Report

Por fim, pela experiência que temos no uso dessas ferramentas no desenvolvimento de aplicações internas, open source e em nossos clientes, podemos afirmar que elas de fato nos trazem uma produtividade antes inalcançável. Se você pensa em começar a utilizar alguma ferramentas de integracão contínua, vale a pena dar uma olhada nessas que indicamos. No entanto, existem várias outras disponíveis, e é questão de escolher a que melhor se adapta às suas necessidades. Não deixe de comparilhar suas experiências…

Cauê Guerra

Tags: , , , , ,

22 Respostas para “Integração Contínua e o processo Agile”

  1. Fabrício Lemos

    04. nov, 2008

    Cauê,

    Vocês estão satisfeitos com o CruiseControl.rb? Uns dois ou três anos atrás troquei o CruiseControl (não era esse .rb) pelo Luntbuild porque na época a interface dele era muito pobre.

    Agora estou querendo dar uma olhada com mais cuidado no Hudson. Você chegou a comparar essas outras ferramentas?

    Uma outra verificação que gosto de fazer, fora a cobertura, é se existe alguma violação do checkstyle. Existe também um plugin do maven para essa verificação.

  2. Tapajós

    04. nov, 2008

    Para projetos Rails você já experimentou o Integration Plugin?

    http://integration.rubyforge.org/

  3. Fabio Kung

    04. nov, 2008

    Fabrício, o CruiseControl.rb é BEM diferente do CruiseControl original. ;-)

  4. Cauê Guerra

    04. nov, 2008

    Fabrício,
    Estamos muito satisfeitos! Como o Fábio disse, o CruiseControl.rb NÃO é o CruiseControl (já experimentamos tb, e não gostamos). Chegamos a olhar sim o Hudson, mas o CruiseControl.rb era tudo o que procuravamos: interface simples e configuração trivial.

    Quanto ao plugin de checkstyle, não costumamos utilizar.

    Tapajós,
    Não conhecia o Integration Plugin, vou dar uma olhada. Valeu pela dica!!

  5. Fabrício Lemos

    05. nov, 2008

    Valeu pelo feedback. Vou dar uma olhada no CruiseControl.rb também.

    Vocês rodam a cobertura para testes do selenium? Ou somente para testes de unidade?

    Nunca consegui uma maneira simples de combinar maven + selenium + cobertura.

  6. Cauê Guerra

    05. nov, 2008

    Rodamos tb sim! Tanto em Ant quanto em Maven

    Qual tem sido seu problema?

  7. Fabrício Lemos

    05. nov, 2008

    Os plugins do cobertura e do emma do maven não funcionaram. O do cobertura só se encaixa na fase test e não na integration-test. O do emma não existe nem uma documentação mínima. Vocês estão utilizando algum plugin?

    Uma saída seria chamar tasks do ant pelo maven, mas ainda não me aprofundei nessa alternativa.

  8. Rodrigo Yoshima

    14. nov, 2008

    A gente poderia contratar um chinês que fala portugues e entende de tecnologia para automatizar os testes das apostilas. Ele (o chinês) fica ligado ao servidor, assim que ocorre um commit ele lê a apostila inteira e se tiver qualquer problema:

    BUILD FAILED….

    eh eh eh he he

  9. Fabio Kung

    17. nov, 2008

    Ei, sou meio chinês e falo português! :-P

  10. Rodrigo Yoshima

    28. nov, 2008

    Mas você é caro!!! Estou falando dum chinês legítimo… da china… e que custa só centavos por hora… he he he he he

  11. Daniel Cukier

    16. dez, 2008

    Ótimo resumo sobre o assunto. Fizemos uma versão em vídeo no blog da Locaweb:
    http://agilblog.locaweb.com.br/2008/12/16/integracao-continua/
    Valeu!

Trackbacks/Pingbacks

  1. Jeveaux’s Weblog » Arquivo » Xvfb: Como usar o Selenium sem ter um X Server - novembro 11, 2008

    [...] ou um push ou até mesmo uma integração para build. Com isso vem a idéia de um servidor de integração contínua onde todos os testes serão executados automaticamente do jeito que você desejar: a cada [...]

  2. Metodologias Ágeis de Desenvolvimento » Blog Archive » Integração Contínua - dezembro 16, 2008

    [...] os vídeos e lendo alguns posts sobre assunto, como o do Martin Fowler, o da ImproveIt e o da Caelum. Bons [...]

  3. Integração Continua - Builds rápidos com Grids e paralelismo | blog.caelum.com.br - fevereiro 9, 2009

    [...] já comentamos em um post anterior, aqui na Caelum fazemos a Integração Contínua das nossas aplicações, com a ajuda de algumas [...]

  4. Integração contínua: deploys e aprovações sem dor de cabeça para o cliente | blog.caelum.com.br - janeiro 18, 2010

    [...] 2008 comentamos sobre a importância de integração contínua no processo de receber feedback rápido sobre suas mudanças em um sistema e depois sobre os [...]

  5. Como você define qualidade de software? - fevereiro 14, 2010

    [...] http://blog.caelum.com.br/2008/11/04/integracao-continua/ [...]

  6. Dicas Locaweb » Blog Archive » Integração Contínua - maio 10, 2010

    [...] os vídeos e lendo alguns posts sobre o assunto, como o do Martin Fowler, o da ImproveIt e o da Caelum. Bons [...]

  7. Deploy Contínuo – Entrega contínua de valor « Agile no mundo real - julho 6, 2010

    [...] Deploy Contínuo – Entrega contínua de valor 6 06UTC julho 06UTC 2010 Desde 2005 ajudo com o desenvolvimento de um produto interno que teve sua segunda versão criada em 2008. Até então utilizávamos práticas de extreme programming, como programação pareada, testes, integração contínua e build automatizado. [...]

  8. Integração Continua – Builds rápidos com Grids e paralelismo | blog.caelum.com.br - fevereiro 2, 2011

    [...] já comentamos em um post anterior, aqui na Caelum fazemos a Integração Contínua das nossas aplicações, com a ajuda de algumas [...]

  9. Diferentes ambientes: Development, Testing, Staging e Production | Klaus Laube - março 7, 2011

    [...] Embora testes unitários e de aceitação sejam amplamente executados em ambiente de desenvolvimento, quando o projeto ficar gigante, executar todos os testes do projeto a cada nova feature desenvolvida pode lhe consumir muito tempo. Neste caso é interessante você construir um servidor de integração contínua. [...]

  10. Integração contínua de projeto Java com Jenkins | blog.caelum.com.br - abril 26, 2012

    [...] bastante tempo aplicamos e escrevemos sobre integração contínua, uma das práticas mais importantes do desenvolvimento ágil. Através dela, é possível [...]

  11. Integração contínua com o Jenkins – Desenvolvimento Ágil de Software - janeiro 15, 2013

    [...] do desenvolvimento ágil. Caso nunca tenha ouvido falar sobre integração contínua, leia este post no blog do pessoal da [...]

Deixar uma Resposta