Como todos nós sabemos o Visual Studio Team Services (VSTS) e o Team Foundation Server (TFS) disponibilizam dois controladores de versão diferentes, são eles:
- Team Foundation Version Control (TFVC)
- Git
Apesar de hoje dentro destas ferramentas termos condições de usar os dois controladores, fica a pergunta… Qual o melhor controlador de versão para o meu cenário?
Antes de respondermos esta questão é importante considerarmos algumas coisas… Por exemplo, o que um bom controlador de versão deve te oferecer? Sem dúvidas temos muitos controladores de versão no mercado mas nem todos fornecem recursos básicos que para o trabalhado de um Software Configuration Management (SCM) seja executado de maneira simples e correta, por isso eu costumo recomendar antes de mais nada que você analise se a ferramenta escolhida te oferece no mínimo:
-
Rastreio e controle de todos os artefatos de projeto. (código fonte, arquivos de configuração, documentação, etc).
-
Se o controlador disponibiliza cada versão já produzida de cada item do projeto.
-
Mecanismos para gerenciar diferentes ramos de desenvolvimento, possibilitando a existência de diferentes versões ao mesmo tempo (concorrência).
-
A possibilidade de se estabelecer uma política de sincronização de mudanças, evitando sobreposições.
-
Histórico completo de alterações sobre cada item do projeto.
Considerando que tanto o TFVC quanto o Git presentes hoje como opções para controle de versão dentro da plataforma de Application Lifecycle Management da Microsoft atendem este pontos que citei acima e que tanto o TFS quanto o VSTS podem inclusive trabalhar com os dois controladores no mesmo projeto e ao mesmo tempo, o fator decisivo para escolher entre um deles é conseguir diferenciar o propósito e o modelo de trabalho de cada um.
Team Foundation Version Control (TFVC)
O Team Foundation Version Control ou simplesmente TFVC é um repositório de código fonte e controlador de versão. Ele foi construído totalmente do zero, reescrito de forma a ser mais robusto e capaz de suprir eventuais necessidades que na época o Visual Source Safe não tinha condições de atender. Hoje o TFVC é uma das funcionalidades da plataforma de ALM da Microsoft.
Outra característica técnica e determinante para a escolha do TFVC como seu controlador de versão está no seu modelo de gestão que é centralizado, ou seja ideal para equipes centralizadas e que não possua problemas em trabalhar 100% conectados ao repositório central.
Repare que o modelo de arquitetura do TFVC temos sempre os workspaces interagindo com o repositório central no servidor, exigindo uma constante conexão para que o versionamento ocorra.
Conceitualmente para trabalharmos com o TFVC temos que saber o significado de alguns recursos, como:
-
Branch: é uma “cópia” isolada de histórico do controle de versão e metadados do item, uma ramificação do mesmo.
-
Check-in: sua confirmação das alterações feitas em seu espaço de trabalho para o servidor criando-se assim um changset.
-
Changset: é uma espécie de contêiner lógico contendo as alterações de um check-in.
-
Label: uma espécie de foto de uma versão especifica para um conjunto de arquivos no repositório.
-
Shelveset: um conjunto de alterações pendentes que podemos salvar temporariamente no servidor.
-
Workspace: é uma cópia local de sua base de código. Podemos inclusive criar vários espaços de trabalho e alternar entre eles, trabalhando em diferentes branchs ou cópias desta base central.
O Team Foundation Version Control, sem dúvidas hoje é um dos controladores mais robustos, estáveis e usados pelo mundo conseguindo se destacar em pontos como:
-
Simplicidade no uso;
-
Possibilidade de versionamento de binários;
-
Alto índice de compatibilidade;
-
Controle centralizado;
-
Recursos exclusivos como:
-
Gated Check-in
-
Shelvesets
-
Check-in Polices
-
Git
O Git é um sistema de controle de versão distribuído e um sistema de gerenciamento de código fonte focado na velocidade. O Git foi inicialmente projetado e desenvolvido por ele… Linus Torvads, para ser utilizado no desenvolvimento do kernel do Linux, mas acabou sendo adotado por muitos outros projetos.
Cada diretório de trabalho do Git é um repositório com um histórico completo e com habilidade total de acompanhamento de todo seu histórico de alterações, não dependendo de acesso a uma rede ou de um servidor central. Esta característica enquadra o Git como um controlador de versão que possui um modelo de gestão distribuído, facilitando times que precisam ou estão geograficamente distantes.
Note que o modelo de arquitetura do Git temos sempre os repositórios locais garantindo todo controle de versão localmente e somente em momentos específicos o sincronismo é feito com o repositório central.
O uso do Git como controlador de versão é extremante simples, exigindo apenas o conhecimento de alguns conceitos básicos como:
-
Branch: é um ponteiro nomeado para uma história de commit no repositório. Usado sempre para isolar as mudanças de cada servidor.
-
Commit: (substantivo)(principalmente) é equivalente ao changset do TFVC, mas também pode ser considerado uma ação.
-
HEAD: é um ponteiro para a branch e seus commits associados.
-
Stash: uma espécie de armazém com o conjunto de alterações pendentes temporariamente e que são salvos no repositório.
-
Tag: ponteiro nomeado para um commit no repositório. Muito útil para a marcação de determinado marco em seu repositório.
O Git hoje é um dos controladores de versão mais usados no mundo, justamente por suas facilidades e recursos que geralmente atendem todos os “gostos” como:
-
Projeção e expectativa de evolução alta;
-
Totalmente Open-source;
-
Modelo distribuído e descentralizado;
-
Cross-Plataform;
-
Recursos como:
-
Commits;
-
Git flow;
-
Pull request;
-
Branchs e merges;
-
A escolha?
Depois de conhecer um pouco mais sobre as características de cada controlador, fica muito mais fácil desenvolver uma opinião e chegar a uma conclusão mais efetiva para seu cenário, claro que não existe certo ou errado, melhor ou pior e sim momentos e situações em que cada controlador vai ser tornar “ideal”.
Portanto analise com calma seu cenário e tome um decisão técnica e coerente que atenda suas necessidades de negócios e permita um crescimento sustentável, e qualquer dúvida pode me avisar que será um prazer poder ajudá-lo nesta escolha.
[su_divider]
Não quer perder mas nenhuma informação sobre ALM e DevOps, então não esqueça de me acompanhar nas redes sociais
[su_table]
Youtube | News | ||
[su_qrcode data=”https://www.facebook.com/adrianobertucciMVP/” title=”Facebook” size=”50″ align=”center” link=”https://www.facebook.com/adrianobertucciMVP/”] | [su_qrcode data=”https://www.youtube.com/c/ALMBrasil?sub_confirmation=1″ title=”Youtube” size=”50″ align=”center” link=”https://www.youtube.com/c/ALMBrasil?sub_confirmation=1″] | [su_qrcode data=”https://www.twitter.com/adrianobertucci” title=”Twitter” size=”50″ align=”center” link=”https://www.twitter.com/adrianobertucci”] | [su_qrcode data=”http://bertucci.klickpages.com.br/buildnoturno” title=”News” size=”50″ align=”center” link=”http://bertucci.klickpages.com.br/buildnoturno”] |
[/su_table]