Sim, eu deixei de usar o TFS. E acho que você também deveria.

(UPDATE 10/04/2023: Há uma versão mais nova deste artigo, refletindo algumas das mudanças no produto que ocorreram ao longo do tempo)

Já faz mais de dez anos que tenho confiado no TFS como minha ferramenta preferida de ALM para todas as minhas necessidades de desenvolvimento, bem como a de nossos clientes. Ao longo desse tempo, tenho visto uma impressionante evolução da ferramenta – só quem mexeu no TFS 2005 consegue entender o longo caminho que a Microsoft percorreu para chegar no que ela oferece agora com o TFS 2015.

Durante todos esses anos, eu tinha a nítida sensação que de o TFS seria sempre a melhor opção. A concorrência sempre pareceu estar sempre comendo poeira! Quem poderia ameaçar o lugar de destaque do TFS?

É, parece que eu estava errado e o que parecia improvável aconteceu. A bem da verdade, já faz algum tempinho: O TFS deixou de ser minha ferramenta preferida de ALM.

“Como assim?!” Para os leitores desse blog, a surpresa deve ser inevitável. Afinal, nunca escondi de ninguém que era um aficionado pelo TFS.

O céu está caindo!
O céu está caindo! (clique para ampliar)

Sendo assim, o que é que estou usando agora? Qual é o substituto do TFS para mim?

Bem, sabe aquele velho dito que “melhor que isso, só dois disso”? Então, para ser melhor que o TFS, só sendo um “TFS melhorado”.

Esse cara existe, e se chama Visual Studio Team Services (VSTS).

“Hein?”

OK, sei que ficou estranho :). Vou tentar explicar melhor.

TFS ou VSTS?

O Visual Studio Team Services (antigo Visual Studio Online) é uma versão SaaS do TFS. Em outras palavras, ao invés de comprar uma licença e montar uma infraestrutura com o TFS, você pode apenas “alugar” (na verdade, o termo é assinar) seu próprio TFS. Infraestrutura, segurança, recuperação de desastres, tudo fica a cargo da Microsoft. A nós cabe apenas subir o código-fonte e sair usando. E é justamente essa conveniência que, para mim, é o maior atrativo do VSTS quando comparado ao TFS – não preciso me preocupar em montar nem em manter uma infraestrutura interna só para ter um TFS à disposição. Mas é claro que a escolha não é tão simples assim.

Quando o VSTS é melhor?

Bem, comecei dizendo que acho o VSTS melhor que o TFS. Melhor eu começar explicando então o porquê disso. Eis alguns pontos em que o VSTS é superior ao TFS:

  • Novos recursos estão à disposição mais rápido. O Visual Studio Team Services tem uma cadência de atualização de três semanas. Em outras palavras, a cada três semanas novas funcionalidades são acrescentadas ao serviço. Já o TFS é atualizado, na melhor das hipóteses, a cada três ou quatro meses. Com isso, novos recursos (como as melhorias nos taskboards e nos dashboards, além do novo Release Management) já estão à disposição dos usuários do VSTS, enquanto os usuários do TFS aguardam meses por uma atualização. Além disso, não há downtime para a instalação do update, como ocorreria no TFS.
  • Dor de cabeça zero com infraestrutura. Quem já precisou montar um servidor, qualquer que seja, sabe que dá dor de cabeça. Configuração, instalação, manutenção, atualização, monitoramento… Na boa, tenho coisa mais importante para fazer com meu tempo. Se posso usar um serviço como o VSTS sem precisar montar uma infraestrutura, não penso duas vezes!
  • Alta disponibilidade. A Microsoft oferece um SLA de 99,9% no VSTS para clientes pagos. E se o serviço estiver disponível por menos tempo, é oferecido um desconto na mensalidade paga pelo serviço. Um SLA de 99,9% significa um downtime de 8 horas POR ANO. Um TFS on-premises provavelmente ficaria fora do ar mais tempo que isso apenas para aplicação de patches do Windows, sem contar as atualizações do próprio produto. Isso não quer dizer que não é possível ter alta disponibilidade com o TFS; apenas que o VSTS te dá isso de graça. Quem já precisou montar uma infraestrutura com HA (tendo que adicionar redundância a quase todos os componentes) sabe que isso tipicamente significa mais do que dobrar o custo da tal infraestrutura.
  • Acesso remoto mais simples e barato. Empresas que fazem terceirização de seu processo de desenvolvimento tem geralmente que criar VPNs e definir políticas restritivas de acesso aos recursos de sua rede interna para os desenvolvedores dos fornecedores. Isso custa caro para implantar e para manter. Já no caso do VSTS, o acesso se dá pela internet pública, de maneira segura e confiável. Bem mais conveniente que VPN.
  • Distribuição geográfica. Hoje há a opção de criar sua conta do VSTS em data centers nos EUA ou na Europa, com mais localidades a caminho. Ou seja, é possível colocar o VSTS mais perto dos desenvolvedores nos casos de desenvolvimento distribuído.
  • Múltiplos provedores de identidade. O TFS, para o bem ou para o mal, está limitado ao Active Directory como provedor de identidades. Já o VSTS pode usar o Azure Active Directory (incluindo aqui contas de nuvem ou contas de domínio via Azure AD Connect) ou então Contas Microsoft (Microsoft Accounts). Flexibilidade a toda prova!
  • OPEX. Parece bobagem, mas para muitas empresas a discussão CAPEX vs. OPEX (gastos de capital vs. gastos operacionais) faz uma diferença enorme em termos fiscais. Como o VSTS é um serviço, acaba sendo contabilizado como OPEX (ao contrário do TFS, que por ser uma licença que precisa ser comprada é CAPEX), o que pode significar menos impostos para algumas empresas.

