Integração contínua: uma introdução ao assunto
Autor: Ronaldo Araújo | Publicado: 2013-05-15T17:27:00-03:00


Há algum tempo queria falar um pouco sobre integração continua devido à experiência que tive e venho tendo trabalhando também utilizando essa técnica em alguns projetos, com isso lê um artigo muito interessante sobre o assunto e vou colocar aqui uma pequena introdução do que é essa técnica, como podemos utiliza-la e algumas ferramentas que podemos usar para tirar um bom proveito da integração continua.


A integração contínua é um termo originado na metodologia ágil XP e utilizado em diversas metodologias, consistindo em algo simples: o desenvolvedor integra o código alterado e/ou desenvolvido ao projeto principal na mesma frequência com que as funcionalidades são desenvolvidas, sendo feito muitas vezes ao dia ao invés de apenas uma vez. O objetivo principal de utilizar a integração contínua é verificar se as alterações ou novas funcionalidades não criaram novos defeitos no projeto já existente. A prática da integração contínua pode ser feita através de processos manuais ou automatizados, utilizando ferramentas como o Jenkins, Hudson entre outros.



“Integração Contínua é uma pratica 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.” Martin Fowler



Para a utilização continua, é importante que a equipe possa trabalhar em grupo, para isso é importante que se tenha um sistema de controle centralizado de versão.


Controle de versão e Integração continua

Como parte crucial no processo de desenvolvimento e, para o sucesso da integração contínua, o controle de versão deve ser utilizado. Sendo que um dos objetivos do controle de versão é o trabalho colaborativo, em que diversos desenvolvedores trabalham em conjunto e compartilhando dados. O controle de versão é essencial para metodologias como o XP, em que a equipe deve trabalhar em conjunto constantemente.

O sistema de controle de versão resolve um grande problema quando trabalhamos em equipe:



&nbsp;como compartilhar as informações de forma a ter a última versão válida e ainda saber quem fez as alterações;
&nbsp;como prevenir que os desenvolvedores refaçam o trabalho já desenvolvido, etc.



Para solucionar estes problemas, existe um conjunto de ferramentas para controle de versão centralizado, entre elas temos o CVS, Subversion, Git, entre outros. Estas ferramentas permitem aos desenvolvedores trabalharem em conjunto, possuindo um Servidor central responsável pelo versionamento do sistema e possibilitando que vários clientes possam acessar, visualizar, modificar e enviar novos códigos se for necessário.


CVS:


&nbsp;http://www.tortoisecvs.org/
&nbsp;http://cvs.nongnu.org/



Subversion:


&nbsp;http://subversion.tigris.org/
&nbsp;http://subversion.apache.org/



Git:


&nbsp;http://git-scm.com/
&nbsp;https://github.com/
&nbsp;http://gitref.org/



Entre os benefícios da utilização de um sistema de controle de versão, temos:



&nbsp;possibilidade de restaurar versões anteriores do sistema;
&nbsp;comparar códigos;
&nbsp;gestão de alteração, etc.



É possível utilizar o sistema de controle de versão para gerenciar códigos, documentos, scripts de teste entre outros. Além disso, é possível criar uma linha alternativa para o desenvolvimento, o chamado branches.



O controle de versão funcionará de forma básica da seguinte forma:




&nbsp;O desenvolvedor faz o seu código, efetua um build antes de integrar seu código com a base principal;
&nbsp;Após realizar o build, o sistema deve ser integrado a base do sistema de controle de versão através de sincronização;



Este processo deve ser feito frequentemente, evitando-se assim o acúmulo de codificação para a integração ao repositório. Algumas metodologias ditam que o desenvolvedor só pode considerar como pronto o trabalho quando o trabalho estiver sincronizado e então o desenvolvedor realizar um build na máquina de integração e após todos os testes serem executados com sucesso.


Na integração contínua o processo de build integrado deve ser feito constantemente, sendo sincronizado sempre que possível, evitando o acúmulo de códigos e de testes. Isto por que é mais fácil encontrar erros em pequenas integrações do que em uma integração grande.


O problema é que, apesar de ser ágil, temos que criar testes automatizados que permitam ao desenvolvedor analisar erros de integração. Uma boa prática é a utilização de frameworks XUnits para esta tarefa, exemplo: Junit para Java, PHPUnit para PHP, CppUnit para C++, entre outros.


