Dividir, Conquistar e Integrar: Conceitos de integração contínua para testadores ágeis

Como veremos neste artigo, a Integração Contínua tem um papel fundamental no XP, em virtude de que viabiliza e potencializa a utilização de outras práticas propostas pelo XP.

por Cristiano Caetano

O desenvolvimento de software, normalmente é formado por conjuntos de procedimentos, sejam no âmbito gerencial do projeto ou no ponto de vista técnico. Seja como for, os procedimentos que não dão bons resultados, são comumente abandonados e trocados por outras abordagens. No entanto, quando um procedimento dá resultados, ele é reutilizado e aprimorado, tornando-se assim uma prática; ou melhor, uma best practice. Sob esse ponto de vista, podemos destacar a Integração Contínua (Continuous Integration), que é um dos pilares fundamentais do Extreme Programming (XP). Como logo veremos, a Integração Contínua tem um papel fundamental no XP, em virtude de que viabiliza e potencializa a utilização de outras práticas propostas pelo XP.

O XP (Extreme Programming) é um processo simples e ágil baseado no contato direto com o cliente. Os requerimentos são capturados em estórias (User Stories) e o software é desenvolvido em pequenas iterações onde essas estórias são escalonadas. O código é escrito seguindo padrões previamente definidos e pode ser escrito por pares de programadores. Adicionalmente, utiliza-se o desenvolvimento dirigido a testes (por meio da criação de testes unitários antes de iniciar a escrever o código), criando assim um ambiente perfeito para otimização e eliminação de duplicações por meio da refatoração (Refactoring). A partir dessa perspectiva, percebe-se que o Extreme Programming propõe uma infra-estrutura onde o software é desenvolvido em pedacinhos, mas, no entanto, cada pedacinho é submetido a todas as fases do ciclo de vida do software, da concepção ao teste. Nessa estratégia, cada pedacinho construído numa iteração é testado (por testes unitários ou testes de aceitação), viabilizando assim, a identificação e correção dos erros de concepção ou programação (e poupando muito tempo e dinheiro, afinal, quanto mais tarde um erro for detectado, maior será o custo e o tempo para corrigi-lo.

Nesse contexto, a proposta da Integração Contínua é a criação de um ambiente separado e independente do ambiente de desenvolvimento, onde as modificações individuais são unificadas ao projeto principal, o projeto é compilado, os testes são rodados, a documentação é gerada e assim por diante, como pode ser visto na Figura 1.

Figura 1: Integração Contínua

Entre as principais características da Integração Contínua, podemos destacar as seguintes:

• Independência: As tarefas de integração são executadas sem terem que concorrer com outros aplicativos que normalmente estão rodando num computador de desenvolvimento. Além disso, a utilização de um ambiente independente, fomenta o descobrimento de vários problemas, como por exemplo, problemas de dependência (arquivos, dlls, chaves de registro) que fazem o software funcionar no computador de desenvolvimento, no entanto, provavelmente não funcionaria no computador do cliente.

• Freqüência: Quanto mais cedo uma modificação puder ser integrada ao projeto principal e testada, mais cedo os erros serão detectados e corrigidos. A freqüência em que as tarefas de integração serão realizadas, sem dúvida, vão depender do software que estiver sendo desenvolvido. Em certos casos, onde os projetos são pequenos, o processo poderá ser iniciado assim que o desenvolvedor enviar as modificações para o repositório do controle de versões. Porém, quando o software é grande e demoram horas só para compilar, as tarefas de integração deverão ser rodadas à noite ou duas vezes por dia.

• Sincronização: A sincronização das modificações freqüente e contínua serve como um termômetro para identificar a qualidade dos esforços da equipe de desenvolvimento. Além disso, integrações bem sucedidas, elevam a moral de todos os membros da equipe.

• Automação: Entre outros benefícios, a Integração Contínua fornece um meio de automatizar processos manuais e repetitivos, evitando que os processos sejam esquecidos ou que algum passo importante não seja executado. Assim, você poderá realmente ter confiança de que essas tarefas serão realizadas com precisão e consistência todas as vezes que for preciso.

• Simplicidade: Uma vez que todo o processo seja automatizado, qualquer operação poderá ser realizada por meio de um clique do mouse. Ninguém mais precisará encontrar o checklist para realizar a compilação das bibliotecas compradas no ano passado, ou lembrar como se faz para gerar o manual nos formatos desejados, ou até mesmo lembrar como se faz para gerar a instalação do software.

Criando um Processo de Build

É por meio de um processo de Build que as práticas da Integração Contínua são aplicadas. Martin Fowler, no seu famoso artigo chamado "Continuous Integration" [2], destaca as práticas listadas abaixo como as melhoras práticas da Integração Contínua:

• Mantenha um repositório de fontes unificado;
• Automatize o Processo de Build;
• Faça o Build auto-testável;
• Todos devem salvar as modificações (commit) diariamente;
• Cada modificação salva deve gerar um Build automaticamente;
• Garanta que o Build seja rápido;
• Execute os testes num ambiente semelhante ao ambiente de produção;
• Garanta que qualquer um possa pegar o executável do último Build facilmente;
• Garanta que qualquer um possa ver o que está acontecendo;

A partir dessa perspectiva, devemos destacar as ferramentas de Integração Contínua, também chamadas de ferramentas de Automação e Gerenciamento de Build. O propósito destas ferramentas é fornecer um motor para a execução de um workflow com tarefas especializadas para a automação de um Processo de Build. Muitas dessas tarefas especializadas são correspondentes aos itens descritos como as melhores práticas da Integração Contínua, conforme o artigo de Martin Fowler. Por exemplo, muitas dessas ferramentas de Automação e Gerenciamento de Build, oferecem diversos meios para garantir que qualquer um possa ver o que está acontecendo, ou seja, o progresso e o resultado do Build. Essas ferramentas oferecem páginas que permitem que as pessoas possam ver o progresso e o resultado do Build e, além disso, enviam e-mails ou mensagens via MSN ou Gaim para alertar que o Build foi concluído. Por outro, lado essas ferramentas também oferecem interfaces para que dispositivos externos apresentem o resultado do Build. Letreiros eletrônicos [5], Lava Lamps [6] e Orb Lights [7] são alguns dos tipos de dispositivos externos usados para apresentar o resultado positivo (verde) ou negativo (vermelho) de um Build, como pode ser visto no exemplo apresentado na Figura 2.

Figura 2: Dispositivos externos apresentando o resultado de um Build Em termos práticos, você poderá utilizar essas ferramentas de Automação e Gerenciamento de Build para executar as tarefas repetitivas e enfadonhas de integração, sincronização e testes do seu software. Além disso, essas ferramentas oferecem uma oportunidade única de documentar o Processo de Build, afinal, nunca se sabe quando aquele único analista que conhece todos os passos do Processo de Build de cabeça vai abandonar a equipe para trabalhar em outro lugar. Convém lembrar ainda que, além de todos os aspectos mencionados anteriormente, devemos destacar as principais características compartilhadas por todas as ferramentas de Automação e Gerenciamento de Build:

• Amigável: O Processo de Build normalmente é definido por meio de uma Interface Gráfica amigável ou uma sintaxe de alto nível com comandos que são expressos na forma de tarefas que executam ações;

• Extensível: Em virtude da sua proposta, a maioria dessas ferramentas oferece uma arquitetura extensível onde você poderá adicionar facilmente novas tarefas customizadas ou plug-ins conforme a sua necessidade;

• Padrão Aberto: As ferramentas de Automação e Gerenciamento de Build mais utilizadas são open-source. Se elas não atenderem as suas necessidades, você poderá baixar o código-fonte e fazer as modificações necessárias para se adequar à sua necessidade;

Ferramentas de Integração Contínua (Automação e Gerenciamento de Build)

CruiseControl

O CruiseControl (http://cruisecontrol.sourceforge.net/) é a ferramenta de Automação e Gerenciamento de Build mais conhecida. Segundo o site do CruiseControl, o principal objetivo desta ferramenta é oferecer um framework para a o Processo de Build. O CruiseControl fornece um wrapper para o ANT, assim como plug-ins para notificação do progresso do Build via e-mail e acesso a vários tipos diferentes de repositórios de controle de versões. A configuração do Processo de Build do CruiseControl é feita por meio de um arquivo XML, mas no entanto, existe uma ferramenta chamada CruiseControl Config (http://cc-config.sourceforge.net/) que permite você configure o CruiseControl por meio de uma interface gráfica amigável.

Figura 3: Dashboard do CruiseControl com o status do Build

Figura 4: CruiseControl Config

Hudson

O Hudson (https://hudson.dev.java.net/) é uma outra alternativa para a Automação e Gerenciamento de Build. Entre as principais características do Hudson, devemos destacar a facilidade de instalação e a possibilidade de distribuir os Builds para múltiplos computadores diferentes.

Figura 5: Listagem dos Builds existentes

Figura 6: Resultados do Build ao longo do tempo

LuntBuild

O LuntBuild (http://luntbuild.javaforge.com/) é uma outra alternativa para a Automação e Gerenciamento de Build. Entre as principais características do LuntBuild, devemos destacar a interface gráfica amigável e a possibilidade de procurar, categorizar e priorização dos Builds.

Figura 7: Agenda dos builds

Figura 8: Status do Build

Para saber mais…

[1] Testes Extremos - Entenda o papel do testador em projetos ágeis
http://www.linhadecodigo.com.br/artigos.asp?id_ac=1229

[2] Continuous Integration by Martin Fowler
http://www.martinfowler.com/articles/continuousIntegration.html

[3] Continuous Integration Server Feature Matrix
http://docs.codehaus.org/display/DAMAGECONTROL/Continuous+Integration+Server+Feature+Matrix

[4] Automation for the people: Choosing a Continuous Integration server
http://www-128.ibm.com/developerworks/java/library/j-ap09056/index.html

[5] Pragmatic Automation
http://www.pragmaticprogrammer.com/pa/pa.html

[6] eXtreme Feedback for Software Development
http://www.developertesting.com/archives/month200404/20040401-eXtremeFeedbackForSoftwareDevelopment.html

[7] Ambient Orb Ant task
http://www.testearly.com/2006/07/11/ambient-orb-ant-task/

[8] Integração Contínua
http://www.improveit.com.br/xp/praticas/integracao

[9] Realizing continuous integration
http://www-128.ibm.com/developerworks/rational/library/sep05/lee/