Por que eu devo ler este artigo:Qualidade de software e Integração Contínua (IC) são dois assuntos que fazem parte do desenvolvimento de grandes projetos de software. A capacidade de utilizar ambos é um dos diferenciais no desenvolvimento de uma excelente aplicação.

Além disso, como veremos ao longo do artigo, a Integração Contínua nunca será completa sem a garantia da qualidade de software. Ao longo desse artigo, iremos fazer uma breve introdução à Integração Contínua em .NET com Hudson, bem como demonstrar a utilização do Sonar como ferramenta de qualidade de software com esse servidor de IC.

A integração contínua é ferramenta essencial no desenvolvimento de grandes projetos de software. Entre as vantagens que esse recurso traz para as empresas está a capacidade de garantir que as muitas partes do software estejam integradas ao longo do projeto.

Esse tipo de atitude evita que haja atrasos ao final do desenvolvimento, o que era muito comum no desenvolvimento de aplicações há algum tempo. A ideia por trás da integração contínua é que as equipes de desenvolvimento realizem commits a um servidor central sempre que o código for alterado.

Então, automaticamente, o servidor irá realizar o build nesse código e, normalmente, aplicar testes sobre o mesmo.

A questão da qualidade de software é outro ponto essencial no desenvolvimento de software. Embora a qualidade propriamente dita seja muito relativa, uma vez que o que é bom para um pode não o ser para outro, existem algumas métricas que podem ser utilizadas para garantir a qualidade de software.

Essas métricas, basicamente, visam garantir que o software cumpre os requisitos inicialmente estipulados para o mesmo. Pensando nisso, a medição da qualidade de software é um ponto importante no desenvolvimento de software. Existem algumas ferramentas que auxiliam as equipes de desenvolvimento nesse caso, e o Sonar é uma delas.

Trata-se de uma ferramenta que irá avaliar diversos aspectos do código, como complexidade, número de comentários, arquitetura e design, cobertura de código (BOX 1), entre outros.

BOX 1. Cobertura de código

A cobertura de código é um termo utilizado no desenvolvimento de software que está diretamente ligado aos testes. Trata-se do nível de cobertura que os testes oferecem ao código.

Em outras palavras, a porcentagem de código-fonte que possui testes atribuídos. Uma cobertura de código de 100%, obviamente, deve ser o objetivo final. Entretanto, isso não é comum, devido ao fato de que um grande projeto terá milhares de métodos, sendo alguns deles extremamente simples.

Por isso, uma cobertura de código a partir de 90% já pode ser considerada excelente.

Ao longo desse artigo iremos apresentar uma das principais ferramentas de integração contínua em .NET: o Hudson. Iremos ensinar como implementar um simples projeto exemplo e verificar como realizar a conexão desse projeto com o Sonar para verificar a qualidade de código.

Apresentando a Integração Contínua

A integração contínua é uma técnica que visa fazer com que o software esteja finalizado no momento que o último pedaço de código é concluído. Entretanto, a implementação dessa técnica não é das mais simples, normalmente. Exige um conhecimento grande por parte de quem está implementando a mesma, além de uma boa vontade da equipe de desenvolvimento.

A IC pode ser considerada o grande divisor de águas no desenvolvimento de software atual, uma vez que ela irá alterar radicalmente o modo de pensar das equipes sobre o processo de desenvolvimento. Essas mudanças serão finalmente benéficas, embora possa haver alguma resistência por parte da equipe de desenvolvimento com relação a mudanças.

Até o momento, temos falado de integração contínua de forma bastante genérica. Mas, afinal, o que é a integração contínua? O principal fundamento da integração contínua é facilitar a manutenção do código.

Entretanto, há muito mais que pode ser feito com a IC. A IC basicamente deve construir (build), testar, analisar e implementar uma aplicação para garantir que o processo inteiro está funcionando seguindo as melhores práticas de desenvolvimento.

Esse processo deve ser executado a cada alteração no código (commit por um membro da equipe) e permite uma resposta imediata para os membros do time, possibilitando também um meio de saber o que os outros membros da equipe estão realizando e se eles estão realizando corretamente.

Esse tipo de procedimento permite também que a IC seja utilizada como uma forma de mensurar o tempo gasto pelo time de desenvolvimento em alterações no código, ajudando a definir custos de processos e melhorar os mesmos.

A implementação da integração contínua pode ser dividida em sete ciclos, começando por uma empresa que não possui nenhum tipo de servidor centralizado até uma em que a integração contínua está implementada de forma completa.

Esses ciclos envolvem um processo de maturação da empresa, e não podem ser aplicados de uma hora para outra. Os 7 ciclos estão explicados brevemente a seguir.

1. Nesse ciclo, não há um servidor centralizado de código, e todos os builds são realizados na máquina local do desenvolvedor;

2. A criação de um servidor centralizado foi realizada, e agora os desenvolvedores podem realizar commits de suas alterações nesse servidor;

3. Já existem alguns testes automatizados e o time começa a tirar proveito de algumas características da integração contínua. O servidor também possui a capacidade de alertar os membros da equipe sobre alterações realizadas;

4. A verificação de qualidade começa a ser implementada nesse ciclo, seguindo métricas comprovadamente eficientes. A organização do sistema nesse ponto permite a chegada de novos membros à equipe facilmente;

5. A confiança no resultado dos builds automatizados é bastante grande, e é possível a utilização de técnicas como a TDD (Test-Driven Development – Desenvolvimento Orientado a Testes);

6. A implementação do sexto ciclo envolve a implementação dos servidores para testes de aceitação e implementação, preparando a empresa para a filosofia da entrega contínua;

7. A confiança em todos os testes automatizados é completa, e pode ser permitido ao servidor de IC implemente técnicas automatizadas diretamente na produção, o que começa a configurar a Entrega Contínua (BOX 2).

BOX 2. Filosofia de Entrega Contínua

A entrega contínua é um fundamento extremamente interessante do desenvolvimento de software. Nos últimos anos, especialmente, essa filosofia começou a fazer parte do dia-a-dia das empresas. Essa filosofia faz com que seja possível que grandes empresas façam vários lançamentos de software diários, utilizando um pipeline totalmente automatizado.

A utilização da entrega contínua deve ser o objetivo final de qualquer integração contínua, criando um pipeline totalmente automatizado. E isso tudo é realizado através de uma premissa muito simples: cada mudança de código é implementada diretamente na produção. Essa simples alteração no pensamento traz um grande impacto no desenvolvimento de software.

Vemos que a integração contínua envolve a adaptação da equip ...

Quer ler esse conteúdo completo? Tenha acesso completo