Configurando um URL amigável no TFS (1 de 5): Application Tier
Como prometido, lá vai nossa série de posts sobre como configurar um URL amigável para o TFS. Nesta primeira parte iremos configurar o Application Tier – o “front-end” e principal componente do Team Foundation Server. Para isso precisamos:
- Criar um registro no DNS para o URL amigável;
- Configurar o host name no IIS (opcional);
- Configurar o URL público no TFS;
- Testar tudo. Ah, vale dizer que neste post não iremos tratar nem de SSL nem de load balancing (ambos alteram as instruções listadas aqui). Eventualmente tratarei de ambos em futuros posts.
Criar registro no DNS
Este deve ser o primeiro procedimento a ser realizado. Se sua empresa usa uma rede baseada em Active Directory, o registro DNS é tipicamente criado no servidor DNS do AD DS. Nesse caso, você provavelmente vai quere pedir para que o pessoal de infraestrutura da sua empresa crie uma entrada no DNS apontando para o IP do TFS.
A ou CNAME?
Tanto faz se o registro é um A ou um CNAME, desde que resolva para o IP do seu TFS.
Configurar Host Name no IIS (opcional)
Esta parte normalmente é opcional. Ao configurar o host name no IIS, você garante que o TFS responda apenas através do nome que você definiu. Isso evita que URLs inadequados (por exemplo, baseados no antigo nome do servidor) continuem sendo usado. Particularmente, gosto de fazer isso. IMPORTANTE: Se você pretende usar SSL para proteger seu TFS, configurar um host name deixa de ser opcional e passa a ser obrigatório. E lembre-se: o host name deve corresponder ao nome no certificado SSL! Abra o IIS Manager e edite os bindings do site do TFS: 
Agora, edite o binding do TFS (o padrão é *:8080) e coloque o nome amigável do seu TFS. Em nossos exemplos daqui por diante usaremos tfs.minhaempresa.com.br. Substitua pelo nome correspondente à sua instalação. 
Agora, seu TFS não irá mais responder através de nenhum outro endereço – nem mesmo localhost! Não se preocupe em testar sua configuração agora; faremos isso mais tarde.
Configurar o URL público no TFS
Esta parte é feita através do Team Foundation Server Administration Console. Em Application Tier, clique no link Change URLs. Lá você vai preencher o campo Notification URL: 
Notification URL? Server URL? Qual a diferença?
O TFS eventualmente precisa montar links que serão enviados para um usuário. Um exemplo disso é no caso dos Alertas. Quando o usuário recebe um alerta de que um item de trabalho foi alterado, recebe um link para poder visualizar esse WI. Obviamente, ele precisa receber um URL válido. Para isso, o TFS usa o Notification URL. Por isso, ele precisa ser sempre atualizado quando definimos um URL amigável. Já o Server URL tem outra finalidade. De acordo com a documentação do TFS:
Server URL is the URL TFS uses for communicating with itself. This should only be changed if (1.)TFS is only accessible via SSL. (In which case, the Server URL should be the fully-qualified-domain name) (2.) Localhost is disabled on the computer hosting TFS. (In which case, the Server URL should be http://computername:8080))
Entendeu? Server URL é “o URL que o TFS usa para falar com ele mesmo”. “Como assim?”, você deve estar se perguntando. “O TFS fala com ele mesmo? Ele é doido então?” 
Piadas à parte, concordo que essa explicação não explica nada. Deixa eu tentar melhorar essa definição, então. Numa mega-simplificação, o TFS Application Tier é formado por dois grandes componentes: o Team Web Access (TWA) e os Web Services. O TWA é o front-end do TFS, com o qual nós interagimos ao abrir o TFS num browser. Esse front-end precisa ser capaz de invocar os Web Services, pois é lá que está a verdadeira lógica do TFS. O Server URL, portanto, é o endereço que o TWA usa para invocar os Web Services. Em circunstâncias normais não precisamos nos preocupar com esse URL pois como os dois componentes estão no mesmo computador, usar localhost já resolve o problema. Porém, se você configurar um host name no IIS o localhost deixará de funcionar. Nesse caso, preencha o campo Server URL com o mesmo valor do URL público para que o TWA possa conversar os os web services do TFS – caso contrário, a interface Web simplesmente parará de funcionar!
Testar a configuração
Tudo pronto? Então agora vamos aos testes. Um pequeno roteiro de testes deveria conter:
- Abrir o TWA no browser a partir do console do servidor;
- Conectar ao TFS via Visual Studio Team Explorer a partir do console do servidor;
- Abrir o TWA no browser a partir de uma máquina de desenvolvimento;
- Conectar ao TFS via Visual Studio Team Explorer a partir de uma máquina de desenvolvimento;
- Caso você tenha configurado um servidor SMTP para o envio de alertas * A partir do TWA, abra um work item existente qualquer e selecione a opção Email Work Item. Verifique, ao receber o email, se o URL para o TFS está correto.
- Caso você tenha configurado o host name no IIS * Repetir os testes acima com o nome antigo do servidor, para garantir que ele não pode ser acessado. DICA: Se o DNS ainda não tiver sido atualizado, crie uma entrada em seu arquivo HOSTS (tanto no servidor do app tier quanto na máquina de desenvolvimento onde você vai fazer o teste) para que você possa testar sua infraestrutura.
Configurar BackConnectionHostName
| Esta parte é importante e pouco conhecida. Se você tentar acessar o TFS através do seu novo URL amigável a partir do console do app tier (ou seja, logado no servidor do TFS) vai se deparar com um erro de acesso negado. Isso se deve a uma proteção que o Windows oferece contra ataques de loopback. Basicamente, ela evita que um malware se instale em seu computador e intercepte suas chamadas à internet. Para contornar isso, precisamos colocar o URL amigável do TFS em uma white-list que o libera da checagem de loopback do Windows. Abra o Registry Editor do Windows e localiza a chave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0. Agora. clique com o botão direito e selecione New | Multi-Value String. Dê o nome de BackConnectionHostNames.  Agora dê um duplo-clique em BackConnectionHostNames para cadastrarmos o nome de nosso servidor:  Reinicie seu servidor. Agora se você tentar acessar o TWA a partir do console do application tier, vai funcionar como esperado:  Aguarde: em breve vêm os outros posts da série! Um abraço, Igor |
22/01/2015 | Por Igor Abade V. Leite | Em Técnico | Tempo de leitura: 5 mins.
