Arquitetura de Alta Disponibilidade para o TFS

O esquema a seguir foi derivado de uma implementação de alta disponibilidade que fizemos para o TFS. Tem umas escolhas de arquitetura legais, estão comentadas a seguir:

• Usamos máquinas virtuais para hospedar os servidores. Isto permite diminuir o número de hosts físicos a gerenciar.
• Usamos NLB para o TFS, o SharePoint e o Reporting Services, e Failover Cluster Feature para o SQL Server (Database Engine) e o Analysis Services. Estas são as tecnologias de alta disponibilidade recomendadas pela Microsoft para cada um dos produtos citados.
• A distribuição dos nós de cada cluster (NLB ou Failover) em hosts físicos distintos permite que os serviços sobrevivam à queda de um dos hosts.
• Para os produtos em NLB, além da alta disponibilidade ainda há a vantagem da distribuição de carga entre os servidores. Além disto, o cluster NLB detecta automaticamente o retorno de um servidor que havia caído, reincluindo-o no processo de distribuição de carga.
• No caso dos produtos em cluster, como o Failover Cluster do Windows não suporta modo "ativo-ativo", no qual ambas as máquinas respondem a requisições, colocamos a máquina que é o nó ativo do cluster para o Database Engine como sendo o nó passivo do cluster para Analysis Service, e vice-versa. Isto evita a existência de uma máquina "parruda" (como tem que ser um servidor SQL Server) e "parada" (o nó passivo), pois ambas respondem a requisições.
• Antes tínhamos uma instância do SQL Server para o TFS e outra para o SharePoint; agora ambos usam a mesma instância. Isto permite um melhor uso de recursos, p.e. RAM não usada por um produto pode ser usada por outro, o que não acontece em instâncias separadas.
• O uso de um alias DNS para os clusters NLB tornam manutenções, movimentações e substituições de servidores invisíveis às máquinas dos desenvolvedores. Aliás o uso destes alias para é uma boa mesmo se você não tem um NLB por trás, exatamente pelas razões apresentadas.

Projetinho simplezinho mas bonitinho. Vai ficar mais bonito quando a gente jogar o Lab Management aí dentro.

Recursos de Formação – TFS

Pra quem quer começar ou se especializar um pouco mais em TFS, aí vão alguns recursos gratuitos:

• Visual Studio 2010 and .NET Framework 4 Training Course > Application Lifecycle Management
  Laboratórios baseados na Visual Studio 2010 RTM Virtual Machine with Sample Data and Hands-on-Labs, cobrindo a parte de testes (Test Manager 2010), planejamento de projetos, branching e merging, e mais.
• Introduction to Visual Studio Team Foundation Server 2010 Training Kit
  Apresentações, hands-on labs e demos sobre TFS 2010.
• Visual Studio ALM Rangers > Rangers Solutions and Projects
  Guias de práticas recomendadas em diversas áreas do TFS (branching, planejamento, customização de builds, testes, banco de dados, etc).
• MSDN Virtual Lab: Team Foundation Server 2010 Training
  VM’s acessadas via Internet Explorer contendo dados e software para praticar conceitos básicos do TFS:
  Parte 1: Team projects e work items
  Parte 2: Source Control e Portal do Projeto (SharePoint)
  Parte 3: Gerenciamento de Requisitos com work items
• Alguns bons blogs de TFS
  Brian Harry: http://blogs.msdn.com/b/bharry/
  Visual Studio ALM + Team Foundation Server Blog: http://blogs.msdn.com/b/visualstudioalm/

Ambiente de Testes Virtualizado com Controlador de Domínio

Não sei direito porque, mas ouvi o pessoal de infra falando sobre problemas se serviços do seu domínio (tais como SQL e Exchange) sobem antes do controlador de domínio. Montei um domínio de testes para desenvolvimento no TFS e esbarrei nesse problema: serviços não subiam ou a conectividade entre eles não funcionava. Como as VM’s estão no Hyper-V, dá pra colocar um “atraso” no boot das máquinas, então configurei o DC sem o delay, e as outras máquinas com um delay de 30 segundos. Na tela de configuração de cada VM que deve subir com o delay:

Desta forma, o controlador de domínio sobe antes das outras VM’s, evitando esse tipo de problema.

