• Como era o método XYZ da classe FooBar na versão 2.0.3.12 do projeto?

• Quais foram as alterações feitas para incluir suporte à NF-e?

• Quando esta linha de código foi adicionada ao método XYZ?

• Consigo compilar e executar o sistema na versão 2.0.2.15 para reproduzir e consertar o bug de um cliente?

Se o seu controle de versão não consegue responder a estas perguntas, então está na hora de rever as práticas do seu time. Uma ferramenta de controle de versão não deve servir somente como um backup do código fonte, onde, ao final do dia, o desenvolvedor deposita seu trabalho inacabado. Ela deve ser um santuário, o repositório sagrado que exige do desenvolvedor todo respeito e cuidado. Afinal, o artefato mais valioso de um projeto, o código fonte, está guardado ali. Portanto, não basta instalar um controle de versão e sair usando. O time deve rever seus conceitos e absorver as mudanças necessárias, que podem ser dolorosas. No entanto, após um tempo, o time começa a colher os frutos do terreno bem preparado.

Há pouco tempo li um artigo muito bom do Eduardo Miranda sobre gerência de versionamento, onde ele cita algumas práticas boas e ruins. Vamos a elas:

Boas práticas

1. O código-fonte no servidor deve estar sempre pronto para compilação. Ou seja, a qualquer momento do dia deve ser possível buscar a cópia da última versão disponível do servidor e compilar uma nova versão da aplicação.

2. Toda changelist (conjunto de alterações que foram submetidas juntas) submetida visa melhorar o produto, nunca piorar. O código fonte é sagrado e deve ser total e completamente respeitado. Uma changelist corrige um defeito, adiciona uma funcionalidade, refatora um trecho de código. O desenvolvedor não pode submeter changelists que quebrem o build, seja pela adição de erros de compilação ou pela quebra dos testes automatizados. O time com o qual trabalho tem uma prática problemática que é fazer chekins parciais de código para compartilhar com outro desenvolvedor as alterações feitas. Não tem problema, desde que feito em um ramo de versão temporário especialmente criado para isso (também conhecido como branch). Assim, o ramo principal (o chamado trunk) não fica ‘contaminado’ com códigos incompletos. Somente quando toda codificação estiver terminada e os testes unitários completos, podemos fazer um merge do ramo temporário com o ramo principal. Claro que o trabalho é maior devido ao merge, mas a maioria das atuais ferramentas de CVS oferecem um bom suporte para isso.

3. Submeta suas alterações o mais rápido possível e com freqüência. Quanto mais tempo um arquivo fica em alteração mais difícil se torna seu merge e mais aumenta o risco de quebra do build. Divida suas alterações em pequenos pacotes compiláveis e testáveis e submeta sempre.

4. Oh-oh! Atenção, build quebrado! Se o build está quebrado não submeta alterações nem sincronize sua cópia de trabalho. Um build break é um estado que deve ser tratado com a máxima prioridade. Neste estado não é possível garantir que a sua alteração compila e não quebra testes, portanto não é possível garantir sua qualidade. Por outro lado, sincronizar sua cópia de trabalho irá corrompê-la, o que te impedirá de compilar e testar as funções localmente.

5. Controle tudo que é necessário para compilar e instalar a aplicação. Código-fonte não é a única matéria prima para compilação e instalação dos aplicativos. Sua aplicação pode depender de bibliotecas de terceiros. Neste caso, é necessário armazenar no repositório uma cópia do binário na versão utilizada pela aplicação. Em caso de atualização, a nova versão deve ser submetida junto com toda a alteração no código-fonte da sua aplicação necessária para suportar a versão.

6. Estabeleça critérios de qualidade. Código sem erros de compilação é o mínimo aceitável. A partir do momento que o objetivo passa a ser melhorar a aplicação, novos parâmetros de qualidade devem ser adotados para aprovação de um check in: código sem warnings e hints, testes unitários executados, métricas de complexidade mantidas, etc.

Práticas ruins

Qualquer prática que vá de encontro ao objetivo de ter no repositório uma versão compilável, testada e sempre melhor da aplicação, é uma prática ruim e deve ser evitada. Mas algumas são típicas e merecem destaque:

• Não submeta alterações em cima da hora. Sexta-feira, 18h, você louco para ir embora e não estará no sábado de amanhã de prontidão para resolver algum problema.

• Não segure as alterações em sua cópia de trabalho por muito tempo. Código-fonte fora de repositório estraga como comida fora da geladeira. Tentar submeter uma alteração feita há 2 meses no repositório gera um trabalho enorme e um elevado risco de quebra de build.

• Nunca ignore a política de check in. Mesmo alterações simples podem quebrar um build.

Finalizando

O controle de versão é provavelmente a ferramenta mais útil e fundamental no desenvolvimento de software e uma das mais utilizadas no dia-a-dia do desenvolvedor. É necessário sempre se preocupar com a facilidade de uso, para que ela não atrapalhe a produtividade nem caia em desuso, sem, contudo, abrir mão dos seus objetivos primordiais.