Software Just in Time

Há algumas semanas eu comentei aqui que estaria apresentando um overview do processo de Integração Contínua que idealizamos e criamos no nosso projeto. Neste artigo, vou apresentar o “The Whole Picture” do processo da forma como ele foi desenhado. Ou seja, como ele está arquitetado para à partir de um check-in do desenvolvedor, disponibilizar a aplicação para uso imediato pela área de qualidade e também, disponibilizar arquivos de instalação para testes e deploy nos clientes. 

O nosso processo de build nada mais é do que um emaranhado de aplicativos e ferramentas, cada um com seu propósito, que nos permite customizar todos os procedimentos e checagens necessárias para um incremento de versão mais seguro em nosso aplicativo. Mas atenção! Este não é um processo que pode ser copiado integralmente para outros projetos. Um processo de build é muito dependente do ambiente em que ele ocorre e do sistema ao qual ele está agarrado. Cada projeto precisa de suas próprias rotinas para validação e geração de artefatos. Uma idéia geral é apresentada nesse post para que você possa seguir seu próprio caminho na hora de projetar seu processo de Integração Contínua.

Características do Processo

• Usamos 100% de ferramental open-source e freeware (apenas o banco de dados é proprietário: MSSql Server);
• Há vários pequenos aplicativos desenvolvidos internamente por nossa equip para atender partes específicas do processo;
• Há duas versões do processo que nós identificamos como RTM e Mainline. Cada uma se aplica a um branch de código diferente. A RTM se refere à versão de produção do nosso sistema, já à Mainline se refere à versão que está em desenvolvimento. Essas duas versões podem se diferenciar na ordem em que os procedimentos são executados, na maneira que ele é executado e também se determinado procedimento vai ou não ser executado.
• Hoje, em sua versão mais lenta e completa, o processo demora em torno de 35 minutos; e, em sua versão mais rápida, 6 minutos.
• Qualquer problema encontrado em qualquer uma das etapas da build, faz com que todo o processo seja interrompido. Nesse caso, uma notificação é enviada para toda a equipe.

Artefatos Gerados

• Uma aplicação publicada em um servidor de homologação para uso imediato, sem que seja necessário qualquer procedimento manual para instalação;
• Um relatório contendo o ChangeLog da versão “Minor” e o ReleaseNotes da build.
• Um arquivo msi auto-instalável, disponibilizado em um website para download, onde se pode baixar uma determinada versão e instalá-la em uma máquina para testes, para apresentação ou até no ambiente de produção do cliente.

RoundTrip

A seguir é apresentado o esquema de execução do processo de Integração Contínua, a lista de ferramentas utilizadas e uma explicação geral sobre cada passo, são mostrados mais adiante.

• Comentário obrigatório para qualquer commit;
• Comentário individualizado por arquivo;
• Associação com uma tarefa previamente cadastrada no Issue Tracking;
• Os comentários devem fazer parte da documentação da task no issue tracking; 

Obviamente, as ferramentas de controle de código-fonte e issue tracking não se falam nativamente. Houve então a necessidade de integrá-las. Implementamos então uma integração do CVS com o Mantis de forma que um script PHP validasse a forma e o conteúdo do comentário escrito pelo desenvolvedor no momento do check-in. Para que isso funcione, o comentário é sempre escrito conforme uma regra pré-estabelecida. Ele é aplicado a uma Regular Expression que valida sua forma. Já o script PHP valida seu conteúdo, recuperando de seu texto o número da task do Mantis e documentando o comentário inserido pelo desenvolvedor nas notas dessa mesma task. Esse processo será descrito com mais detalhes em um post futuro.

Processo de Build e Deploy

Após todo o processo de check-in do desenvolvedor, este pode acionar o build server para disparar os procedimentos de build e deploy, conforme é mostrado no passo 3 da figura 1. O próprio build server se encarrega de obter o código-fonte na versão mais atual para o branch associado. O NAnt é acionado então pelo build server e começa a execução de uma série de procedimentos. Inicialmente, os assemblies são marcados com um novo número de versão seguindo uma máscara pré-definida (ex: 2.0.1.*), onde o * é um número que é incrementado a cada execução do processo (apenas as execuções com sucesso são contadas). Os assemblies saem então com o mesmo número de build da Integração Contínua. Cada assembly é então compilado e reservado junto com referências a bibliotecas de terceiros.

