Integração Continua: O Verdadeiro Foco G.C ou Q.A?

A assunto não é novo. Sempre que vejo na hypermidea e no mercado comentários sobre essa prática vejo sempre o foco em build, abstraindo o máximo possível e fazendo um esforço alguns até enfatizam com foco em gerencia de configurações.

Não há dúvidas que Gerencia de Configuração é uma disciplina esquecida aqui no brasil, fora do país até vejo movimentações sobre o assunto mas lá também existe uma grande deficientes de profissionais nessa área.

Você conhece alguém que é ou quer ser gerente de configurações? São raros talvez achar um gnomo laranja venha a ser uma tarefa mais fácil do que achar um GC. Isso acaba afetando muito um projeto de software, bom que conhece Casos de uso e utiliza estimativas através do Use Case Point sabe a disciplina de ambiente podem diminuir até 38% da complexidade do projeto.



Esse é um número muito alto. Isso se divide em:

• Planejamento de Release: As trocas de versão são complicadas e se perde muito tempo para colocar uma versão no ar, se acontece algum problema não existe procedimentos de rollback e logo todos viram bombeiros.
• Ambiente: Cada programador novo na equipe é um novo parto. Várias coisas devem ser configuradas na máquina do desenvolvedor, mas ninguém sabe bem de cor tudo e todos os ajustes que devem ser feitos.
• Bugs: É complicado reproduzir bugs pois como cada desenvolvedor acaba usando uma versão diferente de cada coisa e não existem sandboxes a coisa fica quase impossível de ser reproduzida, coisa leia-se suposto bug.
• Controle de Versão: Um software de SCM acaba sendo usado como um mero sistema de backup de luxo. Pois como não existem políticas de branches tudo fica como cada um quer, sem falar na falta de comentários nos comits que ajuda muito na hora de um merge no qual ninguém sabe que código fica e que código sai.

Acredito que essa pode ser a vida de muitos dos leitores, não posso negar que já vivi projetos que eram assim. Não adianta também ter um gerente configurações se ele implanta o modelo de branches pro promoção :(

Precisamos de gerentes de configurações, alavancando essa disciplina podemos melhorar muito a produtividade da equipe e isso irá acontecer somente com pessoas, processos e ferramentas!

A Integração Continua não é uma prática que requer Gerencia de Configuração mas requer muito de Q.A também, e isso se da em dois pontos chaves. Nos testes e nas métricas! De nada adianta uma máquina fazendo builds de hora em hora se nada é testado, no final essa máquina vira um compilador de luxo, é isso ai por que assim ela só pega erros sintáticos.

É mais do que necessário testes, e não falo só de testes unitários, testes automatizados também. Com testes podemos tirar o real projeto de um servidor de build continuo que é o feedback rápido de que algo está errado e precisa ser corrigido.

As métricas vão ser feitas em cima do build e não digo apenas métricas do tipo quantidade de bugs, mas digo métricas de qualidade de código através de ferramentas como o Checkstyle e o PMD. Se você usa uma boa ferramenta de CI como o Hudson você pode tirar proveito dessas ferramentas de maneira muito produtiva.

Eu acredito que o Hudson no momento é a melhor solução de Build Continuo open source em Java que existe no mercado. Por que?

• Integração com Maven 2
• Integração com diversos controles de versão como o SVN 5
  
• Grande número de Plugins
• Muito fácil de instalar (só colocar o .war no Tomcat)
• Integração com várias ferramentas de Issue Tracking
• Metáfora da previsão do tempo

Para utilizar uma solução de Build Continuo precisamos de esforços em GC + Q.A como já dito antes, mas ter testes, métricas e usar uma ferramentas como o Hudson não é o suficiente. Precisamos nos preocupar com o ambiente.

Para o ambiente a melhor prática a ser utilizada é a prática de múltiplas Sandboxes. Confira a figura a baixo.

O princípio das sandboxes é simples, diversos ambientes com bancos de dados diferentes. O Ambiente de produção também é considerado um sandbox. Quanto mais perto da sandbox de desenvolvimento mais instável e mais fácil e menos custoso de se mudar algo é!

Assim agora estamos cobrindo melhor a disciplina de ambiente a qual está muito bem guarnecida pelo RUP; Esse deve ser o contexto de utilização de um servidor de build continuo, com todas essas ligações com outras disciplinas.

Somente com a utilização de todas essas práticas das 3 disciplinas: CM (Gerencia de Configuração), Q.A e Ambiente que poderemos colher ótimos frutos em nosso projeto e alavancar muito a produtividade.

Esses são pontos em que muitos projetos falham. Muitas organizações até já se deram conta da importância dessas áreas mas infelizmente tirando Q.A está faltando gente :(