Ricardo Serradas

Olá,

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

Olá a todos! Hoje vamos falar de mais um capítulo da série “Problema e solução”.

Problema:

Ao configurar uma Team Build no VSTS de um projeto que compila e que roda os testes unitários tudo certinho, a build roda, porém o status dela fica como “Partially Succeeded” porque os testes unitários falharam e, ao analisar o log, você encontra a seguinte linha no final:

MSBUILD : warning MSB6006: “MSTest.exe” exited with code 1.

O mais interessante é que se você roda os testes unitários a partir do Test List da Solution, todos funcionam, não é?

Causa:

Pois bem. Por algum motivo, o erro se dá por conta do usuário TFSSERVICE* não ter permissão na pasta onde o resultado do build foi colocado (ou “dropado”).

Solução:

Basta permitir escrita (tanto NTFS quando de compartilhamento) para pra o usuário TFSSERVICE na pasta de build drop.

*Este nome pode variar de acordo com a instalação realizada.

[]‘s

Ricardo Serradas

Numa instancia recém instalada do TFS 2008, onde tudo parecia estar funcionando 100%, encontrei um problema o qual percebi ter pouca referência à respeito.

Criei uma solution de testes para armazenar no Source Control, adicionei projetos, tudo tranqüilo. Depois de tudo, parti para a configuração de um Team Build.

A solução compilava normalmente na máquina client, porém, depois que subi a solução no TFS o team build falhou. Veja a mensagem de erro:

Error MSB4019: The imported project [TargetPath] was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

O erro era vinculado sempre à Web Projects (Web Application, WebService, etc). Isso ocorre porque os targets para aplicações web não estão instaladas no servidor de build.

Existem duas formas de resolver o problema. Uma delas (e a que eu aconselho) é simplesmente instalar o Visual Studio 2008 com as mínimas opções (C# e Visual Web Developer) no servidor de build. O ponto negativo desta solução é que estará consumindo espaço em disco do servidor de build.

A outra opção, se não quiser instalar o VS 2008 no servidor é a seguinte:

- Acesse: MSBuild\Microsoft\VisualStudio\v9.0\WebApplications na máquina client;

- Copie Microsoft.WebApplication.targets para o diretório da solução do projeto;

- Adicione o arquivo como parte da solução e versione-o;

- Edite o arquivo TFSBuild.proj da sua WebApplication usando um editor de texto (normalmente em [TeamProject]/TeamBuildTypes/[SolutionName]Build);

- Encontre a linha que faz o import do WebApplication Target a partir da pasta do MSBuild no Program Files:

<Import Project=”$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets” />

E substitua por:

<Import Project=”$(SolutionDir)\Microsoft.WebApplication.targets” />

- Salve seu arquivo e suba a nova versão no TFS.

Esta solução nada mais faz do que disponibilizar o arquivo de target dentro da própria solution para que o MSBuild o busque lá dentro. O ponto negativo desta é que para cada solução que você for versionar que tiver um Web Project será necessário versionar uma cópia do arquivo de target no TFS.

Escolher a melhor opção para seu cenário é com você. Experimente!

Um abraço,
Ricardo Serradas