Oito razões para preferir TFVC ao invés de Git
Se você está usando o TFS 2013 ou o Visual Studio Online, pode já ter se deparado com esta dúvida ao criar um novo projeto: “TFVC ou Git?”
Muitas pessoas respondem automaticamente “Git” a essa pergunta, assumindo que a introdução do suporte a Git no TFS é sinal de que o TFVC está obsoleto e vai ser eventualmente descontinuado.
Nada mais equivocado.
Entretanto, esse equívoco está disseminado. Tanto que o Brian Harry precisou escrever mais um post sobre o TFVC. Como ele mesmo disse:
From time to time I get the question “Is TFVC dead?” I guess I have to just keep answering it. No, it is not.
Bom, já que ele garantiu que o TFVC não está morto – pelo contrário! – então resta a pergunta: quando escolher um ou outro?
A amiga Patrícia Mantovani fez um pedido específico neste sentido:
Bom, Pati, seu pedido é uma ordem! :-)
TFVC é melhor que o Git. E ponto.
Claro que isso foi uma provocação. Mas há cenários em que o TFVC supera o Git. Avalie os pontos abaixo; se eles forem importantes para você, fique tranquilo e vá para o TFVC sem medo.
- Simplicidade de uso: Vamos começar por um dos pontos mais polêmicos. Não acredite naqueles que te disserem que o Git é simples. Como qualquer ferramenta de controle de versão distribuído (DVCS, Distributed Version Control System) ele é inerentemente complicado. Controles de versão centralizados são mais simples de se aprender e, além disso, estão aí há mais tempo e portanto as pessoas estão mais familiarizadas com seus conceitos essenciais. Não ignore a curva de aprendizado do Git, pois ela é íngreme. Por conta disso, à maioria de nossos clientes de ALM sugerimos que optem pelo TFVC a menos que seus times de desenvolvimento precisem dos benefícios do Git e estejam prontos para o custo de adoção do Git.
- Gated Check-in: A possibilidade de rejeitar um check-in se ele não passar por um build de verificação (chamado de “Gated Check-In” no TFS) é um recurso que, por enquanto, está disponível apenas para TFVC. Em Git, isso tipicamente é resolvido de outra maneira (via build de pull request) mas de qualquer maneira Gated Check-In, out-of-box, somente para TFVC.
- Arquivos binários: Git é, sabidamente, limitado no tratamento de arquivos binários – principalmente arquivos binários grandes, como vídeos. Tanto isso é verdade que existem até alternativas específicas para essa finalidade. Já o TFVC, por outro lado, não tem problemas com arquivos binários. A Microsoft tem testes feitos com repositórios com dois extremos – milhares de versões de arquivos binários de diversos tamanhos e grandes arquivos com centenas de megabytes – sem qualquer tipo de degradação de desempenho.
- Controle centralizado: A natureza centralizada do TFVC – em oposição à descentralização do Git – é um ponto forte para muitas empresas, que se sentem inseguras em terem seus repositórios (e todo o seu histórico) clonados nas estações dos desenvolvedores. Seja por motivos regulatórios ou simplesmente por política interna, o TFVC oferece um nível de granularidade nas permissões de acesso ao controle de versão – podendo limitar acesso a pastas e/ou arquivos específicos – que, de outra forma, não seriam possíveis no Git.
- Shelvesets: Outro recurso exclusivo do TFVC são os shelvesets – mini-repositórios no TFS onde um desenvolvedor pode guardar e compartilhar arquivos sem afetar o controle de versão. Sim, você pode obter resultados parecidos com private branches no Git, mas eles não oferecem a mesma simplicidade e suporte ferramental que temos para os shelvesets. Um exemplo dos benefícios exclusivos dos shelvesets é o conceito de build privado no TFS: com ele é possível disparar um build para validar suas alterações antes de fazer um check-in (o Gated Check-In é uma variação de Build Privado). Build de Pull Request ofereceria algo similar, mas ainda não está disponível no TFS.
- Check-in policies: Disponível desde a primeira versão do TFS, o conceito de política de check-in (verificações client-side, em tempo de check-in, a fim de garantir que o desenvolvedor está atendendo a políticas pré-definidas pela empresa) existe hoje apenas para TFVC. Por isso, se sua empresa precisa – por exemplo – garantir que um desenvolvedor sempre associe um item de trabalho a um check-in, só consegue fazê-lo no TFVC. Eventualmente devemos ter algo similar no Git, mas hoje só tem para TFVC.
- Integração com IDEs Microsoft: Quer você goste, quer não, o fato é que nem todos os desenvolvedores gostam de usar a linha de comando. De fato, muitos deles preferem não sair do seu IDE para nada. Para esses devs, integração nativa da ferramenta de controle de versão é indispensável. E para aqueles que usam as ferramentas de desenvolvimento da Microsoft – desde o VB6 até o Visual Studio 2015 – o suporte a TFVC vai de melhor opção (VS2012+) a única opção (< VS2010).
- My Work, Code Review e CodeLens: Outro caso de funcionalidades que ainda não estão integradas ao Git: My Work, Code Review e o recurso de Incoming Changes do CodeLens só funcionam em repositórios TFVC.
Mas o Git também pode ser melhor que o TFVC
Só que essa discussão vai ficar para um próximo post.
E você, caro leitor? Qual sua opinião? Lembra de outros cenários que não foram discutidos neste post? Discorda de alguns argumentos usado aqui? Não deixe de comentar!
Um abraço,
Igor
13/03/2015 | Por Igor Abade V. Leite | Em Técnico | Tempo de leitura: 5 mins.
