terça-feira, fevereiro 28, 2006

Ferramenta para revisões e inspeções de código

Este artigo fala sobre uma interessante ferramenta que possui como foco facilitar o processo colaborativo para a realização de revisões e/ou inspeções de código via web. A ferramenta se chama Codestriker e é escrita em Perl.

A instalação da ferramenta (apesar de ser em Perl) é bem simples e o manual da ferramenta facilita muito o processo. O manual realmente é bem completo tanto no aspecto de instalação quanto no aspecto de configuração e uso.

Vamos mostrar como funciona o processo de criação e gestão das revisões de código.

A tela inicial mostra todos os tópicos abertos e permite a criação de novos.



Podemos criar tópicos de diversas maneiras. A tela abaixo mostra a criação de um tópico que vai pegar as diferenças diretamente do repositório Subversion definido na configuração. No caso ele irá gerar a diferença entre a revisão 5 e a 6 na linha principal de desenvolvimento. O email dos revisores é colocado para que eles possam receber uma mensagem de que um tópico de revisão está disponível.



Quando o tópico é criado uma URL é mostrada. Ela pode ser útil pois você pode usá-la em algum wiki ou então para colocar em algum issue de revisão na ferramenta de bug tracking. O tópico criado mostra o seguinte:



A tela do tópico mostra as diferenças entre as revisões lado a lado:



Um tópico também pode ser criado usando um arquivo gerado pelo svn diff. Essa forma é utilizada caso você queira que uma revisão seja realizada antes de fazer o check-in do código novo:



E você também pode submeter através do upload um código-fonte inteiro. Esse é um processo muito útil para revisar tudo que foi realizado até um certo ponto. A tela com o resultado mostra todas as linhas de um arquivo:



A lista de tópicos mostra então os tópicos abertos:



A inclusão de um comentário pode ser feita no nível de tópico, no nível de um dos itens de revisão (pode haver diffs de vários fontes diferentes em um único tópico) ou no nível de uma linha de código. No exemplo abaixo cliquei na linha 13 do código e assim a ferramenta abre uma janela no estilo AJAX, para eu inserir o comentário:



Quando o comentário é submetido a linha com o comentário fica com uma cor diferenciada para facilitar a revisão dos comentários pelos revisores ou a pessoa que irá corrigir o código:



E o melhor... ao passar o mouse em cima de uma linha marcada uma janela AJAX abre mostrando o comentário, sem necessidade de mudar de página:



Mas caso tenha interesse você pode clicar na aba "Topic Comments" para ver todos os comentários ordenados:



Na aba "Topic Information" encontramos algumas métricas específicas do tópico:



E você também pode analisar as métricas de todos os tópicos:




A ferramenta ainda possui uma integração com duas ferramentas de bug tracking: Bugzilla e FlySpray.

Um item que falta na ferramenta é o controle de usuários. Não existe nenhum tipo de controle de acessos com login e senha. Mas a idéia da ferramenta é ser colaborativa e creio que esse recurso tenha ficado em segundo plano.

Além disso no arquivo de configuração você pode definir níveis de métricas diferentes para suportar um processo mais formal como, por exemplo, os itens definidos por Gilb e Graham no livro Software Inspections.

Marcadores:

domingo, fevereiro 19, 2006

Integração contínua e gestão de builds com Luntbuild

Esse artigo mostrará as possibilidades existentes na interessante ferramenta open source Luntbuild. Seu objetivo principal é o de ser um sistema de gestão e automação de builds, permitindo também a criação de um ambiente de integração contínua. Existem outras plataformas interessantes para a Integração Contínua como o CruiseControl e o Anthill. Além disso uma matriz de ferramentas(livres e proprietárias) dessa categoria existe comparando seus recursos. O CruiseControl é tema do fantástico livro Pragmatic Project Automation e sua leitura é muito interessante para melhorar a qualidade em projetos de desenvolvimento de sistemas. Seu autor também possui um excelente blog sobre o tema de automação.

