ALM

Team Foundation Version Control vs Git

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:

  1. Rastreio e controle de todos os artefatos de projeto. (código fonte, arquivos de configuração, documentação, etc).
  2. Se o controlador disponibiliza cada versão já produzida de cada item do projeto.
  3. Mecanismos para gerenciar diferentes ramos de desenvolvimento, possibilitando a existência de diferentes versões ao mesmo tempo (concorrência).
  4. A possibilidade de se estabelecer uma política de sincronização de mudanças, evitando sobreposições.
  5. 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.

2017-11-17_10h51_30

 

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.

2017-11-17_10h53_06

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:

  1. Simplicidade no uso;
  2. Possibilidade de versionamento de binários;
  3. Alto índice de compatibilidade;
  4. Controle centralizado;
  5. Recursos exclusivos como:
    1. Gated Check-in
    2. Shelvesets
    3. 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.

2017-11-17_11h30_37

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.

2017-11-17_11h34_03

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:

  1. Projeção e expectativa de evolução alta;
  2. Totalmente Open-source;
  3. Modelo distribuído e descentralizado;
  4. Cross-Plataform;
  5. Recursos como:
    1. Commits;
    2. Git flow;
    3. Pull request;
    4. 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.

 

Não quer perder mas nenhuma informação sobre ALM e DevOps, então não esqueça de me acompanhar nas redes sociais

Deixe uma resposta