TFS – Adicionando nova coluna de estado na board.

Adicionando nova coluna de estado na board.

Adicionar nova coluna de estado

No TFS existe como customizar o Workflow de um Work Item como podemos conferir neste artigo que escrevi.

Esse novo estado (foi criado um estado chamado “Testing” no artigo) pode ser atribuído aos Work Items que tiveram seu Workflow modificado, basta abrir o Work Item e selecionar no combo o novo estado.

Após essa implementação com certeza vai surgir outra necessidade, alterar o estado movendo o Work Item na board do TFS. E é isso que vamos aprender neste artigo.

Para isso é necessário editar o arquivo CommonConfiguration.xml do seu template e para acessá-lo basta exportar o arquivo através do comando witadmin

Para encontrar o diretório digite este caminho no Command Prompt:

cd %programfiles%Microsoft Visual Studio 11.0Common7IDE

Em uma edição de 64 bits do windows, substitua %programfiles% com %programfiles(x86)%.

Execute o comando:

witadmin exportcommonprocessconfig /collection:CollectionURL /p:ProjectName /f:"DirectoryPathCommonConfiguration.xml"

CollectionURL especifica a URL de seu Team Project Collection, ProjectName especifica o nome do Team Project, e DirectoryPath especifica o nome e local do arquivo a ser exportado.

Abra o arquivo no notepad e localize o seguinte trecho

  <RequirementWorkItems category="Microsoft.RequirementCategory" plural="Backlog items">
    <States>
      <State value="New" type="Proposed" />
      <State value="Approved" type="Proposed" />
      <State value="Committed" type="InProgress" />
      <State value="Done" type="Complete" />
    </States>
  </RequirementWorkItems>
  <TaskWorkItems category="Microsoft.TaskCategory">
    <States>
      <State value="To Do" type="Proposed" />
      <State value="In Progress" type="InProgress" />
      <State value="Done" type="Complete" />
    </States>
  </TaskWorkItems>

Repare que existem dois blocos, um para itens de Backlog e outro para Tasks, pois existem duas boards, uma de Backlog e outra de Tasks.

Escolha o bloco referente ao tipo de Work Item que foi editado e adicione uma nova linha, esta linha vai receber o valor do novo estado, porém o tipo nesse caso permanece “In Progress”, pois não trata-se do final de um ciclo.

No exemplo abaixo adicionei uma nova coluna para as duas boards.

  <RequirementWorkItems category="Microsoft.RequirementCategory" plural="Backlog items">
    <States>
      <State value="New" type="Proposed" />
      <State value="Approved" type="Proposed" />
      <State value="Committed" type="InProgress" />
      <State value="Testing" type="InProgress" />
      <State value="Done" type="Complete" />
    </States>
  </RequirementWorkItems>
  <TaskWorkItems category="Microsoft.TaskCategory">
    <States>
      <State value="To Do" type="Proposed" />
      <State value="In Progress" type="InProgress" />
      <State value="Testing" type="InProgress" />
      <State value="Done" type="Complete" />
    </States>
  </TaskWorkItems>

O arquivo já está modificado e pronto para ser importado. Utilize o comando de importação com os mesmos parâmetros utilizados para sua exportação:

witadmin importcommonprocessconfig /collection:CollectionURL /p:ProjectName /f:"DirectoryPathCommonConfiguration.xml"

Pressione F5 na board modificada para conferir a inclusão da nova coluna.

Atenção: O valor “nome” da coluna adicionada deve ser exatamente o mesmo do estado criado no Workflow. Para arrastar um Work Item para a nova coluna lembre-se que é necessário existir no Workflow uma transição de estados entre o estado atual e o novo.

Feedback, sugestões, dúvidas utilize o campo de comentário logo abaixo 🙂

Referências

TFS – Customizando o Workflow de um Work Item

No TFS existe a opção de escolher qual o process template da metodologia que o projeto será gerenciado, atualmente existem os process templates para Scrum, MSF for CMMI e MSF for Agile. Os process templates fornecem ao projeto suporte as terminologias e definem vários elementos que determinada metodologia aborda.

