Integração Contínua (Ferramentas)

No post anterior, tratei da teoria de IC. Mas agora gostaria de postar algo sobre as ferramentas que contribuem para a integração contínua.

Para que a integração ocorra sem muitas dores, faz-se necessário o uso de algumas ferramentas. São elas:

• Ferramentas de build: essas ferramentas são utilizadas para agilizar o processo de build de um sistema, automatizando tarefas como: compilação do código do sistema, compilação e execução dos teste unitários e de aceitação; geração de relatórios dos testes, de cobertura e de análise estática do código; quaisquer outras atividades que sejam definidas como necessárias para o build.

• Ferramentas de controle de versão: ferramentas que armazenam e mantém a versão de todo código-fonte. É também conhecida como repositório. Essas ferramentas automatizam as seguintes tarefas: identificação de mudanças locais, exibição das diferenças entre o código de um arquivo local e uma de suas versões; identificação de quem realizou determinada alteração; incorporação de uma mudança em um arquivo armazenado no repositório; sincronização do código local com uma das versões do sistema ou de um arquivo armazenado no repositório. Temos alguns exemplos de ferramentas de controle de versão: Subversion, CVS, entre outros.

Apesar de haver essas ferramentas, vale ressaltar que a integração só valerá a pena se não houver erros. Para tanto, faz-se necessário a automatização dos testes e que as ferramentas simplifiquem e automatizem o processo de integração contínua.

 

Integração Contínua (Teoria)

Bem, vamos falar um pouco Integração Contínua (IC).

Imagine o seguinte cenário: um sistema X muito extenso precisa ser desenvolvido. A empresa que solicitou esse sistema pretende dividi-lo em módulos e contratar algumas outras empresas para ajuda-la no desenvolvimento do mesmo. Cada módulo depende um do outro. Como fazer para desenvolver esse sistema em ambientes diferentes e no final ter um código consistente e que funcione?

Parece uma utopia, mas embora isso pareça novidade, a prática da Integração Contínua não é tão nova assim.

Mas afinal, o que é a Integração Contínua (IC)?

Bem, a integração contínua é uma prática que consiste em integrar o código várias vezes ao dia, assegurando que o código permaneça consistente ao final de cada integração.

Se cada programador integrar pelo menos uma vez ao dia, teremos, assim, várias integrações ao final do dia.

Essa prática foi introduzida com o Extreme Programming e as vantagens em realiza-la são:

• eliminação de longas sessões de integração;

• os problemas de integração são detectados tão breve quanto o possível;

• as pessoas criam um sentimento de interdependência;

A IC pode ser realizada de duas formas:

• Integração Síncrona: não há a utilização de ferramentas que automatizem a integração. Cada programador integra seu trabalho de cada vez. Após o término da integração do código, o próximo programador poderá integrar o seu.

• Integração Assíncrona: Há a utilização de ferramentas que automatizam a integração. Alguns exemplos: CruiseControl, AnthillPro, Continnum, Team City, Luntbuild, Hudson, Scons, Bitten, Gump, TinderBox, Final Builder, Build Forge, Beetle Juice, entre outros.

Essa prática só se torna viável quando a equipe mantém sempre o código fonte que existir no repositório funcionando.

Para uma melhor prática da implementação da IC, Martin Fowler cita 10 práticas que são fundamentais:

1. Manter um repositório de código-fonte unificado.

2. Automizar a construção do executável (build).

3. Usar testes automatizados.

4. Todos os membros da equipe devem atualizar o repositório diariamente.

5. Cada atualização do repositório deve iniciar a construção do executável (build).

6. Manter a construção do executável rápida.

7. Testar em um clone do ambiente de produção.

8. Tornar fácil que qualquer um obtenha o mais recente executável.

9. Transparência (qualquer pode saber o que está acontecendo).

10. Implantação automatizada.

Para realizar a integração contínua faz-se necessário:

• o uso de servidor de build;

• o uso de servidor de controle de código;

• ter um processo bem definido;

• ferramentas como: cruisecontrol, ant etc;

• responsabilidades do programador:

  • atualizar o repositório diariamente;

  • o código deve ser compilável;

  • o código deve ter testes unitários;

Estudando sobre integração contínua, encontrei um blog onde o blogueiro era contra a integração automatizada. Tudo bem! Não vou querer pegar briga com ele por pensar dessa forma. Os motivos que ele deu foi:

• Ao automatizar o feedback é perdido

• Você não concerta o erro assim que descobre, pois a ferramenta que automatiza a integração te enviará uma notificação alguns instantes depois.

• Quase sempre o build está quebrado.

• E se tentam corrigir a quebra do build, a pessoa que está concertando o erro não conhece todos os erros, gerando assim uma demora para se estudar os erros.

Sobre o feedback ser perdido, realmente isso é uma verdade. E o fato de o erro não ser concertado assim que é descoberto é outra verdade. Mas o fato de o bluid está sempre quebrado é algo a ser pensado, pois faz-se necessário que o build não esteja quebrado. Com boa prática, assim que o build for quebrado, deve-se concerta-lo e disponibiliza-lo no repositório para os demais.

É bem chato, a galera tá trabalhando e de repente o gerente ou alguém responsável pelo feedback da integração dizer: “Putzzzz, o build quebrou!”. E lá vai toda a nossa equipe ou um só tentar resolver o problema. Mas quem falou que a vida de programador é fácil?

Alguns pensam que Integração Contínua só serve para projetos grandes. Mas na verdade 70% das aplicações estão fadadas ao fracasso caso não respeitem o ciclo de software.

Resumo: “Integração contínua serve para controlar a produçao de software, facilita a construção de lista de bugs fixados, features e ajuda ao time de teste andar junto com a equipe de desenvolvedores.”