No post anterior, falamos de uma customização de work items usando os recursos do próprio Visual Studio somados aos do Team Foundation Server Power Tools. O que faremos seguindo esse guia é ir além, codificando nosso próprio controle para um formulário de work item.

Vamos relembrar o problema que vamos resolver: precisamos de um campo que vai exibir o andamento geral da atividade, baseado no andamento das 3 etapas, consolidando-as. Para mais detalhes, você pode ler mais sobre o problema proposto na Parte 1.

Para acompanhar, todo o código conte e XML de definição do Work Item “Task” está disponível para download neste link.

Como funciona o deploy de novos controles para Work Items?

Diferentemente do que muitos me supõe, os assemblies de controles customizados para work items não ficam dispostos no servidor do TFS, mas sim em uma pasta específica em cada máquina cliente. Essa pasta é:

[Drive]:\programdata\Microsoft\Team Foundation\Work Item Tracking\Custom Controls\10.0

Por conta disso, precisamos escolher uma forma para distribuir nosso assembly do controle. Isso fica a seu critério. Você pode disponibilizá-la para cópia num compartilhamento na rede, distribuir via pendrive, SkyDrive, etc… Eu escolhi criar um setup que já faz a cópia da DLL para o diretório correto, e aí sim compartilhei este na rede, porém, não vamos entrar nesse mérito.

Vale lembrar que depois do deploy da DLL feito nessa pasta, é necessário reiniciar o Visual Studio para que ele faça sua leitura.

Vamos ao que interessa

Para criarmos nosso controle, criamos um Class Library simples dentro do nosso Visual Studio. Vamos chamá-lo de CustomWorkItemFields. Chamei assim porque, dentro desse mesmo assembly, podemos criar outros novos controles.

Dentro dele, adicionamos um User Control, que vou chamar de “PercentComplete”. Adicionamos então um TextBox simples, o qual vamos chamar de “txtValue”. O último passo dessa parte visual é ajustar o form para que ele fique do mesmo tamanho que nosso TextBox, assim:

Agora, precisamos implementar a inteligência desse controle. Para isso, vamos ao código.

Antes de tudo, precisamos adicionar duas referências ao nosso projeto, que são:

• Microsoft.TeamFoundation.WorkItemTracking.Client, parte do Team Foundation Server SDK
• Microsoft.TeamFoundation.WorkItemTracking.Controls, localizado no diretório:

[Drive]:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies

Feito isso:

-          Faça as referências a esses namespaces no codebehind do controle;

-          Implemente a interface IWorkItemControl;

-          (Opcional, como implementei) crie um struct para organizar os nomes dos campos de work items com os quais vamos trabalhar os cálculos;

-          Crie o método SetPercenteCompleteField() para concentrar a inteligência de cálculo.

O segredo todo desta customização está no evento FieldChanged do WorkItem, porque a cada vez que um campo for modificado e este for um dos 3 novos campos que adicionamos ao formulário, temos que realizar o cálculo e exibir o resultado no nosso controle customizado. Veja como ficou o núcleo da nossa customização, o método “SetPercentCompleteField”:

private void SetPercentCompleteField()
{

try

{

// Obtém todos os valores que estão informados nos nossos campos de acompanhamento

var analysis = int.Parse(_workItemDataSource.Fields[WorkItemFields.Analysis].Value.ToString().Replace("%", string.Empty));

var development = int.Parse(_workItemDataSource.Fields[WorkItemFields.Development].Value.ToString().Replace("%", string.Empty));

var tests = int.Parse(_workItemDataSource.Fields[WorkItemFields.Tests].Value.ToString().Replace("%", string.Empty));

// Aplica os pesos a cada um dos valores e depois obtém porcentagem

var result = analysis*40;

result += development*30;

result += tests*30;

result = result/100;

// Atribui o resultado ao nosso campo de work item para armazenamento na base de dados

_workItemDataSource.Fields[WorkItemFields.PercentComplete].Value = result;

// Atribui esse resultado, formatado com o caractér '%', no campo do controle

txtValue.Text = result + "%";

}

catch (Exception)

{

if (_workItemDataSource == null) return;

_workItemDataSource.Fields[WorkItemFields.PercentComplete].Value = 0;

txtValue.Text = "0%";

}
}

Depois do controle codificado, precisamos agora criar um arquivo de definição do controle de work item, que será colocado na mesma pasta de deploy que informei acima. Veja o seu formato:

