Integração Contínua: da teoria à prática

Uma das principais etapas do ciclo de desenvolvimento de software é a implementação do código. É nesta etapa que tudo o que foi proposto, sugerido, discutido, desenhado e modelado será traduzido em código.

Durante a codificação, uma série de considerações deve ser levada em conta, como:

· A utilização correta dos recursos oferecidos pela linguagem de programação;

· A implementação do código com aderência à arquitetura definida;

· A aplicação de boas práticas, como design patterns, modularização, criação de componentes reutilizáveis, criação de testes e aplicação dos princípios de qualidade, como manutenibilidade, legibilidade e documentação do código;

· A execução de refatorações constantes, mantendo o código atual dentro das boas práticas citadas no item anterior.

A evolução do código é feita pela equipe de desenvolvimento, que de forma paralela e gradativa adiciona novos recursos à versão atual. Com relação à forma de condução desta evolução, alguns pontos devem ser discutidos, a saber:

· Como é feito o gerenciamento da evolução no código?

· Como é garantido que todas as partes desenvolvidas estão seguindo as considerações levantadas anteriormente?

· Como garantir que o código continua funcionando após cada alteração?

· Como detectar a inclusão de bugs no código?

As questões levantadas anteriormente estão relacionadas a pontos importantes, como o tratamento de bugs existentes no código e o alinhamento da evolução do projeto em relação ao resultado esperado. Estes pontos e as consequências da falta de atenção dada a eles estão destacadas a seguir:

· Bugs: O momento em que os bugs são descobertos pode ser crucial. Um bug detectado em fases avançadas do desenvolvimento pode tornar o prazo de entrega inviável e comprometer o orçamento do projeto, pois a correção deste bug pode gerar novos bugs em outras funcionalidades dependentes, gerando uma reação em cadeia. Esta situação com certeza abala a confiança e credibilidade de todos os envolvidos no projeto;

· Visibilidade do projeto: Como proporcionar aos participantes do projeto, envolvidos diretamente ou não com a implementação, a percepção de que os resultados obtidos diariamente estão de acordo com as expectativas? Esta percepção é muito importante, pois pode evitar que desvios ocorridos durante o desenvolvimento sejam descobertos somente na fase final do projeto, não permitindo reação por parte da equipe.

Por meio da aplicação das técnicas e práticas que compõem a Integração Contínua, conseguimos agir nos pontos levantados anteriormente, em relação à evolução do desenvolvimento.

Deste modo, este artigo apresentará os conceitos, práticas e ferramentas que fazem parte da aplicação da Integração Contínua no ambiente de desenvolvimento. Iniciaremos com a conceituação da metodologia, seguindo com a apresentação das ferramentas necessárias e encerrando com o detalhamento das atividades que são realizadas diariamente durante a codificação do projeto.

O que é Integração Contínua?

A Integração Contínua surgiu como parte das práticas da metodologia ágil XP (Extreme Programming), tendo como foco o desenvolvimento de software em ciclos menores, proporcionando melhor resposta a alterações e inclusão de novos requisitos. Mas a prática da Integração Contínua não se limita apenas a equipes utilizando a metodologia XP ou metodologias ágeis, trata-se de um conjunto de boas práticas que também podem ser adotadas em metodologias de desenvolvimento convencionais.

A Integração Contínua tem como ideia principal a diminuição dos riscos através do monitoramento constante das alterações, mantendo a integração frequente do código. Esta atividade passa a fazer parte do processo de desenvolvimento, sendo considerada como um procedimento normal e corriqueiro.

A integração do código deve ocorrer com a maior frequência possível, idealmente a cada alteração efetuada, pois em caso de problema, o conjunto de modificações em que a falha está inserida é menor, facilitando a identificação e correção do(s) erro(s).

Para que a integração seja efetiva, é necessário verificar o funcionamento do código após as modificações, e para atender esta necessidade, o desenvolvimento em conjunto com a realização de testes é fundamental, de preferência com a adoção da metodologia TDD (Test Driven Development).