Vou comentar apenas alguns benefícios da Integração Contínua, já que estes foram analisados magistralmente por um artigo de Martin Fowler e Matthew Foemmel. A prática da Integração Contínua é elevar ao extremo a prática crítica na estratégia de desenvolvimento de empresas como Microsoft e Netscape que ficou conhecida como "Daily Builds and Smoke Tests" e analisada por Steve McConnell em seu livro Rapid Development e também em um artigo do IEEE.

Os principais benefícios são:

- Minimizar os impactos da integração entre módulos
- Detectar defeitos em ciclos rápidos
- Melhorar a moral do time
- Ter um sistema estável sempre, ainda que não completo.

E como funciona esse processo, independententemente da ferramenta utilizada? Uma explicação será dada a seguir,para depois entrarmos nas particularidades do Luntbuild:

Passo 1: Os desenvolvedores da equipe fazem alterações em códigos-fonte, fazem merge caso necessário, compilam e executam os testes unitários automatizados e fazem o check-in (ou commit) dos códigos na linha ativa de desenvolvimento da ferramenta de controle de versões.

Passo 2: A ferramenta de Integração Contínua acorda a certos períodos de tempo (a literatura do assunto recomenda colocar períodos entre 15 a 30 minutos) e verifica se novo código foi colocado na linha ativa do sistema de controle de versões.

Passo 3: Se sim, a ferramenta de Integração Contínua extrai todo o código-fonte da aplicação e a compila no servidor isolado que tem por objetivo gerar build limpos.

Passo 4: Se compilado, a ferramenta de Integração Contínua executa outras tarefas que podem ser definidas pela ferramenta de build como: compilar e executar testes unitários, de aceitação, gerar relatórios dos testes, de cobertura e de análise estática do código.

Passo 5: A ferramenta de Integração Contínua atualiza os dados da página Web do projeto com todos os resultados da execução do build e com todos os fontes alterados e com os dados de quem fez cada alteração.

Passo 6: A ferramenta envia mensagens (por e-mail, pager, MSN, etc) para a equipe informando o resultado do processo de build durante a Integração Contínua.

Antes de mostrar um processo exemplo que pode ser definido no Luntbuild seguem algumas considerações sobre alguns de seus recursos:

- De forma diferente do CruiseControl, toda a configuração é feita através da aplicação Web e não através de arquivos XML.
- Cada build pode ter um link para um relatório HTML em JUnit. Senti falta de links para cobertura de código e análise estática e, dessa forma, customizei(um pequeno hack) para que eles também fossem arquivados com o build e que links fossem colcoados na página de detalhes do build.
- Você pode criar tipos de schedules diferentes para um mesmo projeto. Isso é útil como iremos demonstrar no exemplo. Você pode criar por exemplo um processo para integração contínua, outro com um build diário e um manual para gerar o release ao final de cada iteração do projeto.
- A ferramenta possui integração com uma boa variedade de sistemas de controle de versão como: AccuRev, ClearCase Base, ClearCase UCM, CVS, Perforce, Subversion, Visual SourceSafe e StarTeam.
- A ferramenta possui integração com as seguintes ferramentas de build: Ant, Maven, Maven 2, Arquivos batch ou shell, Rake.
- Um recurso para habilitar o refresh do site web está disponível, o que permite um ótimo meio de criar radiadores de informação com um monitor de builds pendurado, por exemplo, nos corredores do departamento.
- Sua facilidade de instalação e configuração é um grande benefício para projetos de pequeno e médio porte, que querem iniciar rapidamente um processo de integração contínua e gestão automatizada de builds.

Antes de iniciar é importante comentar que o grande segredo para iniciar qualquer processo de integração contínua é possuir um script de build completo que gere todos os artefatos do projeto. E este deve ser utilizado como forma preferencial para construção de builds também pelos membros da equipe em seus repositórios individuais de trabalho. O script construído também provavelmente mudará no decorrer do projeto mas ter uma base inicial robusta é chave para o crescimento.