Para ver mais sobre JUnit, acesse: http://www.devmedia.com.br/introducao-ao-desenvolvimento-guiado-por-teste-tdd-com-junit/26559.



A vantagem é que tanto a sincronização com o repositório de controle de versão como para o uso do framework de teste, é possível utilizar plug-ins diretamente nas ferramentas IDE´s como Eclipse, Netbeans etc, facilitando o trabalho do desenvolvedor.



Com a utilização de teste e o controle de versão centralizado, é necessária para uma boa integração, a automatização dos builds. O processo de build (compilar, preparar o executável, rodar os testes automatizados, etc.) e a sua automatização é algo relativamente comum, de forma que possamos evitar problemas. Ao realizar os builds, existem diversas ferramentas que permitem a automatização dos builds, entre elas temos o ant (para java), Maven, Nant (para dot net), MSBuild (para dot net), entre outros. Não automatizar os builds, segundo Fowler, é um erro, pois diversos problemas ocorrem quando o processo é feito de forma manual, pois cada desenvolvedor acaba realizando o build de forma diferente, podendo criar problemas na integração.



Um outro ponto importante, segundo Fowler, é que os builds devem ser auto testáveis, ou seja, durante os builds é necessário ter também os testes automatizados, como mencionados acima, para melhorar no processo de detecção de erros.



Bem, e a Integração?




Agora que temos um controle de versão centralizado, temos testes automatizados, temos builds automatizados, podemos ter a integração, que é antes de tudo uma comunicação, e para isso tudo deve estar pronto e adequado.



“O único pré-requisito para um desenvolvedor lançar suas alterações na versão principal é que ele consiga executar perfeitamente o código. Isso, claro, inclui passar pelos testes da build. Como com qualquer ciclo de lançamento de código, o desenvolvedor primeiro atualiza sua cópia de trabalho para coincidir com a versão principal, resolve qualquer conflito e então gera o build em sua máquina local. Se o build passar, então ele estará liberado para lançar suas alterações na versão principal.” Fowler.



A integração contínua permite que os desenvolvedores encontrem rapidamente conflitos de versão, o grande segredo é solucionar problemas rapidamente e continuamente.



Ferramentas para Integração contínua




Com os recursos acima já implementados, chega o momento de implementar uma ferramenta de integração continua. Existem diversas ferramentas, entre elas o Hudson, Jenkins etc. São ferramentas livres e estão disponíveis para download gratuitamente.



A chave para uma boa integração, como visto anteriormente, é um ambiente de controle de versão centralizado, builds e testes automatizados.



As ferramentas de integração contínua permite que seja configurado o seu sistema, o ambiente de desenvolvimento (exemplo: jdk), permite que seja configurado o sistema de build automatizado como o ant, integrar com o repositório de controle de versão, e permite ainda o envio de e-mails de notificação. Isto é importante, pois como o sistema é automatizado, caso ocorram erros, o desenvolvedor pode ser notificado que a integração gerou falhas, para poder ser analisada.



A implantação das ferramentas são simples, por exemplo, o Jenkins pode ser baixado gratuitamente em http://jenkins-ci.org/, existindo versões para Windows, Linux, Mac, Solaris, BSD, Unix, etc. A instalação é simples, e pode ser vista em https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+as+a+Windows+service.



Conclusão




A integração contínua com ferramentas automatizadas traz diversos benefícios, como vimos. Primeiro é que o trabalho em equipe gera menos erros, reduz riscos, pois como o sistema é integrado continuamente e rapidamente, os erros também são detectados na mesma velocidade.



Os bugs neste formato, não se acumulam, não gerando um problema geral no sistema, pois ao invés de demorar um dia ou uma semana, o erro é detectado em horas. Pois mesmo o desenvolvedor testando na codificação, ao integrar, erros podem surgir e quanto antes os erros forem detectados, antes serão corrigidas.



É isso pessoal espero que tenha dado uma luz a quem ainda não conhecia ou não tinha usado essa técnica ainda muito utilizada nas metodologias ágeis.

Referência
http://www.devmedia.com.br/integracao-continua-uma-introducao-ao-assunto/28002

Autor:
Fabio Gomes Rocha