O envio de alertas por e-mail quando um evento acontece no projeto do time pode ser muito importante quando falamos de integração.

Com os Project Alerts é possível, por exemplo, enviar e-mails para o responsável pela tarefa quando ela for atribuída a ele ou quando sofre modificações; pode-se enviar uma cópia para o responsável pelo projeto quando a tarefa é finalizada, entre outros fins. Porém, o template de e-mail nativo do TFS pode não ser satisfatório para o time.

Vamos falar um pouco mais sobre os Project Alerts abaixo.

Como funciona?

No servidor de aplicação, há um agente (TFSJobAgent) que fica aguardando algum evento para disparar os alertas. Os eventos podem ser:

- Modificação em um work item;

- Um check-in é realizado;

- A qualidade de um build é modificado;

- Um build termina;

Entre outros que podem ser criados. Os templates de email (tanto texto plano quanto HTML) ficam armazenados na seguinte pasta, no servidor de aplicação do TFS:

[Drive]:\ Program Files\Microsoft Team Foundation Server 2010\Application Tier\TFSJobAgent\Transforms

Dentro dessa pasta, você encontrará dois arquivos para cada tipo de evento. O arquivo de extensão “plaintextxsl” define o template de e-mail em texto plano, enquanto o de extensão “xsl” define o formato do email HTML, além do arquivo TeamFoundation.xsl, que é como um template, uma casca (como uma Master Page) para os demais arquivos. A partir daí, cada arquivo de cada evento importa este arquivo e define as outras informações a serem exibidas.

Quando o agente identifica o evento, ele recebe uma coleção de informações contendo os campos do work item e/ou do evento para gerar uma saída com base nos arquivos mencionados acima. São elas:

- CoreFields: contém os campos e seus conteúdos, cujo namespace é System.*.

- ChangedFields: contém os campos que foram modificados neste evento.

Um fator muito importante é: campos que estão fora do namespace System.* (ou campos non-core) não são enviados nesta coleção por questões de desempenho. Portanto, se quiser, por exemplo, mostrar o campo “Start Date” (Microsoft.VSTS.Scheduling.StartDate) e ele não tiver sido modificado, não será possível recuperar essa informação no alerta.

Como customizar?

No nosso exemplo, vamos customizar o alerta de Work Item modificado no formato HTML. A modificação que faremos é simples: a linha que contém o “Assigned to:” deve ficar em negrito e removeremos a linha que contém o “Changed date:”. O que temos hoje é:

E para fazer essa modificação, vamos seguir os passos abaixo (faça back-up dos arquivos antes de começar a customização):

- Abrir o arquivo WorkItemChangedEvent.xsl em algum editor de XML ou no próprio Visual Studio;