É muito comum após um process template configurado surgir a necessidade de alguma modificação / adaptação, pois o processo da equipe pode ter alguma particularidade.

Nesse artigo usaremos o process template de Scrum para o exemplo. No Scrum existe o Conceito de Pronto que significa que um time Scrum define quais critérios são necessários para dar como pronta uma atividade. Com certeza para uma atividade ser considerada pronta é necessário que ela esteja testada. O workflow de uma atividade no process template Scrum vai de In Progress para Done, não existe o estado Testing.

Nesse artigo abordaremos como alterar o workflow de uma tarefa e incluir o estado Testing.

Esse artigo aborda o uso de:

Utilizando o TFS Power Tools para editar um Work Item

Após instalar o TFS Power Tools surgirá uma opção do menu Tools do Visual Studio chamado Process Editor

O Process Editor permite que seja editado um Work Item seja ele global ou de algum projeto específico.

No exemplo será editado o Work Item de Task onde será adicionado um novo campo de valor e também modificaremos o seu workflow para prever o novo estado de Testing.

O caminho a seguir é Work Item Types > Open WIT from Server

Surgirá uma janela de diálogo com os projetos disponíveis no TFS, será necessário expandir o projeto em questão e selecionar o tipo de Work Item a ser editado, selecione Task.

Modificando o Workflow de um Work Item no TFS

Na mesma tela Work Item Type clique na aba chamada Workflow

Abaixo está a ilustração do Workflow original para o Work Item de Task no Process Template Scrum 2.2:

A alteração que será executada será adicionar o novo estado Testing e alterar o fluxo de dos estados existentes, para isso serão necessária as ferramentas de design que estão disponíveis em Toolbox

Criando um Estado no Workflow

Arrastando um item da caixa State para o Workflow

Este é a caixa do novo estado, já foi renomeado para Testing e agora é necessário criar as transições, que são responsáveis por guiar o fluxo.

Para criar uma transição basta selecionar o item Transition Link na Toolbox clicar na caixa que a transição inicia e arrastar e soltar na caixa onde termina.

A transição de estado está feita, isso significa que quanto a tarefa estiver em estado Testing, será possível mudar para Done, agora é necessário realizar algumas configurações.

Com um duplo clique na caixa Transition abrirá uma janela de diálogo Workflow Transition.

Na aba Reasons cadastraremos um novo valor para quando o estado de Testing passar para Done.

Clicando em New para preencher o valor do Reason, que é a razão pelo qual a tarefa mudou de estado.

Note que no fluxo principal, a caixa Done requer a adição de um parâmetro o Closed Date, isso significa que é necessário passar essa informação para que haja transição de Testing para Done, a passagem desse valor é feita durante a transição através do item recurso Fields.

Pressione OK e retorne a janela de diálogo Workflow Transition, selecione a aba Fields e clique em New, o combo abaixo irá exibir diversas opções selecione ClosedDate.

Além de selecionar a referência do campo a ser passado é necessário configurar a regra de passagem, clique na aba Rules e selecione New, uma janela com uma lista exibirá todas as regras existentes, nesse caso a regra SERVERDEFAULT deve ser escolhida, pois trabalharemos com uma informação do servidor.

Como estamos trabalhando com um valor do tipo DateTime selecione no combo From a opção Clock, significa que iremos utilizar a data que está no servidor como referência.

Etapa concluída, o novo estado Testing está configurado e a transição para Done foi finalizada.

Note que exitem outras transições a serem feitas como por ex:

  • In Progress > Testing (Atividade finalizada e encaminhada para testes)
  • Testing > In Progress (Bugs encontrados, necessário trabalho adicional)

Basta seguir o mesmo processo para as demais transições.
Salve as alterações pelo Visual Studio e automaticamente o novo estado Testing estará publicado.

No próximo artigo gravarei um vídeo executando este processo e fornecendo mais detalhes de como modelar o Workflow de um Work Item.

Utilizem os comentários para dúvidas ou feedbacks.
Até a próxima 😉

TFS – Aumentando o número de itens na board

