Depois dos últimos posts falando de Source Control, vamos falar um pouco sobre Build Definitions no TFS 2013 com uma particularidade bem especial: como organizar minha estrutura de Builds Definitions para um único Team Project.

Quem se lembra do ALM Summit 2013, o Vinicius Hana fez uma palestra sobre o modelo de implementação de um único Team Project: para maiores detalhes veja a palestra aqui.

Claro que não vou explicar novamente todo o conteúdo, mas focar em um “problema” que foi abordado durante a palestra: organizar a lista de Builds, respondendo as seguintes questões:

• Existe algum padrão que facilita essa organização?
• Existe ferramentas que ajudam a vida do administrador do TFS?

Exemplificando a estrutura de um único Team Project

Para a exemplificação da estrutura de Source Control de um único Team Project, usarei o exemplo de acordo com a figura abaixo, onde:

•  Modelo de branch utilizado – Feature Branch;
• Nível 1 – Sistema;
• Nível 2 – Aplicativo (Web Application, Windows Service, Web Service, etc.);
• Nível 3 – features branches (Novas Features e HotFix).

Por se tratar de um modelo de branches de um único nível de nó filho, todas as branches deverão ser capazes de executar um enfileiramento de Build. Nesse modelo portanto o número de Build Definitions será correspondente ao número de features branches criadas. Então ai que vem a primeira sugestão de organização.

Padronização de Nomenclatura das Build Definitions

Como sugestão de nomenclatura, utilizaremos a seguinte padronização:

SISTEMA.APLICATIVO.BRANCH, onde:

• Sistema – primeiro nível do Source Control;
• Aplicativo – segundo nível do Source Control;
• Branch – Novas features ou HotFix que represente o respectivo desenvolvimento.

Portanto poderemos ter uma estrutura de Build Definitions da seguinte forma:

Finalizada a padronização de nomenclatura, precisamos agora entender como o Team Explorer pode nos ajudar na organização da estrutura de Builds. Para isso faremos uso de dois plug-ins que baixei no Visual Studio Gallery.

TFS Productivity Pack

O primeiro plug-in que utilizaremos chama-se TFS Productivity Pack. Esse plug-in irá nos auxiliar a executar o “clone” de uma Build Definition existe, executando o remapeamento do “Source Settings” apontando para a nova branch criada.

Para o “clone” da Build Definition, o plug-in disponibiliza uma funcionalidade denominada “Branch Build Definition” como mostrado nas figura abaixo:

Basta apenas executar o remapamento do “Source Settings”

E em seguida, renomear a Build Definition com a padronização estabelecida acima:

Com a criação de novas features branches, rapidamente teremos uma estrutura de Build Definitions bem extensa e parecida com a figura abaixo:

Mas e agora? Existe alguma maneira de criar uma hierarquia e facilitar a localização da minha Build Defintion? Para resolver essa questão, nos utilizaremos de mais um plug-in

Team Explorer Builds Tree

O plug-in Team Explorer Builds Tree tem como característica organizar hierarquicamente a nossa estrutura de Builds Definitions a partir de uma padronização. Como já temos um critério de organização das nossas builds, o plug-in organiza nossa estrutura automaticamente, facilitando assim a localização. O único critério de configuração desse plug-ins deve-se ao caractere de “split” que iremos utilizar. No caso especifico da nomenclatura de Build apontada nesse exemplo, utilizamos o caractere “.”.

Feita a devida configuração, a estrutura de Build se desenha conforme mostrada na figura abaixo:

Esse plug-in nos permite o enfileiramento e edição de builds igualmente disponível na versão original do Team Explorer:

Espero que tenha ajudado vocês na organização desse “problema” e até o próximo post.

Muito obrigado,

Vinicius Moura.