Criei um exemplo simples de aplicação contendo duas classes Java e duas classes de testes. As ferramentas open source que utilizei para permitir uma maior qualidade de código são:

- JUnit para criar os testes de unidade.
- Cobertura para instrumentar o código e gerar relatórios de cobertura de linha, de branch e complexidade ciclomática.
- PMD para gerar um relatório de análise estática de código.

Como ferramenta de controle de Versões utilizei o excelente Subversion.

Eu construí um script Ant de exemplo que possui os seguintes "targets":

- compile para compilar o código-fonte.
- instrument para instrumentar o código-fonte para análise de cobertura.
- compile-tests para compilar os testes em JUnit.
- test para executar todos os testes unitários e gerar os relatórios HTML de testes realizados e da cobertura de código.
- pmd para gerar o relatório HTML com a análise estática do código.
- clean para limpar o diretório onde o build e seus resultados são gerados.
- javadoc para gerar a documentação das classes.
- zip para gerar um arquivo zipado com todos os artefatos relevantes para executar o sistema.

Agora vamos mostrar algumas das telas do Luntbuild para demonstrar o processo que ele permite criar em um projeto (não incluí as telas de configuração necessárias para gerar o projeto, a integração com o sistema de controle de versões, com o Ant e o scheduler ).

Primeiro criei um scheduler para realizar o processo de integração contínua no projeto exemplo. Este verifica de dez em dez minutos se alguma mudança ocorreu na linha de desenvolvimento trunk do repositório de projeto:



Após dez minutos o Luntbuild entra em execução no scheduler de Integração Contínua:



Depois do refresh o ícone verde aparece, sinalizando um build bem sucedido:



Clicando nos detalhes desse build encontramos a seguinte tela:



Notem que aparecem links para um relatório em JUnit, Cobertura, PMD, o log do build e o log de revisão. Os relatórios de Cobertura e PMD foram incluídos através de um pequeno hack no Luntbuild. Clicando no relatório do PMD podemos ver uma falha simples que incluí no fonte para gerar essa mensagem. Simplesmente não coloquei chaves em um dos ifs:



As próximas telas são o resultado da excelente ferramenta Cobertura. Notem que na tela de detalhes ele mostra em vermelho exatamente qual linha não foi exercida pelos testes:





A seguir as telas dos relatórios JUnit:





O Build Log mostra os detalhes de saída da execução do Ant:



E o Revision Log mostra quem e quais alterações foram feitas para disparar a execução do build da integração contínua:



Mas também queremos oferecer uma versão ao final de cada dia (no caso do exemplo às 18:00 hs) que pode ser utilizada como base para os testes de aceitação dos analistas de testes no dia seguinte ao build. Então criamos um scheduler de um build diário:



Mas qual a diferença desse build diário para o de Integração Contínua? Em primeiro lugar ele executa o "target" zip do script Ant o que faz o Luntbuild armazenar o zip resultante na área Artifacts. Ele também sempre executa no horário determinado, sem se importar se houve ou não novas alterações. O Zip poderá ser usado pelas equipes que querem testar a última versão supostamente mais estável(pois pelo menos compilou e passou nas baterias de testes unitários automatizados e possivelmente em "smoke tests"):



Clicando no link de histórico podemos ver um sumário de todos os builds já executados(é possível também fazer uma busca por um build específico):




Por fim criamos um scheduler chamado Build Release. Ele executa apenas através de comando manual e usualmente será feito para gerar um release a cada iteração, que pode ser usado para testes de aceitação finais e para um release interno com o intuito de obter análise e feedback dos usuários e clientes:











Outra funcionalidade extremamente interessante do Luntbuild. Ele pode criar uma tag caso o scheduler seja configurado com essa solicitação. No caso você pode criar uma tag para os builds diários(tendo assim como recuperar a versão de cada dia passado no projeto) bem como no build de release(para recuperar uma versão de uma determinada iteração ou de entrega ao cliente). Na tela abaixo o log do repositório após a tag gerada pelo Luntbuild com a execução do Build de Release:



E para demonstrar um erro fiz uma alteração em dois testes de unidade para forçar erros em dois métodos. No script Ant que criei coloquei uma diretriz que no caso de uma falha em qualquer teste de unidade o build deve ser considerado um build falho:





O relatório dos testes de unidade apontam onde ocorreu o erro. E o revision log aponta quem fez os últimos check-ins do período e em quais fontes:







Dessa forma temos um feedback rápido de qualquer quebra de build. É possível configurar o processo de Integração Contínua para enviar um e-mail apenas no caso de um build com falha. A garantia de uma versão integrada minimiza os impactos clássicos dos últimos dias de cronogramas de projetos sequenciais, onde a equipe acaba deixando de realizar os testes pois está ocupada demais tentando encontrar a quantidade de erros geradas por falhas de integração e bugs em geral.

Algumas funcionalidades que creio tornariam a ferramenta ainda mais interessante:

- Esquema de promoção de builds. Atualmente a ferramenta open source só move o build de um scheduler para outro e sem alterar os números gerados (por exemplo, mudar o build diário ProjExemplo-2006-feb-18.1 para ProjExemplo-1.0). Na versão paga chamada QuickBuild isso já existe. Parece que está no backlog do produto open source também.

- Mostrar os comentários da ferramenta de controle de versão Subversion no Revision Log.

- Integrar com as ferramentas de issue tracking (gerenciamento de incidências) como Bugzilla, Eventum, Mantis e Jira. A ferramenta proprietária Parabuild possui já essa funcionalidade.


Nesse artigo mostramos como o Luntbuild pode ajudar a criar um processo de Integração Contínua e de gestão automatizada de builds. Creio que ela é robusta o suficiente para atender a equipes de pequeno e médio porte com facilidade. Um processo mais completo de engenharia de builds e releases, usado em equipes muito grandes desenvolvendo um sistema específico é descrito no livro The Build Master : Microsoft's Software Configuration Management Best Practices.

Lembrando que o Luntbuild é atualmente específico para aplicações Java e J2EE. Para .NET pode-se usar NAnt ou MSBuild como ferramentas de build e o CruiseControl .NET ou o Draco .NET como ferramentas de Integração Contínua(lembrando que o Visual Studio Team System também terá essas ferramentas dentro de sua solução).

É importante sempre frisar que a mudança de paradigma das pessoas para um processo iterativo e incremental é crucial para o sucesso de uma estratégia de integração contínua. A adoção do Test-Driven Development por todos os desenvolvedores da equipe também é o que garantirá uma maior qualidade na entrega do sistema, um feedback rápido da Integração Contínua e uma melhoria na manutenibilidade futura do sistema.

Marcadores:

domingo, fevereiro 05, 2006

Ambiente de desenvolvimento de Software para .NET

Escrevi um artigo e uma apresentação no início do ano retrasado acerca de ferramentas para o suporte à Engenharia de Software no ambiente .NET. Este artigo mostra ferramentas para a plataforma .NET, que permitem a realização de testes e a melhoria da qualidade do produto de software. Explica sobre ferramentas para testes unitários, automação de builds, cobertura de código, análise estática de código e integração contínua. Comenta sobre como elas se encaixam dentro de um processo de desenvolvimento de software maduro e como auxiliam na qualidade de um projeto na plataforma .NET.

As ferramentas específicas são: NUnit, DotNetMock, NAnt, FxCop, NCover e CruiseControl .NET

O interessante é que algumas dessas ferramentas foram diretamente incorporados pelo Visual Studio Team System 2005 enquanto os conceitos de outras também geraram a base do novo produto de desenvolvimento da Microsoft.

A boa notícia é que temos essas ferramentas disponíveis também para o Visual Studio .NET 2003 e ainda por cima livres.

O artigo e a apresentação se encontram na seção de downloads do meu site em meu novo domínio erudio.com.br .

Marcadores:


Veja as Estatísticas