Em muitos projetos o número de itens em uma board ultrapassa a média qual o TFS vem configurado por padrão e quando isso acontece ao acessar a board é exibida a mensagem:

“You have exceeded the number of items allowed on your taskboard.”

Não precisa se preocupar, o TFS limita a board em 500 items por medida de performance, pois todos os items são carregados em cache de forma que sua exibição se torne muito rápida.

Para resolver é necessário editar o arquivo AgileConfiguration.xml do seu template e para acessá-lo basta exportar o arquivo através do comando witadmin

Para encontrar o diretório digite este caminho no Command Prompt:

cd %programfiles%Microsoft Visual Studio 11.0Common7IDE

Em uma edição de 64 bits do windows, substitua %programfiles% com %programfiles(x86)%.

Execute o comando:

witadmin exportagileprocessconfig /collection:CollectionURL /p:ProjectName /f:"DirectoryPathAgileConfiguration.xml"

CollectionURL especifica a URL de seu Team Project Collection, ProjectName especifica o nome do Team Project, e DirectoryPath especifica o nome e local do arquivo a ser exportado.

Abra o arquivo de AgileConfiguration.xml no notepad e localize a seção IterationBacklog, Especifique um valor para o atributo workItemCountLimit (Ex. 800).

<IterationBacklog workItemCountLimit="800">
. . .
  </IterationBacklog>

Isso significa que ao invés de 500 a board passará a exibir 800 itens.

Depois de salvar o arquivo basta importá-lo usando o mesmo comando:

witadmin importagileprocessconfig /collection:CollectionURL /p:ProjectName /f:"DirectoryPathAgileConfiguration.xml"

É a mesma sintaxe, com a diferença que agora trata-se de uma importação.
Atualize a board com F5 e as alterações irão refletir, exibindo novamente os itens com o novo limite de 800.

*PS – Aumentar demasiadamente o número de itens na board pode prejudicar a performance.

Bons projetos a todos 😉

 

TFS – Team Foundation Service

TFS – Team Foundation Service, é a conhecida plataforma de gerenciamento de código fonte e colaboração da Microsoft que foi parar na nuvem.

Team Foundation Service

Quando pensamos em TFS geralmente nos vem o nome Team Foundation Server, afinal trata-se de uma plataforma local, interna e instalada em um servidor.

A Microsoft há algum tempo disponibilizou esta mesma ferramenta só que hospedada na nuvem, ou seja, nos servidores do Windows Azure.

O famoso TFS passou a ser disponibilizado como serviço, notem que está cada vez mais comum encontrar os “SaaS” Software as a Service, diversos produtos da Microsoft já foram para nuvem (ex Office 365).

Minha experiência:

Tanto em casa como no trabalho eu sou usuário do TFS, no trabalho usamos a versão internalizada, ou seja instalada, e em casa antigamente eu tinha uma virtual machine rodando um windows 2008 server apenas para suportar o TFS.

Com o lançamento do TFS 2012 veio a versão TFS Express, gratuita para 5 usuários (porém com algumas limitações), que roda inclusive em windows 8.

Não cheguei a fazer uso do TFS Express, migrei diretamente para o TFS (Service) também conhecido como TFS Preview e o melhor, é de graça para 5 usuários também.

Estou plenamente satisfeito com minha escolha, não precisei instalar nada, apenas com a conta da Microsoft (antigo Live ID) fiz o login no site https://tfs.visualstudio.com/ e criei minha conta no TFS.

Todos os serviços estão disponíveis sem limitações, mesmo para as contas gratuitas, algumas funcionalidades podem se tornarem pagas daqui algum tempo, mas por enquanto a experiência é completa, vale a pena a imersão 🙂

A intenção deste post foi apresentar o serviço do TFS e comentar sobre minha experiência.
Em continuação deste farei um post técnico onde irei explicar passo-a-passo todo processo de utilização, aguardem 🙂

Até mais e abraços!

Undo Checkout no TFS

Undo Checkout no TFS é um processo comum, mas e quando o arquivo está preso a outra pessoa? Nesse caso existem ferramentas de apoio para resolver, mas se você não tem nenhuma a solução é mais uma vez a linha de comando.