<?xml version="1.0"?>
<CustomControl xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Assembly>ALMTeam.BlogSampleCMMi.CustomWorkItemFields.dll</Assembly>
<FullClassName>ALMTeam.BlogSampleCMMi.CustomWorkItemFields.PercentComplete</FullClassName>
</CustomControl>

Formato simples, não? Dentro da tag “Assembly”, informamos qual o nome da DLL onde está localizado nosso controle e, em “FullClassName” o nome completo, incluindo namespace, da classe que o define.

Por último, abrimos o Work Item Type “Task” e criamos o campo BlogSampleCMMi.Tracking.PercentComplete (Integer) para armazenar os dados que nosso controle vai exibir.

Feito isso, fazemos o deploy dos dois arquivos na nossa referida pasta e depois reiniciamos o Visual Studio. A partir de então, um novo tipo de controle ficará disponível para inserirmos no layout do work item. É com ele que vamos criar o campo percent complete no formulário, assim como criamos os outros 3 campos, com a seguinte diferença:

Veja que em “Type”, temos nosso tipo de controle customizado disponível. Não podemos nos esquecer, porém, que devemos também referenciar nosso campo de work item (criado na aba “Fields”) na propriedade “Field Name”.

Depois de criado o controle, salve o seu work item type e veja o resultado criando um novo work item do tipo “Task”:

Perceba que cada vez que um desses 3 campos tem seu valor alterado, o cálculo no campo “Andamento Geral” acontece automaticamente.

Importante: a implementação de um controle customizado para formulários de work items na web (Team Foundation Web Access) é diferente. Logo, verá que esse controle não é visível nos formulários web. Este assunto será abordado num outro post.

É isso galera! No próximo episódio dessa “saga”, veremos como integrar tudo isso à um cronograma do Project.

[]’s

Ricardo Serradas

Há alguns dias atrás passei por uma série de situações curiosas, com algumas diferentes customizações de um template de processo MSF for CMMi 5.0 do TFS para um time de desenvolvimento, situações essas que são relativamente simples, mas achei que caberiam bem em alguns posts sobre como realizar cada etapa. Minha proposta então é expor o problema e depois, numa série de posts, mostrar como é possível implementar tudo isso. Vamos lá.

- Há a necessidade de customizar o template do work item do tipo Task, com 3 campos que compunham o andamento de cada etapa da atividade. Algo parecido com o seguinte:

 Então, os campos “Original estimate”, “Remaining work” e “Completed work” seriam inutilizados a pedido da própria gestão.

- O próximo passo é criar um campo abaixo que mostrasse o andamento geral da atividade, uma porcentagem consolidada, levando em consideração os pesos de cada etapa. Exemplo, se:

 Logo, o andamento geral da atividade é 55%, porque ((100*40)+(50*30)+(0*30))/100 = 55, certo?

Porém, como fazer isso apenas com as regras de campos de work items do TFS? Bingo! Não é possível. Para conseguirmos isso, precisamos criar um controle customizado para nossos work items com essa inteligência embutida.

- Depois disso, sabemos que esses work items serão mapeados para um cronograma no MS Project. A necessidade do gestor é que esse campo com o andamento geral da atividade fosse refletido no campo “% Complete” do cronograma.

- Por fim, é interessante conseguirmos elaborar relatórios a partir desses novos dados. Vamos então criar um novo tipo de Report e publicá-lo na área de relatórios do Team Project.

Vamos resolver esses “puzzles”?

Parte 1: Criar campos customizados para o formulário de work item

Antes de tudo, precisamos ter um um Team Project configurado com MSF for CMMi 5.0 para podermos trabalhar. Recomendo fortemente que crie um Team Project exclusivo para exercícios como esse.

Existem duas formas para customizar um tipo de work item: editando suas definições via XML ou usando o Process Editor integrado no Visual Studio, módulo contido no Team Foundation Power Tools, que pode ser obtido neste link. Mesmo que queira mexer direto no XML, é muito importante baixar e instalar essa ferramenta para que possa ter fácil acesso ao XML definition do work item.

Depois de instalado, vamos primeiro dar uma olhada no XML definition do Work Item do tipo Task. Para isso, dentro do Visual Studio, siga os passos:

Menu Tools -> Process Editor -> Work Item Types -> Export WIT.

Uma janela como essa sera aberta:

Selecione o tipo “Task” do seu Team Project e clique em OK. Agora, você verá uma caixa de diálogo de “Salvar como”, pedindo para escolher o local para salvar o arquivo XML.