Como resultado da execução de uma integração bem sucedida, conseguimos atingir os seguintes benefícios:

· Garantia que o código compila e que as funcionalidades testadas mantêm sua integridade e funcionamento esperados;

· Uma potencial versão do software, que pode ser utilizada, por exemplo, pela equipe de QA para execução de testes.

Quais as ferramentas necessárias?

Para a aplicação eficaz da Integração Contínua em um ambiente de desenvolvimento são necessárias algumas ferramentas que proporcionam algumas das funcionalidades fundamentais, como o controle das alterações, automatização de build e execução das integrações.

O Sistema de Controle de Versões (SCM)

O Sistema de Controle de Versões (SCM) gerencia as alterações do código durante o desenvolvimento. No SCM, um projeto é representado por uma estrutura de diretórios chamada de repositório. Durante a evolução da implementação, o repositório do projeto sofre várias alterações, que são controladas por meio de revisões. Cada revisão possui um identificador único, a data de criação, o conjunto de modificações efetuadas e o responsável. Estas informações permitem que a evolução do código seja rastreada, indicando detalhes do que, quando e por quem as modificações foram realizadas.

As revisões constituem um recurso essencial em sistemas SCM, pois além de manter o histórico de alterações, possibilitam a restauração de estados anteriores do repositório, como por exemplo, antes da aplicação de determinadas modificações.

O sistema SCM age como um ponto central na obtenção e propagação de alterações efetuadas em um projeto, sendo a sua utilização considerada uma boa prática, pois facilita aos participantes o acesso ao conteúdo do projeto.

Por meio dos recursos oferecidos pela ferramenta de SCM, o Servidor de Integração Contínua consegue monitorar a criação de novas revisões no repositório. Deste modo, assim que uma nova revisão é criada, o servidor atualiza o código com a versão mais atual existente no repositório e executa a integração.

As principais ferramentas de SCM disponíveis atualmente oferecem todas as funcionalidades apresentadas anteriormente.

Em seguida, estão os detalhes de algumas das ferramentas mais utilizadas:

· Concurrent Versions System (CVS): é uma solução open source, criada na década de 1990, e originalmente para a plataforma UNIX. Utiliza um sistema de versionamento por arquivo, ou seja, cada arquivo no repositório tem um controle de revisões próprio. Como deficiências do CVS, vale ressaltar a fragilidade no suporte ao versionamento de diretórios e a ausência de um controle de atomicidade nos commits, o que significa que se ocorrer algum problema nesta operação, os arquivos que já foram submetidos até momento do erro não serão revertidos;

· Subversion (SVN): é uma solução open source, multiplataforma, e com a primeira versão disponibilizada em 2000. O Subversion é considerado o sucessor do CVS. Ele oferece controle de atomicidade nos commits e as revisões são controladas por repositório, ou seja, após a efetivação de um commit uma revisão é criada para representar a nova situação da estrutura do repositório;

· Git: é uma solução open source e com a primeira versão disponibilizada em 2005. Como diferencial, oferece um sistema de controle de versões descentralizado.

Automatização de Build

O build (construção) de um projeto é uma atividade composta por várias etapas, incluindo a compilação do código fonte, execução de testes, empacotamento, geração de artefatos de documentação e realização do deploy.

Além destas etapas, podem ser incorporadas etapas específicas de acordo com a necessidade do projeto, como por exemplo, a versão em construção pode demandar a evolução da base de dados para suportar novas funcionalidades. Neste caso, uma etapa extra deve ser incluída no processo de build para executar os scripts de evolução da base de dados.

As etapas de construção são repetidas todas as vezes que é necessária a disponibilização de uma nova versão, seja para utilização em testes, homologação ou produção.

A automatização do processo de build é possível por meio da criação de scripts, que executam cada uma dessas etapas da construção em sequência, reportando o resultado ao final da execução de cada uma. A automatização de build utilizando scripts traz os seguintes benefícios para o processo de construção:

· Facilidade na execução: O script de build geralmente é disparado por um ou poucos comandos, simplificando a execução do build;