- Dentro do arquivo, procure pelo trecho “ReferenceName[.='System.AssignedTo”. Verá que existe uma definição de uma linha de tabela (TR). Assim:

Interpretando esse trecho de código: na primeira célula da linha (PropName), ele coloca o título do campo, que é “Assigned to:”. Na segunda (PropValue), é inserido o valor.

Dentro dessa segunda TD você pode enxergar uma estrutura de repetição (foreach) e uma de validação (IF) onde ele varre os campos da coleção CoreFields em busca de um campo do tipo “System.AssignedTo”; se encontrar, exibe seu valor, através da propriedade “NewValue”.

Vamos fazer uma simples modificação de HTML. Colocaremos a tag de bold (“<b>”) nas duas tds. Fica assim:

Sobre o Changed Date, basta procurar pelo texto “System.ChangedDate” no código e remover a TR que á contém.

Depois dessas edições, salve o arquivo e faça alguma modificação em algum work item para disparar o evento. No meu caso, o resultado foi o segunte:

Daí pra frente é só ir brincando com os campos e com o template dos alertas.

[]’s

Ricardo Serradas

Muito falou-se sobre uma das features mais esperadas da versão 2010 do Visual Studio Team Foundation Server: o Gated Check-in. Neste post, vamos fazer um raio-x deste mais novo aliado na luta por uma integração contínua mais forte e código fonte de nossas aplicações de melhor qualidade.

De uma forma geral, como ele funciona?

Quando um desenvolvedor efetua um check-in, ele recebe uma notificação dizendo que suas alterações devem ser compiladas antes de serem persistidas no controle de versão. O TFS então desvia essas alterações para um shelveset. No servidor de build é feito um unshelve dessas alterações e em seguida todo o código é compilado. Se o build tiver sucesso, um novo changeset é criado a partir do shelve e o check-in é feito em nome do desenvolvedor.

Como configurá-lo?

Para que o Gated Check-in seja usado no seu time, precisamos criar uma Build Definition com essa característica. Vamos ver como funciona:

Vamos assumir que já temos configurado nosso servidor de build e que ele está definido como Build Agent e Controller no TFS.

Não vamos entrar em detalhes sobre a configuração completa de um build definition por não ser o foco principal deste post. Sendo assim, durante a configuração de uma build definition, vemos várias abas. Uma das abas que nos interessa neste momento é a de nome “Trigger”. É nela onde definimos que essa build configura o Gated Check-in:

Um passo muito importante (e que chega até ser uma “pegadinha”) no processo de configuração está na próxima aba, que é a “Workspace”. É lá que definimos para qual estrutura de pastas esta build funcionará. Veja:

Isto significa que esta política de gated check-in somada ao build automatizado só vai ser disparado se uma tentativa de check-in for realizada na estrutura de diretórios abaixo de $/TFS10Demo/dotnet/GatedCheckinDemo.

Se esta configuração não for feita da forma correta e, por exemplo, se deixarmos este campo com “$/”, esta política se aplicará para todos os projetos desta coleção. Sendo assim, um check-in em qualquer outro Team Project será barrado por este Gated Check-in e o código do projeto GatedCheckinDemo será compilado sem real necessidade.

Salvas essas e outras configurações, vamos testar se nosso Gated Check-in está funcionando. Para isso, vamos modificar algum fonte que está versionado debaixo da estrutura definida no workspace. Depois disso, vamos efetuar um check-in. Após isso, recebemos a seguinte mensagem:

*Ao clicar em Build Changes, uma nova build é disparada e as pendências de check-in na máquina do desenvolvedor são desfeitas, ficando apenas no shelveset que será usado pelo servidor de build.

Se tudo der certo, se tudo foi bem codificado e o processo de check-in foi bem feito (Get Latest Version antes, tentativa de compilação e etc), será mostrada essa mensagem na tela do desenvolvedor que efetuou o check-in:

Ela informa que o build teve sucesso e que as suas alterações foram persistidas no controle de versão. Se a opção para preservar os check-outs ficou marcada na hora de submeter o build, use o botão “Reconcilie…” para acertar seu workspace. Se não, basta apenas ignorar a mensagem e rodar um Get Latest Version para obter suas próprias alterações.

Já se o build falhar, uma janela semelhante será mostrada, sugerindo dar o unshelve das alterações que foram enviadas para que a correção possa ser feita.

* A opção “Bypass validation build and check-in my changes automatically on your behalf” é, por padrão, desabilitada para membros do grupo “Contributors”, que é o grupo onde costuma-se incluir desenvolvedores.

Você já conhecia este novo conceito? Gostou desta nova funcionalidade? Tem críticas? Comente!

[]’s

Ricardo Serradas

Para quem é daqueles que está sempre querendo estar um passo à frente, é uma informação muito importante. A Microsoft já disponibiliza para download um kit de aprendizado sobre o Visual Studio 2010 e o Team Foundation Server 2010. As máquinas virtuais existem nas versões para Windows Virtual PC, Microsoft Virtual PC e Hyper V.

Este material contém tudo que é preciso para estudar e entender as capacidades desta poderosa ferramenta de ALM (Application Lifecycle Management). Inclusive, a base de dados do TFS já vem populada com dados de exemplo. Há apenas uma exceção: as funcionalidades de Lab Management não estão inclusas. Ainda espera-se uma novidade vinda do time de produto relacionada a isso.

Abaixo, o link para download de cada uma das versões:

• Windows 7 Virtual PC
• Microsoft Virtual PC SP1
• Hyper V

As máquinas tem validade até 9 de abril de 2010, data de expiração do trial do SQL Server. Notificações de ativação serão exibidas durante o uso, comportamento normal de uma versão trial do Windows. Não há com o que se preocupar.

Boa diversão!

[]‘s
Ricardo Serradas

A mensagem de erro, depois que descobrimos a solução, é bem clara: “verifique se o servidor SQL está no ar ou se você tem permissão para acessá-lo“. Não é bem o servidor SQL, e sim o servidor de relatórios, o Report Server.

Ao acessar http://[TFSSERVER]/Reports com o TFSSETUP (usuário que usei para instalar todo o TFS) vi que não conseguia enchergar nada. Como resolver isso? Acessando a mesma URL porém autenticando-se como o Administrador local do servidor.

Pronto! Só atribuir permissão de Content Manager para o TFSSETUP (ou o usuário que está usando para criar o projeto, o seu “TFS Admin”) assim:

- Acesse http://[TFSSERVER]/Reports como orientado acima;

- Clique na aba “Propriedades”;

- Clique em “Atribuição de nova função”;

- Em “Nome do grupo ou usuário”, digite o usuário que necessita da permissão (no meu caso, [TFSSERVER]\TFSSETUP);

- Em “Função”, selecione “Content Manager” e em seguida clique em OK.

E pronto! Você conseguirá prosseguir com a criação do Team Project.

[]’s

Ricardo Serradas

Hoje instalando o TFS 2010 num ambiente single server me deparei com dois problemas que não estão previstos no TFSInstall.chm, que vem no DVD de instalação do TFS.

O primeiro erro foi que não há web.config em “C:\Program Files\Microsoft Team Foundation Server 10.0\Application Tier\Web Services”.

Solução: É preciso criar uma cópia do web.config.template já existente lá.

Segundo erro: Visualizado no wizard de configuração padrão do TFS. Veja:

Error [ Configuration Database ] TF255147: The following server that is running SQL Server is not listening on the expected TCP port: TFS01.

As portas necessárias já estavam liberadas, a instancia do SQL já estava rodando… O que fazer? Foi então quando me lembrei de dar uma olhada nas configurações do SQL 2008 (em Start > All Programs > Microsoft SQL Server 2008 > Configuration Tools > SQL Server Configuration Manager)  e lá vi que o protocolo TCP/IP não estava habilitado (e não vem habilitado por padrão numa instalação do SQL).

O que fiz então foi habilitar o protocolo, com um duplo clique em TCP/IP e na aba Protocol, mudar a propriedade Enabled para Yes.

Feito isso, voilá! O teste de configurações rodou 100%! Mas, há um porém… Se a instalação do TFS for interrompida por algum motivo (no nosso caso, pelo SQL não estar corretamente configurado) a instalação do Sharepoint Services será corrompida. Isso é um bug conhecido do Beta1 do TFS.

Por conta disso, mãos à obra! Desinstalar todo o TFS + WSS e começar denovo. Então, dessa vez, tudo correrá bem. 

Um abraço!

Ricardo Serradas

Já está disponível para download a versão Beta 1 do Visual Studio 2010.

Os itens disponíveis são:

• Team Suite
• Team Foundation Server
• VS Professional
• .Net Framework 4.0

Para acessar, clique aqui.

Bora testar agora!!!

[]’s

Ricardo Serradas