Esta semana, para aproveitar a mudança da sede da WhiteFox, resolvemos já também migrar o nosso Microsoft Team Foundation Server (TFS) de 2008 para 2010. Como toda instalação de TFS, estávamos bem preocupados, já que no 2008 uma instalação completa era sempre difícil de funcionar da primeira vez. No TFS 2010 não foi diferente, foram praticamente dois dias de trabalho de duas pessoas (dev e infra) para conseguir colocar tudo funcionando! Para que outros não tenham que passar por esta mesma sina, seguem abaixo algumas dicas e experiências que aprendemos na “marra”.

Primeiramente, resista à idéia de “vamos instalando” pra ver no que dá. Cada instalação de componentes do Windows 2008 e SQL Server deve ser feita de uma maneira específica ou então erros estranhíssimos acontecem. Tentamos desta forma inicialmente e obviamente, não funcionou. O TFS Installation Guide é, portanto, leitura obrigatória. Mas atenção que a versão que vem no DVD NÃO é a mais atualizada; é necessário baixar a mais atual da MSDN. O link para download está na primeira página do próprio Installation Guide. A versão mais atualizada é bem mais detalhada, com os passos mais específicos para cada item. Siga à risca! A única coisa que não seguimos foi com relação as permissões da conta TfsService. No Guide eles recomendam não dar privilégio administrativos; somente alguns específicos e “logon as a service”. Como esta parte era uma fonte enorme de dor de cabeça no TFS 2008, resolvemos ignorar e colocar esta conta como Domain Admin.

Um ponto que gerou uma dúvida seria se o TFS 2010 pode ser executado no Windows Server 2008 R2. Os pré-requisitos diziam que sim, mas eu encontrei alguns blogs afirmando que o suporte no R2 é possível, mas mais complicado. Acabou que confirmamos que de fato é possível, só não está claro no Installation Guide (a impressão que dá é que o Guide foi feito para o 2008, não para o 2008 R2) que o SQL Server 2008 não é compatível com o Windows 2008 R2, assim, imediatamente após a instalação do SQL Server, é necessário instalar o Service Pack 1.

Agora o ponto mais crítico que encontramos (e este nos fez perder quase 1 dia para descobrir o que era) é que, como toda empresa de desenvolvimento parceira Microsoft, nós utilizamos o SQL Server 2008 Developer Edition como banco de dados. Porém, a instalação desta versão tem uma característica única: ela por default não habilita o acesso TCP/IP. Sem este acesso, ocorre um erro na hora do installer do TFS criar o suporte ao ReportServer. E o erro é uma daquelas mensagens 0x8XXXX que não dizem absolutamente nada. Identificar este erro não foi simples, felizmente encontramos alguns blogs que acabaram nos apontando o caminho correto (isto depois de várias reinstalações frustradas). A correção, no entanto, é trivial: basta ativar o TCP/IP no SQL Server Configuration, imediatamente após a instalação do mesmo.

Com isto, tudo finalmente funcionou. O processo completo de instalação do Windows 2008 R2 + Sql Server 2008 + Sql Server 2008 SP1 + TFS demorou cerca de 2,5h no nosso hardware (que não é muito potente).

Após a instalação, nos deparamos com a nova feature do TFS 2010, que são as Project Collections. Ele cria uma por default na instalação, a “DefaultCollection”. No nosso caso, como temos vários clientes, resolvemos apagar esta e criar uma para cada cliente. Para apagar uma Project Collection, é necessário utilizar o “TfsConfig.exe”, que fica no diretório Tools de instalação do TFS 2010.

Ainda estamos analisando o uso das Project Collection. No Team Explorer, quando se abre uma Collection, ele fecha a anterior. Isto pode ser um problema para gente, já que temos projetos de infra-estrutura que são reutilizados entre os clientes. Mas iremos tentar esta abordagem e vamos ver como fica, já que ela aparentemente faz sentido.

Um último ponto diz respeito à segurança de acesso de collections criadas. No TFS Administrator, existe uma opção chamada “Group Membership”. Ali é possível dar permissão para outros usuários após a criação do mesmo. Porém, o problema do TFS 2008 permanece no TFS 2010, ou seja, dar permissão ali não significa acesso automático ao Sharepoint ou ReportServer. Assim, lembre-se sempre de dar permissões nestes dois itens após criar cada Collection. No ReportServer, isto pode ser feito na configuração raiz, vale para todas as Collections. No Sharepoint, é necessário fazer para cada site após a criação da respectiva Collection.

É isto pessoal, espero ter contribuído para tornar este processo um pouco menos penoso para outros. Por favor comentem caso tenham notado outros pontos ou se eu deixei alguma coisa relevante sem ser mencionada. Até a próxima.