Quando o TFS é melhor?

Se o VSTS é tão legal assim, então por que há tantas empresas que ainda preferem o TFS? Bem, os motivos mais comuns são:

  • Restrições à nuvem. Para muitas empresas, ir para a computação em nuvem não é uma opção. O motivo mais comum que ouço nessas empresas é “segurança”, o que tipicamente significa “não confio em deixar meu código na nuvem.” Bem, aqui entre nós: muitas dessas empresas que alegam não confiar na segurança oferecida por provedores de nuvem (sejam eles Microsoft, Amazon, Google e outros) costumam ser infinitamente mais inseguras, com processos falhos de hardening, monitoramento e auditoria. Mas essa discussão fica para outro post; o fato é que isso é um blocker para muitas empresas.
  • Customização. O TFS é altamente configurável, oferecendo desde a personalização de modelos de processos até plug-ins client-side e server-side. Afinal, o servidor é seu e você poder customizar como bem entender. O VSTS, por outro lado, não oferece a mesma flexibilidade.
  • Relatórios. O TFS oferece, out-of-box, um data warehouse com inúmeras métricas coletadas a partir da utilização da ferramenta, facilitando o acompanhamento dos projetos de desenvolvimento. Além disso, sua integração nativa com SharePoint, Reporting Services, Excel e outros significa que podemos criar ricos relatórios e dashboards.

Esses três pontos citados acima são os principais show-stoppers para a adoção do VSTS. Muitas empresas desistem sequer de ouvir falar sobre a possibilidade de usar o “TFS as a Service” por causa deles. Mas o quanto esses pontos são realmente relevantes hoje em dia? Como disse logo acima, não pretendo discutir aqui a questão de restrições à nuvem. Vamos falar, então, dos outros dois pontos.

Customização no VSTS

Hoje em dia o VSTS é quase tão personalizável quanto o TFS. Duvida?

  • Customização de Processos Agora é possível customizar os modelos de processo do VSTS exatamente como fazemos no TFS. Dá até para importar seus modelos customizados de processo do TFS no VSTS!
  • Relatórios. Com o novo suporte a dashboards e a integração com o Power BI, já dá para fazer quase tudo o que podíamos fazer no TFS. É bem verdade que ainda há relatórios que não estão disponíveis na nuvem, mas já estamos quase lá!

Conclusão

Hoje o Visual Studio Team Services oferece quase todos os recursos e benefícios do TFS, de maneira mais conveniente e barata. Quer experimentar o VSTS? Ele é de graça para até cinco usuários! O que você está esperando, caro leitor?

Você usa o TFS ou o VSTS? Tem vontade de testar um ou outro? Não deixe de compartilhar seus comentários!

Um abraço,

Igor



15/02/2016 | Por Igor Abade V. Leite | Em Técnico | Tempo de leitura: 7 mins.

Postagens relacionadas