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.