Depois de salvo, abra este arquivo com seu editor de textos preferido. Verás um arquivo de cerca de 550 linhas. Vamos falar rapidamente sobre algumas tags importantes desse arquivo:

WORKITEMTYPE – Raiz do tipo do work item. É onde, por exemplo, o nome do tipo do work item é definido.

FIELDS – Aqui são definidos os campos usados no formulário do work item. Aqui algumas propriedades são definidas, como nome do campo, tipo de dado e formato no relatório.

WORKFLOW – Neste trecho é definido o ciclo de vida do tipo de work item. Transições entre estados, campos a serem preenchidos nelas, entre outras coisas são definidos aqui.

FORM – Aqui é definida a aparência do formulário do work item. Posições de campos, tamanho, label, agrupamento, etc.

Mas, há uma frase que acho muito valiosa que Ramon Durães costuma usar, que é “Não tem que ser difícil”. Seguindo essa linha, nós vamos basear nosso trabalho em cima do Process Editor do TF Power Tools.

Vamos então abrir o mesmo arquivo XML numa interface amigável dentro do Visual Studio. Para isso, siga esse caminho: Menu Tools -> Process Editor -> Work Item Types -> Open Work Items From File. Uma janela de abertura de arquivo vai aparecer, selecione o arquivo XML que visualizávamos no editor de texto. Verás então uma janela como essa:

As abas representam os nós daquele XML que falamos acima. Para executarmos a nossa primeira tarefa, precisamos seguir o seguinte roteiro nessa janela:

- Etapa 1: Criar a definição dos campos na aba “Fields” (seus nomes, tipos e descrição).

                Usando o botão “New”, a seguinte janela aparecerá:

Entendendo esse formulário:

Aba “Field Definition”

Name – Simplesmente o nome do campo, não interfere no funcionamento.

Type – Como o nome já diz, o tipo de dado que o campo vai suportar.

Reference Name – É através desse nome que ele será usado tanto no formulário quanto nos relatórios. Tem como padrão ter um nome semelhante ao namespace+nome de uma classe. No nosso exemplo usamos “BlogSamplesCMMi.Tracking.Analisys”.

Help Text – Texto que serve para tooltips, descriptions, etc.

Reportable – Se você pretende usar a informação desse campo em relatórios, é importante escolher um dos valores para esse campo. Os valores podem ser:

                None: Não será inserido no banco de dados relacional (não poderá ser usado em relatórios);

                Dimension: Use este tipo apenas para Integer, Double, String ou DateTime. Os dados nesse campo entram no banco de dados relacional e no cubo como um atributo de dimensão do Work Item para que os dados sejam usados para filtrar relatórios. Use-o para campos que têm uma lista de valores válidos. Work Item Type e State são bons exemplos de uso desta opção.

                Detail: Use esse tipo somente para Integer, Double, String ou DateTime. Os dados nesse campo entram no banco de dados relacional nas tabelas “Work Item History” e “Current Work Item”, mas não no cubo. Esta é uma boa escolha para campos de texto sem restrição, no entanto, você terá que usar a base relacional em vez do cubo. “Summary”, um campo String que contém uma breve descrição de um work item, é um bom exemplo de campo que deve ser do tipo Detail quando usado em relatórios.

                Measure: Use este tipo somente para campos Integer ou Double. São usados para propósitos estatísticos ou para medir certos aspectos do projeto. Cada campo desse tipo aparecer tanto no grupo de medidas “Current Work Item” quanto “Work Item History”. “Estimated Work” é um bom exemplo de campo do tipo Measure.

                Apesar do campo “Formula” existir nesse form com diversas opções, os campos desse tipo são sempre agregadas como Soma (Sum).

Vamos repetir o uso desse formulário para nossos 3 campos, que nomearei assim:

• BlogSampleCMMi.Tracking.Analysis
• BlogSampleCMMi.Tracking.Development
• BlogSampleCMMi.Tracking.Tests

Aba “Rules”

Nessa aba são definidas algumas propriedades do seu campo, como valor padrão, valores permitidos, validações. O que vamos configurar em todos esses campos são as seguintes regras:

REQUIRED – O campo não poderá ficar em branco;

ALLOWEDVALUES – Deixaremos esses campos serem preenchidos somente com os valores “0%”, “50%” e “100%”.

DEFAULT – Em um novo Work Item, é o valor inicial do campo. Vamos configurá-lo da seguinte forma:

                From: value

                Value: 0%

