Integração Contínua e o processo 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…

24 Comentários

  1. Fabrício Lemos 04/11/2008 at 07:33 #

    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/11/2008 at 08:11 #

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

    http://integration.rubyforge.org/

  3. Fabio Kung 04/11/2008 at 09:39 #

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

  4. Cauê Guerra 04/11/2008 at 11:12 #

    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/11/2008 at 00:59 #

    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/11/2008 at 02:55 #

    Rodamos tb sim! Tanto em Ant quanto em Maven

    Qual tem sido seu problema?

  7. Fabrício Lemos 05/11/2008 at 04:57 #

    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/11/2008 at 05:48 #

    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/11/2008 at 11:05 #

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

  10. Rodrigo Yoshima 28/11/2008 at 02:14 #

    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/12/2008 at 06:09 #

    Ó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!

Deixe uma resposta