Sistema de controle de versão

• Um sistema de controle de versão (ou versionamento), VCS (do inglês version control system) ou ainda SCM (do inglês source code management) na função prática da Ciência da Computação e da Engenharia de Software, é um software com a finalidade de gerenciar diferentes versões no desenvolvimento de um documento qualquer. Esses sistemas são comumente utilizados no desenvolvimento de software para controlar as diferentes versões — histórico e desenvolvimento — dos códigos-fontes e também da documentação.

• Entre os mais comuns encontram-se as soluções livres: CVS, Mercurial, Git e SVN; e as comerciais: SourceSafe, PVCS (Serena) e ClearCase. O desenvolvimento de software livre prefere o SVN que vem substituindo o clássico CVS. Muitas empresas também adotam o SVN, embora algumas empresas prefiram uma solução comercial, optando pelo ClearCase (da IBM) ou SourceSafe (da Microsoft). Optar por uma solução comercial geralmente está relacionada à garantia, pois as soluções livres não se responsabilizam por erros no software e perdas de informações1 , apesar das soluções livres poderem ter melhor desempenho e segurança que as comerciais. As soluções comerciais apesar de supostas garantias adicionais não garantem o sucesso da implementação nem indenizam por qualquer tipo de erro mesmo que comprovadamente advindo do software.

• A eficácia do controle de versão de software é comprovada por fazer parte das exigências para melhorias do processo de desenvolvimento de certificações tais como CMMI e SPICE.2

Principais vantagens

• Controle do histórico: facilidade em desfazer e possibilidade de analisar o histórico do desenvolvimento, como também facilidade no resgate de versões mais antigas e estáveis. A maioria das implementações permitem analisar as alterações com detalhes, desde a primeira versão até a última.

• Trabalho em equipe: um sistema de controle de versão permite que diversas pessoas trabalhem sobre o mesmo conjunto de documentos ao mesmo tempo e minimiza o desgaste provocado por problemas com conflitos de edições. É possível que a implementação também tenha um controle sofisticado de acesso para cada usuário ou grupo de usuários.

• Marcação e resgate de versões estáveis: a maioria dos sistemas permite marcar onde é que o documento estava com uma versão estável, podendo ser facilmente resgatado no futuro.

• Ramificação de projeto: a maioria das implementações possibilita a divisão do projeto em várias linhas de desenvolvimento, que podem ser trabalhadas paralelamente, sem que uma interfira na outra.

Cliente-Servidor vs Distribuído• Sistemas cliente-servidor trabalha com um modelo centralizado no qual

existe uma copia do código corrente em um servidor central, no qual os usuários fazem “check-out” a fim de trabalhar localmente. Quando o usuário termina suas alterações, ele fazer um update (para validar se houve alterações durante o tempo que ele estava editando), lida com os conflitos que podem ter surgido e depois faz o “check-in” para que outros usuários possam fazer “check-out” novamente.

• Sistemas distribuídos são estruturados com ponto-a-ponto: ao invés de repositório centralizado, todos possuem seus próprios repositórios e sincronizam através de troca de mudança conjuntos na forma de patches, ou por merge de ramos de códigos (branches). No entanto na pratica a maior parte dos projetos com tamanho significante possuem uma única ramo nomeada como principal (trunk), mas isso é uma questão social e não técnica.

Distribuídos

• Fornece full backup da base de código e seu histórico com cada ramificação de código (branches), e existem muitos ramos de código.

• É mais fácil trabalhar uma conexão de rede, pois você pode fazer “commit” para sua copia local do repositório.

• Colaboração direta com outros desenvolvedores fica mais fácil, logo não é preciso passar pelo sistema central.

• Fácil criação e destruição de ramos códigos (branches), e de tal forma conduzir experiências quando desenvolvendo.

• Alguns veem como capacitando, encorajando novos desenvolvedores a se envolverem no projeto.

• É possível múltiplos ramos principais (trunks) de diferentes usos (estável, desenv ou ramos de releases, por exemplo).

• Commitar, visualizar histórico e outras operações similares são rápidos, já que não precisam acessar o repositório central.

• Merge em geral é muito mais fácil.

Cliente-Servidor

• É possível ter uma única pessoa ou entidade manter o controle do histórico a acessos ao projeto. (Em alguns casos visto como positivo outros negativos)

• Uma única “versão máster” do código é mantida centralizada em vez de ter múltiplas versões concorrentes.

• Um servidor central pode ser arquitetado e configurado para “tolerância a falhas”, em vez de confiar nas maquinas de muitas pessoas.

Boas Práticas / Trunk

• A pasta trunk é principal área de desenvolvimento.

• Todas as atualizações efetuadas dia-a-dia são armazenadas na pasta trunk.

• Geralmente contém os arquivos mais atuais do projeto, bem como as correções de bugs e os últimos recursos adicionados ao projeto.

• Branchs e tags em SVN são leves – no servidor, ele não faz uma cópia completa dos arquivos, apenas um marcador dizendo “esses arquivos foram copiados nesta revisão”, que ocupa apenas alguns bytes. Com isto em mente, você nunca deve se preocupar sobre espaço ocupado.

Boas Práticas / Branch

• A pasta branch contém uma cópia de determinada revisão de trunk quando este estiver estável ou for necessário criar uma nova funcionalidade que posteriormente será mesclada devolta ao tronco ou até mesmo para criar outra linha de desenvolvimento intependente do tronco.

Boas Práticas / Tag• Normalmente utilizada para lançamentos de “releases”, a tag

marca um ponto estável do desenvolvimento.A seguir um exemplo de utilização

• Um projeto inicia e um repositório é criado. Ex.: meuprojeto 1.0.

• O projeto é desenvolvido na pasta trunk.

• Quando chega a hora de liberar uma versão, a pasta trunk é copiada para a pasta branch e dado um nome de versão.

• Este branch é congelado e não sofre mais alterações, apenas correções. Rigorosos testes são efetuados.

• Quando os testes efetuados encima de um branch estão completos, a versão que se encontra no branch é copiada para a pasta tags, formando assim um “release” ou uma versão “liberada”. Ex.: meuprojeto 1.0.

• O projeto continua em desenvolvimento em trunk até que chegue a hora de lançar uma nova versão. Ex.: meuprojeto 2.0.

• Havendo mais algum bug na tag “meuprojeto 1.0″, será corrigido no branch correspondente e criada uma nova tag, evitando ter que liberar a versão mais nova – possivelmente inacabada ou não testada. Ex.: meuprojeto 1.1.

• Qualquer modificação em branch, deve ser copiada para a pasta de tags, após todos os testes.

Mercado Subversion (SVN)

Visual SourceSafe(VSS)

CVS

Team Foundation Server (TFS)

Perforce

ClearCase

Git

PVCS

StarTeam

Vault

MKS Integrity

Mercurial

Synergy

AccuRev SCM

CA Software Change Manager

Rational Team Concert

Proficiência

Resumo

• Achar o equilíbrio entre algo comercial ou comunitário, cliente-servidor ou distribuído, novo ou maduro, integrado ou stand alone etc ... são algumas das duvidas na escolha de uma solução para sua empresa. Deixo aqui dados analíticos e quantitativos para que você tome sua própria decisão. Lembrando que não existe o estado da arte então busque o equilíbrio.

Fontes :

• http://pt.wikipedia.org/wiki/Sistema_de_controle_de_vers%C3%A3o

• http://www.tuxradar.com/content/which-version-control-system-best-you

• http://www.scalevp.com/github-the-new-locus-of-software-development

• http://google.com.br