Esta semana duas publicações interessantes sobre Integração Contínua me chamaram a atenção a ponto de eu estar sugerindo aqui no meu blog. A primeira é um screen cast no DnrTV com Scott Hanselman e Jay Flowers sobre o CI Factory. O CI Factory realmente me impressionou. Ele ajuda a preparar e gerenciar "workspaces" que isolam, padronizam e permitem fácil extensão e manutenção de sistemas de integração contínua. Em poucos minutos de contato com a idéia da ferramenta já dá pra perceber o quanto seus projetos vão poder se beneficiar de seus recursos. Acho que o ponto alto do CI Factory é trazer consigo um grande conjunto de boas práticas na construção e no gerenciamento de sistemas de Integração Contínua e Build Servers. Algumas das boas práticas que detectei apenas vendo o vídeo (ainda não parei para me aprofundar no uso da ferramenta, mas certamente o farei assim que puder): Todos os arquivos necessários para execução da build estão no mesmo contexto de controle de versão do próprio aplicativo; Toda a lógica de build é portável de forma que pode ser rodada não só no servidor, mas também nas workstations dos desenvolvedores; As referências a componentes de terceiros são organizadas e gerenciadas em um espaço próprio; Adicionar ou Remover passos é simples e rápido; Incorporar novos recursos à sua build também é muito fácil e rápido. Já vem com os pacotes para vários controladores de repositório, Versionamento de assemblies, Frameworks para execução de Unit Tests, Code Coverage, Métricas, Análises de Código, Deployment e Pacotes para Instalação. Um outro post interessante foi do Martin Fowler a respeito dos gargalos que às vezes podem ser gerados com builds quebradas em processos de integração contínua. Quando uma build é quebrada, o resto do time é afetado até que a build seja corrigida. A solução pode ser o uso de “branches privados” onde o desenvolvedor faz uma integração prévia antes de integrar com a mainline. Eu particularmente acho que alguma disciplina pode ajudar bastante em diminuir este problema. Práticas como, por exemplo, não integrar no fim do expediente e na iminência do horário de almoço, não realizar integrações simultâneas, deixar bem visível para o restante da equipe que há alguém integrando e evitar que desenvolvedores que estão integrando sejam interrompidos por qualquer motivo.

Posted by: alisson.vale
Posted on: 4/29/2007 at 11:39 PM
Categories: Projetos Ágeis | SCM
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
 
 
Apresentação do esquema de execução do processo de Integração Contínua no Projeto Phidelis. São exibidas a lista de ferramentas utilizadas e uma explicação geral sobre cada passo.
[More]

Posted by: alisson.vale
Posted on: 4/13/2006 at 3:25 AM
Categories: Projetos Ágeis | SCM
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (1) | Post RSSRSS comment feed
 
 
Sobre o desafio de aliar os processos de Integração Contínua, One-Step Build e One-Step Deployment. [More]

Posted by: alisson.vale
Posted on: 3/26/2006 at 8:13 PM
Categories: Projetos Ágeis | SCM
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
 
 
O DevConsole foi uma ferramenta criada para automatizar as principais rotinas do dia-a-dia do desenvolvedor. [More]

Posted by: alisson.vale
Posted on: 2/14/2006 at 3:13 AM
Categories: SCM
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
 
 
Portais Corporativos em Projetos de Software? Acho que tem tudo pra dar certo. Veja nesse post uma adaptação do texto introdutório do livro Portais Corporativos, de José Terra e Cindy Gordon, que contextualiza o uso de portais no contexto do ambiente de software. [More]

Posted by: alisson.vale
Posted on: 2/8/2006 at 10:06 PM
Categories: SCM
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (1) | Post RSSRSS comment feed