Em um projeto XP a Integração Contínua deve ser encarada como um importante agente transformador. Ela é o primeiro passo para que o software saia da máquina de um desenvolvedor e apareça na máquina de um cliente para que este o utilize. Na minha visão, a IC afeta diretamente e de forma significativa um projeto XP. Ela pode dizer, por exemplo, o quão rápido será o feedback do seu cliente. Pode dizer também quanto tempo um desenvolvedor terá que gastar para incorporar seu código no sistema e quão confiante o time estará depois de modificações no código, pois este sabe que uma “Successfull Build” é o resultado da passagem do código por vários níveis de checagens. Um integração contínua executa no mínimo três operações básicas: Recupera o código-fonte de seu repositório em sua versão mais atualizada, compila e monta seus diversos componentes e executa todos os testes de unidade sobre esses componentes recém-compilados. Ou seja, nesse cenário, tivemos dois níveis de checagem: compilação e testes de unidade.

De forma geral, uma IC que apenas compila e executa testes de unidade é o suficiente para o seu propósito, que é permitir que os códigos de  vários desenvolvedores estejam sempre sintonizados e funcionando de forma correta. Este processo deve ser simples e rápido o suficiente para ser executado em até 10 minutos. Esta é uma média de tempo que pode ser considerada para a maioria dos projetos. Há projetos em que esse tempo acaba sendo maior. O ideal é que a IC possa acontecer várias vezes por dia e, que os desenvolvedores não precisem ficar parados esperando longos processos de integração.

Ao contrário do que muitos pensam, a IC não precisa ser feita de forma automática. Ela é uma atividade que pode ou não ser feita com o uso de ferramentas. Se, depois de terminar seu trabalho, um par de desenvolvedores sentar em uma máquina, baixar manualmente o código-fonte, compilar esse código e rodar seus testes, tudo de forma manual, ainda assim será um bom processo de IC.

Com o uso de ferramentas de script você pode fazer seu processo de IC se beneficiar do conceito de One-Step Build. Um One-Step Build é um processo que permite a geração de uma build de um sistema por meio de apenas um único passo, que pode ser um click de botão ou a execução de um programa. O próprio script criado se encarrega de rodar todos os passos necessários para a geração da build. Se os passos necessários para execução dessa build passarem por “Obter a última versão do código”+”Compilar”+”Rodar testes de unidade”, este processo de One-Step-Build poderá ser utilizado como apoio para a IC. Há várias ferramentas que podem te ajudar nisso. As mais conhecidas são o Ant, o NAnt, o MSBuild e, mais recentemente, o Ruby Rake (a sensação do momento nesse assunto).

Aqui no nosso projeto, nós usamos com muita satisfação o NAnt e o MSBuild. Ambas as ferramentas são usadas no mesmo processo. O NAnt roda 90% do processo. Deixamos o MSBuild responsável apenas por algumas tasks relacionadas com os processos de compilação e merging da parte web da nossa aplicação, que está em ASP.Net 2.0.

Mas o One-Step Build ainda não é suficiente para reduzir em sua totalidade o que há entre o desenvolvedor e o cliente. Ainda há um vazio entre o resultado da integração contínua e o software efetivamente funcionando no ambiente do usuário.

Depois de integrado, em tese, o software estaria pronto para ser disponibilizado em ambientes diversos para testes ou para uso efetivo de seus usuários. Só em tese mesmo... mas há muito o que fazer ainda. Um software integrado, é um software cujo código-fonte foi validado e checado naquilo que é possível em termos de automação. O compilador checa sintaxe, compatibilidade de tipos e a validade de mensagens enviadas entre objetos. Ainda precisamos checar se os objetos respondem satisfatoriamente às regras e ao propósito para os quais eles foram codificados. Isso é feito com testes de unidade. Mas ainda há um longo caminho a andar para que o software possa estar na máquina de um usuário pronto para ser utilizado e testado. 

Percorrer este caminho, significa ter o que chamamos de One-Step Deployment. Esse é um grande desafio para qualquer equipe de desenvolvimento de software. Pense em todos os passos que você precisa tomar para levar seu software do repositório de código-fonte direto para a máquina do usuário. Atualizar o aplicativo, estruturas de banco de dados, arquivos de configuração, módulos rodando em diferentes máquinas com diferentes tecnologias; considerar restrições de segurança, ambientes distribuídos e, como se já não estivesse complicado, você ainda tem que deixar seu processo informar aos usuários o que foi alterado entre uma versão e outra. Difícil? Sim. É complicado mesmo... Mas o tamanho dos benefícios é proporcional ao tamanho do desafio.  Quando você conseguir executar todos estes passos por meio de um “apertar de botão” você terá alcançado o tão sonhado “One-Step Deployment”.

Em nosso projeto, depois de muito esforço, nós conseguimos chegar a uma solução de Gerência de Configuração em que unimos Integração Contínua com One-Step Build e One-Step Deployment.

Para aqueles que querem conhecer essa solução eu estarei postando semanalmente um overview de todas as etapas que precisamos vencer para chegar a este resultado.

Acompanhe!