Build automático de projetos com Continuum

Manter a qualidade do software produzido é um dos maiores desafios que as equipes de desenvolvimento de software enfrentam hoje em dia. Identificar os problemas, independentemente da linguagem escolhida, das tecnologias envolvidas e dos frameworks utilizados, é uma tarefa complexa e uma das principais razões pelas quais muitas equipes falham em construir um bom produto. Além disso, os atrasos nas entregas e o retrabalho tornam-se cada vez mais frequentes, resultando em dinheiro e esforço desperdiçados. Num cenário como esse, a Integração Contínua é uma excelente opção que pode ajudar a melhorar os processos de desenvolvimento.

Segundo Martin Fowler, a “Integração Contínua é uma prática de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver múltiplas 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”.

Imagine uma equipe de desenvolvimento trabalhando da forma como Fowler descreve. Que ganho de produtividade seria obtido se houvesse uma ferramenta capaz de executar os builds de forma automática? E se, além disso, ela pudesse identificar e reportar os problemas assim que fossem encontrados? Um servidor de Integração Contínua cumpre exatamente esse papel.

Com base nisso, neste artigo mostraremos como instalar e configurar um servidor de Integração Contínua. Para isso, optamos pelo Apache Continuum, devido às funcionalidades que ele oferece e ao suporte fornecido pela comunidade de desenvolvedores da Apache. Além da instalação, mostraremos como configurar o build de um projeto a partir de sua URL no Subversion, como modificar o agendamento da execução dos builds e como adicionar notificações que serão disparadas quando o build for executado.

Por que usar um servidor de Integração Contínua?

A questão chave é a garantia da qualidade. É uma boa prática cada desenvolvedor fazer o build do projeto em sua própria estação de trabalho, no entanto, esse procedimento não é suficiente para garantir a integridade do código, ou seja, há algumas outras questões a serem levadas em conta. Por exemplo, vamos supor que houve uma mudança em um determinado requisito e foi necessário alterar uma biblioteca de uso comum do sistema que está sendo desenvolvido. Imagine que essa biblioteca é utilizada por um componente de conexão com o banco de dados e que este é largamente utilizado por vários aplicativos que compõem o sistema. Nesse caso, devido ao tamanho do sistema, é possível que o desenvolvedor não tenha visibilidade de tudo o que essa alteração pode afetar porque sua workspace possui apenas os aplicativos com os quais ele deve trabalhar e eles continuam funcionando corretamente.

Ao longo do tempo, no entanto, alguns aplicativos começaram a apresentar problemas de compilação ou erros durante os testes integrados por causa das alterações feitas naquele componente de conexão com o banco de dados. E agora? Como é possível manter os aplicativos integrados e garantir que todos saibam o que está acontecendo? Como a equipe que desenvolve o aplicativo afetado será informada dessa situação para que possa fazer as correções necessárias? É nesse contexto que pretendemos demonstrar como um servidor de integração contínua pode ser uma ferramenta de grande valia.

O que o build do projeto deve fazer?

Segundo Duvall (2007), o build deve ser capaz de construir o aplicativo a partir do seu código-fonte sem intervenção manual. Para que funcione, o ideal é que seja necessário executar apenas um comando que dispare a sequência de ações. Os scripts não podem conter dependências em relação às IDEs utilizadas para desenvolvimento e deverão ser executados pelo sistema de integração contínua sempre que houver uma mudança no código-fonte ou segundo um agendamento.

A estrutura de diretórios utilizada para armazenar o código-fonte deverá ser a mesma para todos os projetos porque isso facilita a localização dos arquivos e a manutenção do script de build. Os arquivos de configuração a serem utilizados pelo aplicativo em cada ambiente em que ele for instalado (desenvolvimento, teste, homologação e produção) devem ser criados a partir do mesmo modelo de forma a garantir, por exemplo, que os parâmetros para conexão com o banco de dados sejam sempre os mesmos, independentemente dos ambientes, e apenas os valores (número de conexões, usuário, senha e URL do banco) possam ser diferentes.

Além disso, as variáveis de configuração de ambiente no servidor deverão ser independentes do aplicativo sendo construído. Por exemplo, se o build precisa utilizar um determinado diretório, esse deverá ser definido no script e não no servidor ou no aplicativo que está sendo construído. Com relação às dependências do build, Duvall explica que elas devem ser reduzidas ao mínimo necessário para executar o build.