tf rollback: Como voltar os fontes para um determinado ponto do desenvolvimento

Comé que a gente volta o código da nossa aplicação pra um determinado ponto do sistema no TFS?

Bem, a ferramenta dá o suporte, mas você tem que ter processo. Tem várias formas de fazer isto. Uma delas é usando labels. Pra poder voltar em um ponto no tempo, você tem que fazer o seguinte:

1. Combinar com a equipe. É, porque todo mundo tem que saber dessa combinação, preparar os fontes nos quais estão trabalhando para isto, e fazer checkin.
2. Aplicar um label aos fontes. Na janela do Solution Explorer, botão direito no diretório no qual estão os fontes desejados, opção "Apply Label".

Esta label vai ser seu "ponto no tempo" para o qual você pode voltar os fontes. Depois de tocar horror no código, pra voltar pro momento no qual você colocou a label, faça o seguinte:

1. Abra um "Visual Studio 2010 Command Prompt".
2. (opcional) Use o comando tf labels para listar o nome da label para a qual você quer fazer o rollback:
   

   tf labels *@$/Projeto /owner:* /collection:http://server:8080/tfs/testcollection

3. Mude para o diretório aonde estão os itens nos quais você deseja fazer o rollback.
4. Rode o comando tf rollback para voltar o código para o ponto desejado:
   

   tf rollback /toversion:L"Solução Criada" HelpDesk /recursive

Este último comando volta os fontes para o estado em que estavam quando a label "Solução Criada" foi aplicada. O diretório atual é o diretório imediatadamente acima do diretório "HelpDesk", no qual estão os fontes do sistema. O utilitário tf faz checkout de todos os arquivos a modificar e retorna os mesmos para o estado da label "Solução Criada". Quando você fizer o checkin agora, a solução estará como estava quando a label "Solução Criada" foi aplicada.

Como apagar um work item do TFS

O TFS 2010 não tem na sua interface gráfica um comando para apagar um work item. Isso pode ser um incômodo em algumas situações, como p.e., quando você criou o work item como filho do "pai errado". Para apagar um work item do TFS é necessário rodar uma ferramenta de linha de comando. Em C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE, execute

witadmin destroywi /id:215 /collection:http://servidortfs:8080/tfs/DefaultCollection

aonde "215" é o Id do work item a ser apagado, "servidortfs" é o nome do seu servidor TFS, e "DefaultCollection" é o nome da coleção de projetos aonde seu projeto está.

Listar arquivos com check out no TFS

O Visual SourceSafe tinha uma opção de menu bem legal: "Status Search", que permitia ver todos os arquivos "checautados" por alguém. O TFS Source Control Explorer não tem esta opção (ainda, espero) na sua interface, mas existe um utilitário de linha de comando chamado TF.EXE que faz isto.

Abra um prompt de comando, e vá para o diretório %Program Files%\Microsoft Visual Studio 10.0\Common7\IDE (%Program Files% em Windows de 64 bits é o diretório "Program Files (x86)"), e execute a seguinte linha:

tf status $/...ponto_raiz_da_verificação /recursive /user:*

Se houver aquivos checautados por alguém, eles serão listados.

Check-outs Múltiplos no TFS

Equipe de geeks (2: eu e o Luti). Instalamos o Visual Studio 2010 (beta, of course, que geek que se preza não trabalha em software estável), com o Team Foundation Server, e criamos nosso primeiro projeto. Depois de algum estudo do Azure, começamos a codificar. Criamos nossas primeiras classes.

"Editei o ContextoDados.cs. Tenta editar ele aí", diz o Luti. Nem sei de onde ele tirou a idéia de testar o TFS SCC (Source Code Control - o Controle de Código Fonte - do TFS, sucessor do Visual SourceSafe). Bem, fiz aquela cara de ai-meu-saco-tenho-mais-o-que-fazer-e-claro-que-vai-funcionar-tudo, e fui fazer o check-out. "Uai", sai sem querer a exclamação mineira, depois de 20+ anos aqui no DF. "Não é que checkautô?". O Luti faz aquela cara de toma-seu-mané. "Fiz check-in. Altera alguma coisa aê e faz check-in também", ele diz. Eu faço uma alteração e, na hora que tento fazer check-in, aparece uma tela de resolução de conflitos de edição. Auto-Merge, Merge Manually, Changed, Deleted, Next, Previous... Tudo pronto pra causar uma boa confusão. Uai de novo. Isso já não funcionava redondo no Visual SourceSafe?

