Integração contínua – Parte 2
Neste segundo artigo da série, vamos iniciar a montagem de um ambiente voltado para integração contínua utilizando ferramentas Open Source.
A primeira etapa será a instalação da primeira ferramenta, o Cruise Control(CC), ferramenta Open Source de automação e gerenciamento de Build. O Cruise Control foi desenvolvido inicialmente pela empresa ThoutghtWorks e liberado como versão gratuíta para a comunidade. O CC, conta com uma arquitetura totalmente extensível, e possui três módulos distintos:
Build loop: é o coração do sistema, ele inicia processos de build e envia notificações aos usuários, como , problemas durante o build. A inicialização do processo de build poderá ser, por exemplo, quando o CC detecta uma mudança no sistema de controle de fontes (ex, Source Safe, SubVersion entre outros). O processo de build é composto por um workflow de tarefas, ex:
- Baixar os fontes
- Compilar
- Executar testes unitários
- Realizar cópia de arquivo
- Aplicar versão nos Fontes da aplicação
- Efetuar publicação da aplicação.
Todas as tarefas de build do projeto são mapeadas através do arquivo de configuração do CC que veremos em outro post. Cada tarefa, graças a arquitetura flexível do CC, poderá ser delegada a diversos plugins. Um dos plugins mais famosos é o NAnt, plugin de Build que também utilizaremos em momento oportuno.
JSP reporting: é o módulo responsável por exibir informações e artefatos gerados pelo processo de build. As informações são exibidas através de uma interface web de fácil utilização. Podemos visualizar informações tais como: tempo de build, data do build, erros, avisos, dados sobre testes unitários entre outras informações.
Dashboard: como o próprio nome diz, é um painel de instrumentos que tem o objetivo de mostrar status do build de um projeto. Este módulo também exibe os dados através de uma aplicação web rica em informações, que também pode ser acessada via
RSS.
A figura abaixo,retirada do site do Cruise Control, mostra a arquitetura detalhada do aplicativo:
OBS: Um pré-requisito é a instalação do Java Runtime Enviroment, que pode ser obtido no site do Java.
Então vamos começar a brincadeira, baixe o Cruise Control e execute o instalador, e clique em “Next”
Selecione o “Path” de instalação, vou manter o padrão. Clique em “Install”
Após procedimentos de instalação, o instalador pede que inicializemos o serviço do Cruise Control, através do Painel de controle de serviços. Clique em “Ok” e em seguida “Close”
Vá a Painel de Controle/Ferramentas Administrativas, e escolha a opção “Serviços”. Na listagem, procure o serviço do Cruise Control
Antes de iniciar é aconselhável configurar uma conta sob a qual o serviço irá rodar, esta conta deverá ter permissões restritas às atividades do servidor de Build. Para configurar é muito simples, basta clicar com o botão direito, escolher a opção “Propriedades”, escolher a guia “Log On” e informar o usuário.
Para iniciar, basta clicar com o botão direito do mouse e selecionar a opção “Iniciar”. Com o usuário configurado, inicie o serviço. Para sabermos se a instalação ocorreu com sucesso, vamos acessar o console de gerenciamento do Cruise Control através do endereço http://localhost:8080/dashboard/. Teremos a página abaixo:
No próximo post, vamos começar as configurações necessárias do Cruise Control.
[]'s
Fabio Margarito
Integração contínua – Parte 1
Vou iniciar uma série de posts sobre o processo de integração contínua e como utilizar ferramental de apoio parar tornar a prática possível.A idéia de montar a série advém de dúvidas de amigos e para eu mostrar como este processo trouxe benefícios ao meu trabalho.Inicialmente irei contextualizar o que é Integração Contínua e como utilizar ferramental apropriado, e na seqüência vamos implementá-la utilizando uma plataforma open-source na prática com Cruise Control + nant e também através do Team Foundation 2010(se tudo der certo).
Em uma tradução livre, Fowler define integração contínua como :
“Uma prática de desenvolvimento de software onde os membros de um time integram trabalhos com frequência, usualmente cada pessoa realiza integrações pelo menos uma vez ao dia – levando a múltiplas integrações por dia. Cada integração é verificada por um processo de build automático para detectar erros de integração o quanto antes. Muitos times acham que esta abordagem leva a reduções drásticas de problemas com integração e permite que um time desenvolva softwares coesos rapidamente”.
Para entender as palavras de Fowler, vou demonstrar como funciona o trabalho de um time quando uma nova versão de sistema é desenvolvida:
- Cada desenvolvedor baixa uma cópia dos fontes de um repositório central para sua máquina. Este repositório é o Source Control. Não é objetivo discutir nesta série o papel e recursos de um Source Control e por isso indico o excelente artigo do Eric Sink, caso Source Control seja um assunto desconhecido para você.
- Cada desenvolvedor efetua o check-out, ou seja, “informa” ao source control que determinado fonte está sendo alterado e mantém este estado pelo tempo necessário até efetuar a alteração.
- Após alterações de fonte, que podem levar vários dias, cada desenvolvedor efetua o “check-in”, que é o processo de enviar para o source control o código alterado e torná-lo disponível a todos.
- Quando todos os desenvolvedores efetuarem os check-ins, uma profissional baixa a versão e realiza o Build. O Build é o processo de montagem de uma versão que será implantada, e pode ser composto por uma compilação, montagem, execução de scripts de banco de dados, entre outros artefatos. O processo de Build realizado através dos check-ins é o processo de integração que Fowler cita, ou seja, quando integramos o resultado do trabalho de todo time. O Build é um processo chato, oneroso, geralmente de natureza manual e leva muito tempo.
- O resultado oriundo do Build é instalado.
Este é o caminho feliz, mas geralmente não é verdade, por quê? Um módulo alterado por um desenvolvedor pode afetar o trabalho de outro, devido a erros de código ou quebra de compatibilidade. Estes problemas normalmente são encontrados em vias de entrega da versão.
A Integração Contínua tem como principal objetivo, automatizar todo processo de Build para que erros possam ser identificados o quanto antes. Por ser um processo automático, a freqüência de integração aumenta. É boa prática que o time realize check-ins diários para que tirem proveito do processo de integração contínua.
Ferramentas de integração contínua (IC) podem, por exemplo, identificar que houve check-in de arquivos e automaticamente disparar um processo de Build, se houver algum erro, um aviso pode ser emitido e problema identificado rapidamente. Caso o processo de Build seja muito lento, o mesmo pode ser agendado para rodar noturnamente todos os dias.Outro recurso interessante de ferramentas IC, é a possibilidade de após Build, rodar testes automatizados, caso um teste não passe, um erro de Build é gerado.
Espero que nestas poucas linhas, eu tenha conseguido deixar claro o que é o processo de integração contínua e quais benefícios o time ganha com esta prática. No próximo post, vamos começar a colocar a mão-na-massa, utilizando o Cruise Control.
Para mais informações, sugiro os links:
Continous Integration na visão de Martin Fowler
http://www.martinfowler.com/articles/continuousIntegration.html
Continous Integration por Mattew Foemmel
http://www.martinfowler.com/articles/originalContinuousIntegration.html
[]'s
Fábio Margarito