· Padronização do build: O script de build é compartilhado por toda a equipe de desenvolvimento, sendo executado da mesma forma por cada integrante;

· Parametrização do build: O script de build pode ser elaborado para permitir a utilização de parâmetros durante a construção. Um exemplo é o fornecimento de parâmetros para que a versão construída esteja de acordo com os possíveis ambientes de execução da aplicação (ambiente de testes, ambiente de homologação ou ambiente de produção);

· Execução de todas as etapas: O script de build executa todas as etapas em sequência, garantindo que elas não sejam esquecidas ou suprimidas. O script de build até pode permitir a supressão da alguma etapa durante a construção, mas esse recurso deve ser usado apenas em casos específicos.

Outro benefício no uso de scripts de build é permitir a independência da construção em relação à IDE. A IDE pode ser utilizada para executar o build, mas isso do ponto de vista e necessidade de cada desenvolvedor. Nos demais casos, o script de build é o principal mecanismo para a construção do projeto.

Para a criação dos scripts de build pode se optar pelo uso de soluções “caseiras” ou pelo uso de ferramentas de automatização de build, como o Apache Ant, que é bastante flexível, possibilitando que o fluxo do build, ou seja, as etapas e a sequência de execução sejam totalmente customizadas. Outra opção de ferramenta é o Apache Maven, que não é tão flexível, mas que oferece recursos que facilitam a criação do projeto e do script, como a padronização na estrutura de diretórios e o ciclo de build próprio.

Independente da solução escolhida, o importante é ser possível disparar a construção do projeto de modo simples, com apenas um comando. A facilidade no disparo do build é aproveitada pelo Servidor de Integração Contínua, para manter a integração e construção frequente do projeto.

Servidor de Integração Contínua

O Servidor de Integração Contínua é uma aplicação que tem como objetivo principal recuperar as alterações ocorridas no repositório e integrá-las, com a execução do script de build. Para que esta tarefa seja executada, o servidor deve permitir a configuração de planos de build, que armazenam as configurações necessárias para que a integração possa ser executada, como o endereço do repositório para monitoramento das modificações, a frequência da execução, o(s) comando(s) para o disparo do build e as configurações das notificações dos resultados.

Os planos de build podem ser configurados de várias maneiras, atendendo a diferentes necessidades do projeto, como por exemplo, a configuração de um plano de build que executa a compilação e execução de testes em uma versão de JDK alternativa. Este plano de build complementar assegura que a aplicação atenda aos requisitos de construção e execução nos ambientes especificados.

A cada execução do plano de build, o Servidor de Integração Contínua oferece através de uma interface Web o resultado da execução da integração, incluindo o log de execução do script de build e o resultado da execução dos testes.

Uma funcionalidade essencial do Servidor de Integração Contínua é a configuração de mecanismos de notificação. Estes mecanismos divulgam os resultados da integração, sendo importantes para uma ação rápida por parte da equipe de desenvolvimento, em caso de falha na integração. Geralmente, o principal mecanismo de notificação utilizado é o disparo de e-mail, mas alguns mecanismos alternativos podem ser utilizados, como plugins para IDEs, plugins Desktop e o envio de mensagens de texto (SMS).

Após a configuração do plano de build, o Servidor de Integração Contínua, de acordo com as configurações do plano, irá manter um ciclo de funcionamento, que consiste no monitoramento e recuperação constante das modificações, executando a integração sempre que houver mudanças no repositório, disponibilizando os resultados por meio da interface Web e dos mecanismos de notificação configurados.

Para que o Servidor de Integração Contínua execute estas atividades são exigidos recursos mínimos de processamento e armazenamento. Os recursos de processamento são requeridos para a execução dos planos de build e os recursos de armazenamento, para manter as cópias dos projetos em execução e dos logs de construções anteriores, que ficam disponíveis para consulta. Os recursos requeridos podem ainda ser maiores, caso a mesma instância do Servidor de Integração Contínua seja compartilhada por mais de um projeto. Por esta razão é indicada a instalação do servidor em uma máquina dedicada, com maior disponibilidade de processamento e armazenamento.