O comando é o tf undo (tf.exe) e para executá-lo você precisa do Visual Studio instalado

Para encontrar o diretório digite este caminho no Command Prompt:

cd %programfiles%Microsoft Visual Studio 11.0Common7IDE

Em uma edição de 64 bits do windows, substitua %programfiles% com %programfiles(x86)%.

*Atente-se ao diretório devido a qual versão do Visual Studio está usando.*

O comando deve ser chamado da seguinte forma:

tf undo [/workspace:workspacename[;workspaceowner]]
[/recursive] itemspec [/noprompt] [/login:username,[password]]
[/collection:TeamProjectCollectionUrl]

Naturalmente o usuário deverá ter permissão de Administer Workspaces para realizar esta operação.

/collection : TeamProjectCollectionUrl
Especifica a URL da coleção de projeto de equipe que contém os itens. Por exemplo: http://myserver:8080/tfs/DefaultCollection.

itemspec
Especifica o escopo de itens. Você pode especificar mais de um argumento de itemspec Para a sintaxe, consulte Referência de comandos de controle de versão do Team Foundation.

/login
Especifica a conta de usuário para usar o para executar o comando. Consulte Referência de comandos de controle de versão do Team Foundation.

/noprompt
Suprime a exibição das janelas e caixas de diálogo e redireciona dados de saída para o prompt de comando. Consulte Referência de comandos de controle de versão do Team Foundation.

/recursive
Desfaz recursivamente alterações dos itens no diretório especificado e todas as subpastas.

/workspace workspacename[;workspaceowner]
Especifica o nome do espaço de trabalho que você deseja desfazer alterações pendentes. Se não for especificado, o espaço de trabalho é aquele que mapeia o diretório atual.

Exemplos:

Remover as alterações pendentes em um arquivo
– Remove todas as alterações pendentes em program.cs

c:codeSiteAppMainSolutionAProject1>tf undo program.cs

Remova recursivamente durante alterações em todos os itens em uma pasta
– Remove todas as alterações pendentes na pasta c:codeSiteAppMain e todas suas subpastas.

c:codeSiteAppMain>tf undo * /recursive

Remover as alterações pendentes em um arquivo em um espaço de trabalho remota
– Remove todas as alterações pendentes em program.cs na coleção e o espaço de trabalho especificados.

c:>tf undo /collection:http://fabrikam-3:8080/tfs/DefaultCollection
/workspace:FABRIKAM-1;JuliaI $/SiteApp/Main/SolutionA/Project1/program.cs

Até a próxima dica 😉

Deletar Work Item no TFS

Deletar Work Item no TFS é sempre uma dúvida que surge ao implantar a ferramenta, pois sempre abrimos alguns para testar e depois não precisamos mais.

Não tem interface visual que faça a deleção do Work Item, mas existe a linha de comando, grande aliada para resolver N situações.

O comando é o witadmin e para executá-lo você precisa do Visual Studio ou Team Explorer instalado

Para encontrar o diretório digite este caminho no Command Prompt:

cd %programfiles%Microsoft Visual Studio 11.0

Em uma edição de 64 bits do windows, substitua %programfiles% com %programfiles(x86)%.

Para ter permissão de remoção do Work Item você precisa ser Administrador do TFS ou do projeto em questão.

Execute o comando:

witadmin destroywi /collection:CollectionURL /id:id [/noprompt]

/collection:CollectionURL
Especifica a URL a coleção de projeto de equipe. o formato para o URI é o seguinte: http:ServerName: porta/VirtualDirectoryName/CollectionName/

Se nenhum diretório virtual é usado, o formato para o URI é o seguinte:
http: /ServerName: porta/CollectionName.

/id:id
A identificação de um item de trabalho a destrui-lo. Para especificar mais itens de trabalho, IDs separadas por vírgulas, sem somente espaço em branco.

/noprompt
Desativa o aviso para a confirmação.

/?ou help
Exibe ajuda sobre o comando na janela do prompt de comando.

Exemplo:

witadmin destroywi /collection:"http://dev-win-01:8080/tfs/Em Andamento/" /id:25

Até a próxima dica 😉