Como disse no post anterior, do meu ponto de vista é possível fazer muito melhor na área do desenvolvimento. Existem muitos pontos dos quais vale a pena falar, mas existe um mais de fundo, um ambiente de desenvolvimento automatizado, que me parece particularmente entusiasmante. Este conceito - a Integração Contínua - foi popularizado pelas metodologias ágeis, como a Extreme Programming. Com a  plataforma .Net, e com a ajuda de um infraestrutura de suporte, ficam criadas finalmente as condições para que este conceito se torne realidade e acessível às pequenas e médias equipas que trabalhem com tecnologia Microsoft. É meu objectivo falar deste assunto ao longo de vários posts, onde aproveitarei para introduzir outras ideias que também terão direito ao seu espaço próprio.

Para concretizar o conceito, é fundamental o auxílio de uma série de aplicações que só com o advento do .Net surgiram no mundo Microsoft. Todas as aplicações que irei discutir são da Microsoft ou então são freeware, normalmente Open Source. O esquema apresentado em baixo é uma versão ainda algo rudimentar da arquitectura de um ambiente de desenvolvimento que adopta a Integração Contínua, tal como eu o imagino.

Ao longo dos próximos posts tentarei descrever o processo em detalhe, mas para já vou descrever resumidamente o fluxo.

1. O desenvolvimento é feito em modo isolado pelos diversos elementos da equipa. Quando estes consideram que a solução se encontra estável, fazem check-in desta no SourceSafe. O Korby Parnell tem um blog onde fala da nova versão do SourceSafe.
2. O CruiseControl.Net monitoriza o SourceSafe, de acordo com um período configurado por nós, para detectar novas versões da solução. Quando detecta uma nova versão, retira-a do SourceSafe e inicia o processo de build, permitindo detectar potenciais conflitos criados pelos novos desenvolvimentos e problemas não detectados localmente. Este passo é o cerne da Integração Contínua.
3. Se o processo de build correu sem problemas, a nova versão é distribuída pelas diversas máquinas: para os servidores, de imediato; para as máquinas locais, conforme o definido. Se o processo detectou algum erro, o processo de deployment não é iniciado.
4. O CruiseControl.Net publica os resultados num site que fornece diversas estatísticas sobre o processo, permitindo a toda a equipa estar permanentemente a par do estado e do progresso da solução.
5. Os elementos directamente envolvidos no último build são notificados por e-mail, indicando os resultados obtidos.

Uma solução é considerada estável quando: compila sem erros; os testes de unidade, criados com o NUnit, passam todos; o código está conforme com as linhas de orientação definidas pela Microsoft e por nós na ferramenta FxCop; a percentagem do código exercitado é superior a um determinado valor, sendo verificado pelo CoverageEye.Net. Todos estes passos são configurados na ferramenta de build MSBuild.

Este post já vai longo, mas já devem ter percebido que há muitos temas para reflexão.

Até à próxima.

---

Posted 29-3-2004 10:09 por João Hugo Miranda