O TFS SCC vem com duas modificações radicais nas suas configurações default, em relação ao SourceSafe:

• A primeira: check-outs múltiplos são permitidos por default. No VSS, o check-out múltiplo podia ser habilitado, mas o default era check-out simples: somente um desenvolvedor pode travar um dado arquivo para edição. Se outro desenvolvedor tentasse travar o mesmo arquivo (o check-out), ele receberia uma mensagem e não conseguiria editar o arquivo.

Esta até que não chega a ser tão problemática assim. Da primeira vez que houvesse um check-out múltiplo, apareceria a tela de resolução de conflitos de edição, e alguém falaria "Opa! O check-out múltiplo está habilitado". Aí é só desabilitá-lo e tudo ok.

• O problema sério é a segunda modificação. Quando um desenvolvedor faz um check-out, ele *não* recebe a última versão do arquivo armazenada no servidor!!! Isto significa que, se você tem uma versão antiga de um arquivo na sua máquina,e faz check-out deste arquivo, você vai editá-lo sem receber as modificações já feitas por outros desenvolvedores.
  

Ok, quando você fizer check-in, vão aparecer conflitos para todas estas modificações; mas somente pela quantidade de conflitos caso sua versão seja muito antiga, e pela proximidade do botão "Next", há um grande potencial para que modificações sejam perdidas. De fato, ao pesquisar sobre o assunto, encontrei relatos de equipes que, em apenas algumas semanas de trabalho, já estavam experimentando este tipo de problema.

As configurações default do Visual SourceSafe evitavam estes dois problemas. No VSS, o check-out múltiplo era desabilitado por default, ou seja, só um desenvolvedor pode trabalhar em um arquivo em um determinado momento. E quando você fazia o check-out, você rebebia a última versão do arquivo. Isto podia quebrar a sua compilação local, por o seu código não estar de acordo com as modificações mais recentes feitas no arquivo recebido durante o check-out. Mas isto obrigava você a manter o seu código atualizado. E evitava que seu check-in sobrescrevesse coisas que outros já tinham feito.

Se você, como eu, a torcida do Vascão e a maioria dos desenvolvedores prefere o esquema do VSS, basta abrir o projeto no Team Explorer, fazer duplo-clique no item Source Control, e no menu Team, selecionar a opção Team Projet Settings > Source Control. Em seguida, inverta a seleção de opções:

Opções de check-out no TFS 2010

Desta forma o SCC do TFS irá trabalhar como o VSS, quanto às suas configurações de check-out.

Não Adiantou Mas Foi Legal

Coloquei uma sugestão pra poder inserir uma opção de menu no Team Explorer 2010 que excluísse um projeto do TFS. Foi educadamente recusada pela Microsoft, mas pelo menos foi bom ver que não foi um auto-reply que gerou a resposta; foi alguém que conhecia do produto. O link pra sugestão está em http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=488149. Legal esse Connect.

Como Excluir um Projeto do TFS

Vai entender. Pra você criar um projeto no Team Foundation Server, a Microsoft disponibilizou um wizard com interface gráfica muito fácil de usar. Agora pra excluir um projeto (team project, no jagão do TFS), tem que entrar em ferramenta de linha de comando. No grupo de programas do Visual Studio (estou usando o 2010, mas deve servir para 2005 e 2008 também), tem uma pasta chamada "Visual Studio Tools". Entre na opção "Visual Studio 2010 Command Prompt", e digite o seguinte comando:

tfsDeleteProject /server:url_do_tfs nome_projeto

O primeiro parâmetro, url_do_tfs, deve ser a URL aonde seu Team Foundation Server está instalado. Cuidado neste parâmetro, ele deve ser a URL exata do TFS, incluindo número de porta e caminho completo. P.e., no meu servidor, a URL usada é http://srv07:8080/tfs. O segundo parâmetro é o nome do projeto (deve estar entre aspas duplas caso o nome do projeto contenha espaços).

No Team Explorer tem uma opção "Remover", que remove o projeto do Team Explorer, mas sem apagar ele do TFS. Por que não colocar uma opção "Excluir" também??? Vou sugerir lá no Connect...