- Etapa 2: Inserí-los no formulário do work item, através da aba “Layout”.

Essa etapa, apesar de ter uma interface amigável, não é tão intuitiva quanto arrastar controles para um Windows Form, mas claro, é muito melhor do que fazer isso direto no XML. J

Para usarmos nosso campo, primeiro precisamos escolher onde vamos colocá-lo no nosso formulário. Eu escolhi criar uma nova aba, chamando-a de “Etapas” e lá eu coloco somente os meus campos, para não poluir outras áreas do formulário. Veja a tela de layout do Work Item Type:

Na árvore à esquerda, os elementos do formulário são organizados numa estrutura de árvore e, à direita, as propriedades do elemento selecionado.

Nessa árvore, existem alguns tipos de elemento. Vamos entendê-los já praticando.

Dentro do TabGroup, criaremos um novo elemento do tipo “TabPage”. Para isso, botão direito em cima do item TabGroup -> New Tab Page. Um novo item na árvore aparecerá. Do lado direito, uma das propriedades chama-se “Name”. Altere-a para “Etapas”.

Para que os controles não fiquem espalhados dentro da aba, criamos um elemento do tipo “Group” para inserir os controles dentro. Insira então um “Group” ao TabPage usando o menu de contexto já usado acima. Quando um Group é criado, um item do tipo Column é criado dentro dele automaticamente.

Agora já podemos inserir nossos controles dentro da aba. Para isso, use o “New Control” dentro do menu de contexto em cima do item “Column”. Um novo item aparecerá como filho da Column. Ao lado direito, algumas propriedades chave do controle precisam ser modificadas. Vamos à elas:

FieldName: É aqui que você deve encontrar a Reference Name do campo que quer inserir. Neste primeiro caso, procuramos por “BlogSampleCMMi.Tracking.Analysis”.

Label: O label para o campo no formulário. Vamos usar “Análise e documentação (peso: 40%):”

Fazemos isso para os nossos 3 campos. Você pode visualizar préviamente como está ficando seu formulário, através do botão “Preview Form”, mas já adianto que não funciona muito bem. Por algum motivo, o que ele mostra não é exatamente como vai ficar seu formulário. L

Depois de pronto, salvamos o arquivo. Precisamos agora importá-lo devolta para o TFS. Para isso, vá ao menu Tools -> Process Editor – > Work Item Types -> Import WIT. Em “File”, localize o arquivo que você editou e em “Project to Import to” selecione o Team Project para o qual a customização se aplicará. Clique então em OK. Aguarde até que a importação seja concluída.

É importante agora dar um refresh no seu Team Explorer para que os templates sejam recarregados. Após isso, abra o formulário de criação de nova task e já verá a nova aba e os campos dentro dela, assim:

Primeira etapa completa! Logo mais, o segundo post falando sobre a criação de controle customizado.

[]’s

Ricardo Serradas

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

“Eu fiz o shelve lá conforme você recomendou só que agora não sei como recuperar as modificações do servidor! E agora, já era? As perdi? Como faz?”

Muita calma nessa hora. A solução é bem simples, porém, o problema é compreensível. O botão “Unshelve” está em localizações pouco intuitivas na IDE do Visual Studio 2008. Vamos à elas:

1 – Em “Pending Changes”: De um certo modo, concordo que umchangeset é composto de modificações pendentes de check-in, mas não são todos que pensam da mesma forma. Para grande maioria, “Pending Changes” são check-outs locais pendentes de commit paraversionamento. Concordo, afinal Shelveset é um conjunto de modificações armazenadas no Servidor, mas ainda não versionadas.

Mas voltando ao que interessa, o “Unshelve” está aqui: View -> Other Windows -> Pending Changes.

2 – Ao clicar com o botão direito em qualquer item no solution explorer. Sim, ali mesmo. Mas desde que você tenha algum projeto aberto. Não vale aquela “Solution1″ 

Ah, aproveitando! Galera, vamos dar mais atenção à essa feature do VSTS. Esse tal de Shelve pode ser muito últil para você!

Um abraço,

Ricardo Serradas

Como vinha tendo problemas com o modo que o VSTS faz o compare, fui atrás de modificar a ferramenta que ele usa para esta ação. Para fazer isso, basta seguir os passos abaixo:

