Os 10 erros mais comuns usando controle de versão

17 de maio de 2014 Por Ramon Durães

sourceA demanda por tecnologia está cada vez mais frequente e com isso tem ganhado grande impulso a busca por soluções de colaboração para permitir o trabalho em conjunto no mesmo projeto e no mesmo código fonte, tornando-se obrigatório a utilização de ferramentas para controlar a versão do código (Version Control).

O Source Safe desempenhou um grande papel na história das ferramentas de controle de versão se tornando muito popular na sua época, e com o tempo o grande número de novas necessidades de projeto ele acabou se tornando obsoleto para esse cenário de TI cada vez mais dinâmico e exigente.

Em meados de 2005 a Microsoft lançou oficialmente o Team Foundation Server, proporcionando uma experiência moderna na gestão de código fonte e ampliando o contexto para a nova demanda de gestão de aplicações (Application Lifecycle Management, ALM).

No o dia a dia acompanhando projetos de software nos mais variados cenários encontro muitos erros, desde técnicos e até conceituais sobre qual a proposta de uma ferramenta para controlar a versão do código fonte. Abaixo segue alguns itens que anotei ao longo do tempo.

1) Encher o controle de versão de arquivos binários
Na prática é como usar o repositório de “código” como uma lata de lixo digital. É importante separar o que é gestão de código fonte, gestão de arquivos (file system) e gestão de documentos (GED), que podem fazer parte de um contexto, porém atendem a princípios diferentes. Arquivos binários no controle de versão apenas se multiplicam ocupando espaço em disco e dificultando a manutenção e tempo de obtenção da versão.

2) Utilizar Branch como Label
Ao falarmos  sobre estratégia para gestão de configuração de software, ou simplesmente SCM, o profissional precisa entender claramente a proposta da criação de uma ramificação “Branch” e de um Label  “Baseline ou foto” e o que mais encontro são ramificações criadas em demasia com modificações frequentes nas mesas contrariando o conceito de “Baseline”.

3) Não subir um código fonte para o repositório
É muito comum encontrar pessoas que passam o dia trabalhando e não sobem as alterações para o repositório. Sincronizar suas alterações garante a sua segurança e da sua equipe em caso de falha em seu computador. Nada justifica tal falha. Você pode aplicar um Shelve e gerar um backup do seu código, ou se estiver no Branch trabalhará tranquilamente sem afetar os outros desenvolvedores.

4) Não efetuar um Get Latest
Antes de modicar um código é importante ter certeza que ninguém fez nenhuma alteração no mesmo, e fazendo essa pequena atualização você poderá evitar perda de tempo em um futuro merge para sincronizar as alterações.

5) Não limpar o controle de versão
Ao excluir um arquivo no Team Foundation Server ele é marcado como excluído, porém continua residente no banco de dados, e inclusive, se configurar o Visual Studio ele vai mostrar o mesmo. Por isso usuários com a permissão de administrador podem limpar sempre que necessário usando o comando Destroy para confirmar a exclusão definitiva.

6) Fazer um backup da versão no disco
Esse é um sintoma clássico que tem alguma gambiarra escondida. Se está baixando o código para fazer uma alteração local desconectado do controle de versão, certamente não está usando corretamente a estratégia de Branch. Da mesma forma se você salva e gera os executáveis locais está faltando no projeto um baseline e uma política de build para gerar sempre que necessário a versão desejada.

7) Corrigir um problema do cliente na versão atual em desenvolvimento
Esse é aquele momento que trocamos “as mina pira” pôr “os clientes ficam loucos”. Não tem punição pior para um cliente que reclama de um bug na versão 1.0 e recebe a versão 2.0 com a correção solicitada  (ás vezes) e mais uma tonelada de novidades e novos bugs. Esse número representa ainda 90% dos projetos no Brasil. Com o tempo o cliente aprende a não reclamar, pois sempre é punido com novos bugs. Você  se identificou nesse cenário?

8) Trabalhar com arquivos presos
Há 10 anos quando você iniciava sozinho uma tarefa durante meses eu até entendo, mas nessa nova dinâmica ágil e incremental, trabalhar com o recurso lock é um suicídio à produtividade. É inaceitável um profissional ficar parado aguardando outro liberar um arquivo. Sem falar naquele momento que ele travou e saiu de férias.

9) Não usar políticas de padronização de código fonte.
Cada projeto, conforme a sua estratégia, pode seguir uma linha para definir permissões nas pastas, branch para desenvolvimento paralelo e manutenções. Porém, é fundamental você entender que o controle de versão é uma extensão de um princípio maior que é ALM e podemos agregar muito se usarmos um Code Analysis, Code Metrics, validação de arquitetura, e principalmente, teste unitário e cobertura de código integrados ao Check-In, proporcionando o que chamamos de  Continuous Quality Enablement.

10) Esquecer de realizar backup do repositório central
Ao longo do tempo tenho escutado inúmeras histórias de projetos que iniciaram pequenos e foram crescendo com uso intenso do controle de versão, porém só lembraram dele no momento em que o disco rígido deu problema. Se você usa Visual Studio Online esse item já é eliminado automaticamente.

 

A ferramenta de controle de versão nos deu uma liberdade muito grande, permitindo colaboração entre as pessoas que agora podem trabalhar em qualquer parte do mundo conectadas e interagindo com segurança no mesmo projeto transportando atualizações de um lado para outro.

As ramificações “Branch” são um plus a parte, pois em uma mesma versão podemos ter pessoas trabalhando paralelamente em funcionalidades diferentes que podem ser liberadas a medida que estão sendo construídas sem afetar os grupos paralelos.

Hoje você consegue mapear quem mudou cada linha de código e reverter se necessário com segurança e agilidade em poucos cliques. Se os testes unitários estiverem ativos podemos, por exemplo, usando o recurso Gated Check-In do TFS disparar um processo interno para validar se gerou algum bug e recursar o código fonte. Eu fico emocionado toda vez que paro para analisar a quantidade de possibilidades que temos na gestão de código fonte.

Para saber mais:
Como gerenciar o código fonte de aplicações
O que é ALM?

Oportunidades para você aprender agora mesmo:
Curso Online ALM – Gestão ágil de projetos
Curso Online ALM – Gestão de código fonte

Até a próxima!! Vá em curtir e participe nos comentários

[],
Ramon Durães
Chief Technology Officer (CTO) na 2PC
MVP, Visual Studio ALM
PSM, CSM, PSD

Como planeja evoluir os seus projetos de software? Entre em contato e vamos agendar uma conversa sobre modernização de aplicações, Team Foundation Server, Visual Studio e serviços online em Cloud Computing no Azure.