Depois disso, os vários arquivos Xml utilizados para configurar a aplicação passam por procedimentos de checagem. São 3 níveis de checagem: sintaxe (via parser), regras de integridade (via schemas) e semântica (via um aplicativo desenvolvido internamente). Por exemplo, nós temos um arquivo de mapa de urls que mapeia o caminho físico de uma página web com um alias lógico. A validação sintática checa se não há má-formação do xml, a validação de integridade checa, entre outras coisas, se os atributos obrigatórios de cada elemento estão preenchidos; ou ainda, se um determinado atributo contém valores válidos. Já a validação semântica verifica, por exemplo, se o arquivo indicado no mapa existe fisicamente no repositório. Há também vários outros arquivos Xml utilizados pela aplicação que passam pelos seus próprios níveis de validação. 

O próximo passo é o acionamento do MSBuild para a compilação e merging da aplicação web. O ASP.Net 2.0, diferentemente do 1.1,  disponibiliza um aplicativo chamado ASPNetMerger que compila todo o código de interface de usuário em um único assembly, deixando as páginas aspx apenas com conteúdo HTML. O MSBuild foi utilizado nesse caso por que já tem tasks preparadas para rodar este procedimento.

Feito isso, e se tudo deu certo até agora, estamos prontos para executar os testes unitários. Como há vários testes que acessam o banco de dados, é necessário acionar o isql.exe para execução do script SQL de inicialização do BD da aplicação. Um BD novo é criado, as configurações para acesso a este bd são realizadas, e o NUnit é chamado para rodar os testes de cada um dos assemblies compilados anteriormente.

Se nenhum teste falhar, a build continua com o procedimento de geração de ChangeLog e ReleaseNotes. Esses procedimentos merecem estar em um post específico (e estarão!), mas, em resumo, o que acontece aqui é a leitura de todos os logs do CruiseControl. Esses logs contém as informações de que tasks do Issue Tracking foram contempladas em cada build gerada. Com essa informação, nós conseguimos gerar um documento de ChangeLog que relaciona as tasks associadas a cada build gerada anteriormente. O ChangeLog é contextual à máscara de número de versão que está no contexto da integração contínua.

O resto do processo fica por conta da geração e execução do MSI, um arquivo auto-instalável que permite a instalação de toda a aplicação em modo silencioso. A geração do MSI é toda realizada pelo framework open-source WIX. Como a aplicação é toda web, depois de instalada ela já pode ser acessada pela equipe e testada. Vale destacar, nesse processo de instalação, que houve a necessidade de desenvolvermos um pequeno aplicativo para a atualização automática de estruturas de banco de dados e arquivos de configuração que venham a ser criados ou modificados pelos desenvolvedores.

Ao final, o NAnt faz a cópia do arquivo MSI para um diretório onde ele estará disponível para download pela equipe ou pelos próprios clientes.

O próprio Build Server se encarrega de notificar a equipe de que o processo de build foi finalizado com sucesso. Se qualquer evento anterior falhar, a build se encerra e a equipe é imediatamente notificada.

• Ao invés de fichas com adesivos indicando a situação da história (Figura 1), nós optamos por usar "Post-its" posicionados em áreas diferentes do quadro. A área em que ele se encontra, identifica sua situação e não mais a sua cor.
• Nossas histórias agora só tem duas cores: amarelo e laranja. A cor laranja identifica tarefas extras (tarefas não planejadas) - o que nós chamamos de SWATs - pois na maioria das vezes elas são de caráter emergencial.
• O quadro também contém gráficos que nos dão uma indicação de produtividade:
• Quantos pontos a equipe produziu na iteração (Velocidade);
• Desses pontos, qual o percentual de pontos de tarefas planejadas com relação às tarefas não-planejadas.
• Criamos uma área de "Product BackLog". Assim, na hora de planejar a iteração seguinte, basta priorizar e estimar a parte do backlog que será atacada.

Figura 1 - Modelo anterior. Fichas com adesivos que indicavam
a situação da história.

Figura 2: Novo quadro de acompanhamento. Mais útil,
mais fácil de atualizar e mais informativo.

    O novo modelo deu muito certo até agora. Há muitas vantagens sobre o modelo antigo. A idéia agora e mandar fazer um quadro com uma estrutura parecida para que não precisemos desperdiçar um dos nossos quadros brancos para esse propósito.

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!