- No VSTS, clique em Tools > Options > Source Control > Visual Studio Team Foundation Server
- À direita, clique em “Configure User Tools…”
- Na nova janela, clique em “Add…”
- Em extensions, insira as extensões de arquivo as quais você quer usar a ferramenta para fazer compare;
- Em “Operation” deixe “Compare”;
- Em “Command”, localize o executável da ferramenta (no meu caso, “C:\Program Files\WinMerge\WinMergeU.exe”);
- Em “Arguments” configure conforme sua ferramenta de merge recebe os parâmetros;

Não aconselho fazer o mesmo para a ferramenta de merge essa sim eu acho que está legal 

[]’s

Ricardo Serradas

Para conseguir fazer isso através da IDE, seria necessário ir nas propriedades do arquivo, na aba Branches e consultar qual (ou quais) é o seu branch pai ao qual ele pertence, localizar este arquivo neste branch e visualizar o arquivo… Trabalhoso, não?

Pois é… E por isso existe no CodePlex um projeto chamado TFS Follow Branch History, que permite fazer isso tudo com apenas um clique, ou dois, se considerarmos o clique do botão direito no arquivo 

Ele funciona como um Add-in para o VS 2008 e, depois de instalado, disponibiliza mais um botão no menu exibido ao clicar com o botão direito em qualquer arquivo no Source Control Explorer, assim:

Acesse a página do projeto clicando aqui.

Vale lembrar que o TFS Power Tools também disponibiliza uma opção a mais para a visualização do histórico via linhas de comandos, que é “/followbranches”.

Abraços

Ricardo Serradas

Nesta semana, conseguimos efetuar a migração dos fontes armazenados no SourceSafe e SVN para o TFS aqui na empresa.

De um modo, a migração foi muito tranquila. A única perda foi a do histórico do SVN, pois ainda não há nenhuma ferramenta que faça essa migração anexando o histórico, diferente do que faz o VSSConverter.

O que tem sido um problema nos últimos dias é o gerenciamento dos workspaces por parte dos desenvolvedores, principalmente dos que trabalhavam com o SVN, que era integrado ao Windows Explorer. O que tem acontecido é que uma única pasta no source control é mapeada para diversas no disco da máquina.

O TFS permite que seja criado um template de workspace para a equipe, mas não oferece opção para evitar que os Colaboradores façam novos mapeamentos. É possível apenas evitar que novos workspaces sejam criados.

Para contornar isso então, precisava encontrar uma maneira de visualizar todos os workspaces de todos os usuários e orientá-los melhor a respeito desta feature. Mas como fazer isso?

Foi quando encontrei o Team Foundation Sidekicks. Com ele, além de executar esta ação, também é possível:

• Checar status de arquivos;
• Visualizar históricos, shelvesets e labels com dados mais detalhados;
• Gerenciar permissões;
• UI para melhorar auxiliar no processo de code review.

Eu achei a ferramenta muito bacana. Ainda estou a explorando e com certeza devo encontrar mais surpresas. Para quem quiser conhecer, segue o link abaixo. É 100% free:

Attrice TFS Sideckick

Abraços

Ricardo Serradas

Para quem se preocupa com Database Projects no momento de um build ou deploy. Aquela preocupação que diz respeito à “vou ter que reconstruir meu banco para gerar o novo build?” ou “vou perder todos os dados da tabela X para poder adicionar uma nova coluna a ela?”…

O VSTS Database Edition (Codename “Data Dude”) tem total integração com o MSBuild. Ou seja, todo o esquema de build e deploy podem ser também utilizados para sua camada de dados do projeto.

As alterações no projeto de banco, sejam de adição de novas entidades ou alteração de alguma já existente, são adicionadas a um arquivo .sql. Este arquivo pode ou não ser integrado ao seu processo de build diretamente, dependendo do seu processo (validação de algum DBA, etc).

Lembrando que no processo de build, tanto podem ser usadas somente as alterações realizadas quanto o script inteiro do banco de dados.

Em um deploy Full (usado para entrega ao cliente, geração de versão), todo o banco de dados é criado no server de destino. É este o processo padrão quando, no destino, o banco não existe. Porém, isso pode ser forçado no build usando a opção “Always Recreate Database”.

Já num deploy incremental (útil para gerar builds para testes), somente os scripts de alterações realizadas são rodados no banco de dados.

Ainda podem ser utilizados scripts incrementais que validem versão do servidor no destino, nome do banco de dados e nível de compatibilidade. Caso alguma dessas validações falhe, o processo de build/deploy pode ser abortado.

Abraço,

Ricardo Serradas