Como usar o Proxy do TFS no Team Build

Oi pessoal,

Esta é mais uma dica rápida que pode ajudar quem faz a compilação de grandes projetos usando o Team Build. A situação complica ainda mais quando o servidor de build e de TFS estão em redes diferentes, pois o download da grande quantidade de fontes passa por uma conexão habitualmente pior do que a de uma rede local.

O que o Team Foundation Server Proxy faz é basicamente cache dos fontes para otimizar futuros downloads. Como o foco desta publicação é, de fato, habilitar o uso do Proxy pelo servidor de Build, você pode obter mais informações sobre o TFS Proxy, por enquanto, nas referências abaixo:

E indo direto ao assunto, para habilitar isto, é necessário modificar o Registro do Windows. Por isto, muito cuidado! Faça isso somente acompanhado dos pais ou responsáveis, ok? :-)

Primeiro passo: Configurar o TFS Proxy Client no Build Server

Eventualmente, o Build Server não será o mesmo servidor para Proxy. Entretanto, para que o Build use o Proxy previamente configurado, é necessário “configurar” um proxy também no Build Server para que possamos trabalhar os próximos passos. Para isto:

No Team Foundation Server Administration Console, acesse Proxy Server e clique em Configure Installed Features para iniciar a configuração:

Siga o Wizard, que é bem trivial, para ter o client de proxy no server de Build:

Atente que as informações a serem configuradas são:

  • Conta de serviço;
  • Porta onde o serviço ficará escutando, que por padrão é a 8081;
  • Pasta onde o cache será armazenado. Aqui, é recomendado informar uma pasta que está em um disco com ao menos 50GB livres;
  • Coleção a qual o proxy servirá. Bem como o servidor de Build, um Proxy pode atender somente uma coleção.

Segundo passo: Configurar o Build para usar o Proxy Server

Nesta etapa, vamos configurar o Build Server para usar o servidor de proxy do seu TFS. Assumindo que você, Administrador de TFS que está executando esta operação, já é íntimo dos Registros do Windows, no Regedit, encontre seguinte chave:

    HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl\Proxy

Aqui, vamos alterar a entrada Enabled para True e em Url, vamos informar o endereço do nosso servidor de Proxy. Vai ficar assim:

Recomendo reiniciar os serviços de build para que as alterações de registro tenham efeito. A partir de então, o build server vai usar este Proxy para fazer download dos fontes.

Um abraço!

[QuickTip] Como obter o objeto de Workspace nos templates de build novos

Oi pessoal.

Esta dica rápida (mas nem tanto) é para resolver um problema pelo qual passei algumas vezes quando o assunto é customização de build: Cadê o objeto de Workspace nos template novos?

Pois é, estes novos templates tem uma forma diferente de trabalhar com o Download de código-fonte e gestão dos workspaces que ficarão na máquina de Build. Basicamente, uma atividade do tipo TfsGetSources encapsula essas atividades e é usada para baixar tudo e, caso precise de algumas informações adicionais do Build, você precisa usar a classe WellKnownEnvironmentVariables (Microsoft.TeamFoundation.Build.Activities.Extensions). Entretanto, nada de informações sobre workspace também nesta classe utilitária. Quem trabalha com customização de build há algum tempo sabe que as coisas mudaram bastante entre as últimas versões, não é?

Usar algumas das atividades relacionadas à Workspace da Toolbox (sim, eu tentei usá-las para resolver estes problemas) pode trazer problemas no seu template de build justamente por incompatibilidade com esta nova versão. Então, para resolver isto, executei alguns passos que quero compartilhar com vocês:

Atividade customizada para obter o Workspace

Para facilitar as coisas, eu criei uma Code Activity customizada para realizar o trabalho para mim. Usando a classe VersionControlServer em conjunto com IBuildDetail é possível obter o workspace em uso em um determinado contexto. Com isto, tudo que eu preciso são duas informações: o BuildDetail e o SourcesDirectory, informações que consigo obter através da classe WellKnownEnvironmentVariables (Microsoft.TeamFoundation.Build.Activities.Extensions). Criei então dois parâmetros de entrada para cada uma destas variáveis e um parâmetro de saída que devolverá o objeto de workspace obtido. Veja como ficou:

Usando a Code Activity no Template

Uma vez criada a Code Activity, é hora de usa-la no template de build. Para isto, assumindo que eu tenho um projeto para atividades customizadas e outro para os meus templates na solução, eu vou apenas adicionar a referência para o projeto de Atividades no de Templates. Feito isto, você vai ver que as atividades que você criou aparecem automaticamente na Toolbox para uso:

Antes de usa-la, precisamos obter as duas variáveis que ela precisa como entrada. Para isto, vamos seguir os passos abaixo:

  • Criar três variáveis para armazenar BuildDetail (IBuildDetail, Microsoft.TeamFoundation.Build.Client), SourcesDirectory (Sytem.String) e o Workspace (Microsoft.TeamFoundation.VersionControl.Client), com escopo Overall Build Process;
  • Criar uma Sequence para armazenar os passos de obtenção das variáveis e o de obtenção do Workspace;
  • Dentro da Sequence, adicionar duas atividades de Assign e obter BuildDetail e SourcesDirectory através do WellKnownEnvironmentVariables:

  • Finalmente, adicionar a atividade GetWorkspaceObject, passar os parâmetros de entrada e saída para posterior uso.

E pronto. Agora é possível trabalhar com o Workspace do Build em andamento sem maiores problemas. Este objeto é comumente usado em extensões escritas para versões anteriores do TFS as quais podem mexer em código-fonte do que está sendo compilado, como o TFS Versioning. Além disso, para que possa ter uma ideia do poder que este objeto dá em suas mãos, dê só uma olhada aqui: https://msdn.microsoft.com/en-us/library/microsoft.teamfoundation.versioncontrol.client.workspace.aspx

Até mais!

031415_1549_ComocriarTo5.png

Como criar Tools e Actions personalizadas no Release Management

Oi pessoal.

Hoje trouxe pra vocês um how-to de uma atividade que achei muito legal de trabalhar, na verdade achei até divertido, que é a criação de Tools (Ferramentas) e Actions (Ações) personalizadas/customizadas no Release Management.

Antes, vamos entender porque isto nos é útil: no meu caso, me deparei com a necessidade de compactar uma determinada pasta da publicação e enviar este arquivo para um site FTP. Atente que estas duas possibilidades não existem no Release Management out-of-the-box. Entretanto, tornar isto possível é uma atividade muito amigável na ferramenta. Vamos ver como colocando a atividade de compactação para funcionar no RM.

Tools

As Ferramentas no Release Management têm a serventia de viabilizar as Ações de Workflow de Release que usam recursos (aplicativos) que não estão presentes ou instalados nos servidores de deploy. Vale ainda dizer que uma Action usa uma Tool de diferentes formas. Como exemplo, podemos olhar para a Ferramenta IIS Deployer, que é usada para gerenciar o IIS e é usada em Ações como Configuração de Application Pools e Web Sites, Criação de Diretório Virtual, entre outras muitas. Para viabilizar a compactação, vamos criar uma ferramenta que usa o aplicativo 7zip, pois suporta execução via linha de comando.

Para isto, siga os passos abaixo:

  • No Release Management, acesse a aba Inventory (Inventário). Na sequência, vá para Tools.
  • Veja que as Ferramentas out-of-the-box estão todas listadas aqui e podem ser customizadas. Nós vamos criar a nossa através do botão “New”:
  • Nesta janela, que te mostro já preenchida, vemos algumas coisas muito interessantes. Vamos entender cada uma delas:
    • Command: aqui, informamos qual o comando a ser executado quando esta ferramenta é chamada. Repare que eu não me preocupei com o caminho completo dela. Em outras palavras, “onde ela está?”;
    • Arguments: aqui, definimos quais os parâmetros necessários para a ferramenta rodar. Bem como na criação de componentes, podemos criar variáveis usando underlines que automaticamente são exibidas em Parameters;
    • Resources: o ponto mais interessante e importante da etapa da criação de Ferramentas. Como disse ao descrever Command, não é necessário se preocupar sobre onde está o executável porque é neste momento que você envia ao Release Management todos os arquivos necessários para que a ferramenta seja executada. Com isto, no momento do release, os recursos para rodar o comando são enviados temporariamente ao servidor e, após o deploy, são apagados. Muita atenção pois, dependendo do tamanho dos recursos enviados aqui, seu deploy pode demorar um bocado;
      Ao salvar e fechar a criação da Ferramenta, ela já vai aparecer na lista do inventário pra você.

Actions

As Actions no Release Management podem usar ou não uma Ferramenta previamente criada. Você verá que uma Action pode também executar uma linha de comando, com as ressalvas já citadas na descrição das Tools.

  • O próximo passo, enfim, é criar sua Action. Para isto, ainda na aba Inventory, acesse Actions e veja todas as já existentes na ferramenta:
  • Nesta simpática janela, clicamos em “New“:
  • Mais uma vez, vamos entender os campos importantes da imagem da janela já preenchida:
    • Categories: veja que eu criei a categoria Custom através do link New que você pode encontrar ao lado do campo;
    • Tool used: aqui você simplesmente seleciona a Ferramenta criada no passo anterior (a partir daqui também é possível ir para a janela de criação de Ferramenta);
    • Arguments: como falamos anteriormente, a Action pode usar uma Tool de diferentes formas e este campo é um exemplo disso. Veja que é possível adicionar, remover ou modificar os argumentos do executável aqui, tendo como base o que foi criado para a Ferramenta.
  • E pronto, salvando e fechando esta janela, você já pode usar esta Action no Workflow de Release, assim:

E é isso. Legal, né? Fica aqui então minha dica para provocar a reflexão sobre o poder em mãos que temos quando podemos personalizar o uso da ferramenta neste nível.

Abraços!

Como customizar um Team Build de ponta a ponta

Olá pessoal,

Em uma conversa recente com um amigo, chegamos à conclusão de que há poucas fontes de referência para este assunto. Então, este artigo vem com o objetivo de cobrir a customização de build, de ponta a ponta.

Disclaimer: é um post longo… Mas objetivo!

Aqui, devemos cobrir:

  • Como customizar um template de build;
  • Como criar atividades customizadas para encapsular ações e viabilizar reaproveitamento;
  • Dicas e técnicas importantes durante o processo de customização.

Para este artigo, vamos imaginar um problema para resolve-lo através da customização. Minha sugestão é algo bem simples para fins de exemplo mesmo:

Dado um template de build existente (TfvcTemplate.12.xaml), eu quero que este pergunte meu nome e me devolva uma mensagem de saudação personalizada.”

Pois bem. O primeiro passo é obter este template de build existente. Para isto, vamos baixa-lo através da interface de criação de um novo build definition:

1 – Obter o template de build para customização

Na aba “Process“, em “Build Process Template“, clique em “Show Details“:

Na sequência, você verá um combo com a lista de todos os templates de build disponíveis para uso:

De acordo com a nossa “estória”, mantenha o Default Template selecionado e clique em “Download“:

Por enquanto, escolha um local qualquer para salvar o seu template (arquivo .XAML) com um nome diferente, talvez TfvcTemplate.12-customizado.xaml.

2 – Preparar a estrutura de projeto

A recomendação é que o template de build seja trabalhado de dentro de um projeto do tipo Class Library, contido em uma solução. Vamos então preparar esta estrutura:

Repare que eu criei uma solução no Visual Studio com um projeto do tipo Class Library dentro, conforme dito anteriormente. Veja também que eu já inseri o template que baixamos para dentro do projeto.

Entretanto, se você tentar compilar esta solução, você provavelmente vai se deparar com uma série de erros. Isto se dá porque o template de build tem que ser marcado para não compilar dentro do projeto. Para isto, basta acessar as propriedades do arquivo dentro da solução e definir a propriedade “Build Action” para “None” e limpar a propriedade “Custom Tool“. Assim:

Feito isto, você já está pronto para modificar o seu template de build. Veja:

3 – Primeiras customizações: variáveis e parâmetros

Conforme nossa estória diz, precisamos que o build nos “pergunte” qual o nome para depois devolver uma saudação usando esta entrada. Para isso, vamos precisar criar 2 itens: um argumento de entrada para o build, onde o usuário informará o nome, e uma variável para armazenar a saudação, que trabalharemos depois.

3.1 – Criando o argumento de entrada

Os argumentos no template de build podem ser de uma das quatro direções: In, Out, In/Out e Property. Isto está embasado no conceito do Workflow Foundation. Para mais informações, visite: https://msdn.microsoft.com/en-us/library/dd489456(v=vs.110).aspx

No nosso cenário, usaremos um argumento com direção In (entrada), ou seja, é um argumento definido pelo usuário.

Precisamos então criar o argumento NomeDoUsuario, para que este seja posteriormente usado para que o usuário informe seu nome. Para isto, expanda a sessão “Arguments” que fica no rodapé do workflow:

Ao expandir, você poderá ver a lista de argumentos já definidos neste template. Para criar um novo argumento, desça até o fim desta lista e clique na linha com “Create Argument” para criarmos o nosso:

Repare que criamos o argumento do tipo String. Entretanto, não é só isso. Para que este argumento seja visível para o usuário durante a edição do processo de build e/ou durante o enfileiramento de um novo build, é necessário informar sua existência nos Metadados (Metadata) do template de build. Para isto, use o argumento Metadata, que você encontra na lista de argumentos. Para editá-lo, clique nas reticências ao fim da linha dele:

É nesta janela que é possível editar a interface entre o usuário e os argumentos do template de build. Nela, definimos seus nomes amigáveis e descrições, além de informar se este é obrigatório ou não:

Aqui, vamos adicionar o argumento recém criado como parâmetro com as seguintes informações:

  • Parameter Name (nome exato do argumento): NomeDoUsuario
  • Display Name (nome amigável do parâmetro): O meu nome é
  • Category (categoria do parâmetro na definição do build. O agrupador de parâmetros): Customização de Build
  • Required (obrigatório): marcado
  • View this parameter when (quando ver este parâmetro? Só na definição ou na definição e enfileiramento de build): Always show the parameter (sempre mostrar o parâmetro)

3.2 – Criando a variável que vai armazenar o resultado da ação

A variável que vamos criar terá a serventia de armazenar o resultado da ação de gerar a saudação. Basicamente, guardará a string gerada. Variáveis são criadas com as seguintes informações:

  • Name: J
  • Variable Type: o tipo da variável. Pode ser de qualquer tipo compilado pelo .Net;
  • Scope: você pode definir qual o escopo da variável. Se quiser que ela fique restrita somente a um trecho do workflow, é aqui que você define isso;
  • Default: é possível definir um valor inicial para a variável.

Para trabalharmos na definição da nossa variável, precisamos expandir a sessão “Variables“, no canto esquerdo do rodapé do Workflow:

Após esta expansão, basta você selecionar um escopo (trecho ou “caixinha” do workflow) que será possível criar uma nova variável clicando na linha com o texto “Create Variable“. Vamos criar uma como a imagem abaixo:

Feito isto, o template de build já está preparado para receber o input do usuário e armazenar a saída da ação. O próximo passo agora é customizar uma atividade de workflow para executar a “regra de negócio” da nossa estória.

4 – Criando uma atividade de build customizada

O grande objetivo de criar uma atividade customizada de build é ter a praticidade de codificar as ações necessárias, sem depender de design e de atividades de workflow prontas. Afinal, com o código, temos todo o poder, não é? J

A nossa atividade nada mais será do que um método que recebe uma string, a insere num texto de saudação e devolve este como resultado. Vamos lá!

4.1 – Criando a estrutura necessária

Para criarmos atividades de workflow customizadas, precisamos adicionar à solução um tipo de projeto específico e, depois de terminarmos a atividade, adicionamos uma referência dele no projeto que armazena os templates de build.

Vamos então adicionar à solução um projeto do tipo “Activity Library“:

Este novo projeto já virá com uma atividade XAML, a qual você pode excluir. Vamos adicionar então uma Code Activity para codificar nossa “regra de negócio”. Para isto, botão direito no projeto e Add > New Item… > Workflow > Code Activity

4.2 – Codificando sua atividade

Uma vez adicionada a Code Activity, habemus código! Antes, vamos abaixo entender algumas particularidades deste código:

  • Toda classe de atividade de workflow herda CodeActivity;
  • Os argumentos de entrada são atributos da classe do tipo InArgument<T>;
  • Os argumentos de saída são atributos da classe do tipo OutArgument<T>;
  • Toda a execução da atividade deve ficar dentro do método Execute, que recebe o parâmetro context, que orquestra as entradas e saídas da atividade.

Tendo estes conceitos definidos, nosso código ficou assim:

Atividade codificada e compilando… É hora de usá-la no template de build!

5 – Usando uma atividade própria no template de build

Agora é a hora de juntar as pontas. A forma mais fácil de conseguir utilizar a sua atividade no template de build é adicionando uma referência do projeto de atividades no projeto que armazena os templates, assim:

Após isso, abra o template de build novamente e acione a toolbox e veja isto acontecendo automaticamente:

Veja que o nome do projeto de atividades customizadas na solução aparece como nova sessão na toolbox e, claro, a atividade criada aparece dentro desta sessão.

Uma vez disponíveis para uso, basta arrastar a atividade para dentro do template de build, configurar e salvar para usar. Vamos lá, eu arrastei para um local no template para que ela fosse primeira atividade do processo:

Depois que atividade encontra-se dentro do workflow, precisamos configurá-la. Para isso, vamos acessar suas propriedades a selecionando e acionando F4 na sequência. Veremos isto:

Repare que as variáveis que codificamos na nossa atividade customizada constam aqui. E é nestas variáveis que vamos usar o argumento e variáveis que criamos no template de build anteriormente. Assim:

Trocando em miúdos, o que o usuário informar no nome será repassado à atividade e o resultado da atividade será armazenado na variável SaudacaoGerada. Inclusive, para vermos o resultado no sumário do build, precisamos adicionar uma outra atividade, esta nativa, para exibir a saudação gerada. Vamos então arrastar para o workflow, logo após a nossa atividade customizada, uma atividade do tipo WriteBuildMessage:

Esta atividade vai escrever na tela o que consta na variável SaudacaoGerada. Vamos analisar as propriedades desta atividade:

Veja que atribuímos à Message a variável SaudacaoGerada e, para que possamos verificar esta mensagem no sumário do build sem precisar consultar logs, definimos a propriedade Importance desta atividade como High (enum Microsoft.TeamFoundation.Build.Client.BuildMessageImportance) para que esta mensagem sempre apareça no sumário.

E pronto. Temos nosso template de build e atividade customizada pronto para uso. Agora é colocar para funcionar.

6 – Configurando o build controller para “conhecer” as atividades customizadas

Uma vez que temos assemblies usados no template de build os quais o TFS não conhece nativamente, é necessário configurar o build controller para saber onde busca-los. A forma para configurar isto é versionar estes assemblies no TFS e apontar o caminho onde eles estão para a build controller.

No caso da nossa atividade customizada, versionei a DLL gerada no caminho $/MSFAgileTfvc.4/custombin. Precisamos configurar a build controller para buscar qualquer assembly desconhecido neste caminho. Para isto, vamos seguir os procedimentos abaixo:

  • No Team Explorer, em Builds, clique em “Actions” e depois “Manage Build Controllers“:
  • Nesta nova janela, selecione a build controller e clique no botão “Properties“:
  • Nesta nova janela você deve especificar, em “Version control path to custom assemblies“, o caminho para a pasta que contém a DLL da atividade customizada:
    • Veja que há um botão com reticências que te ajuda a procurar o local no TFS.

7 – Criar a build definition

Tendo o projeto (e consequentemente o build template) versionado, bem como a DLL da atividade customizada apontada no build controller, é hora de configurar o build definition para usar todos estes artefatos. A única diferença aqui para uma criação de build comum é que vamos ter que procurar e adicionar este novo template de build às opções no combobox que vimos no início do artigo. Para isto:

  • No Team Explorer, em Builds, clique em “New Build Definition“;
  • Na janela de nova definição de build, defina todos os parâmetros normalmente até chegar na aba “Process“;
  • Nesta aba, será necessário adicionar o build customizado à lista de templates. Clique então em “Show Details” e depois no botão “New…“. Você verá esta janela:
  • Aqui, você deve encontrar o template de processo customizado no versionador. Feito isto, clique em “OK” e você já poderá utilizar o seu template.
  • Repare que, em “Build process parameters“, o parâmetro que criamos no template já aparece:
  • Repare que o parâmetro também aparece no enfileiramento de build, conforme configuramos:

Vamos então terminar de configurar a definição de build e enfileirar uma execução para acompanhar o resultado. Neste exemplo, eu selecionei para compilar a própria solução da atividade customizada.

E aqui está o resultado: nossa mensagem escrita no resultado do build.

Este foi apenas um exemplo de como customizar o build indo além do template, seguindo para a codificação de atividades. É importante ressaltar isto porque poder codificar aumenta e muito as possibilidades. Espero que o recado “dentro do código tudo é possível” tenha ficado claro aqui.

É claro, a customização de builds tem uma série de outros pequenos detalhes que não cobri neste artigo. Entretanto, a possibilidade de codificar é a mais valiosa das funcionalidades. E se houver dúvidas sobre algo não coberto, não hesite em me chamar J

Abraços

[QuickTip] A exclusão de Team Projects no Visual Studio Online

O Visual Studio Online é uma tendência que vem se consolidando para trabalhar com a plataforma e as práticas de ALM no mundo Microsoft. Entretanto, há algumas adaptações que se fazem necessárias. Rapidamente, podemos citar algumas delas:

  • Você tem obrigatoriamente uma coleção, ou seja, uma conta no VSO = uma Team Project Collection;
  • Você só pode usar um dos 3 templates de processos disponíveis na ferramenta e não pode customizá-los (por enquanto);
  • E, claro, você não tem o Console de Administração do TFS porque não tem administração da máquina que o hospeda, caracterizando o PaaS;
  • Entre outras.

Tendo isto em vista, tive que realizar uma ação recentemente no VSO que me deixou curioso: excluir um Team Project. Isto por 2 motivos: como dito acima, não temos a Console de Administração do TFS e também porque não é trivial através da interface do produto.

E para você que chegou aqui porque estava procurando como fazer isso, aqui estão os passos:

Ao autenticar-se no VSO, encontre a engrenagem no canto superior direito e clique lá!

deletetp_1

Veremos uma área de configuração e você já estará na aba “Control Panel” com a sua única coleção selecionada, a Default Collection.

deletetp_2

Veja que, do lado direito, aparecem algumas informações sobre a sua coleção como: Nome, quantidade de Team Projects e status. Logo abaixo, há alguns links para algumas tarefas administrativas. Selecione então “View the collection administration page” para chegar à página de administração da coleção:

deletetp_3

Nesta nova tela você pode, basicamente, gerenciar as permissões no nível de coleção, criar um novo projeto (o que pode ser feito através da Home do VSO) e excluir os seus Team Projects. Repare que, ao passar o mouse por cima de um deles, vai aparecer uma seta do lado esquerdo. Ao clicar nela, você verá a opção de exclusão do Team Project:

deletetp_4

E aí está a tal opção de exclusão de Team Project. Então: nada de usar linhas de comando, hein! :-)

Abraços!

TFS Checkout Notification 1.1 – Ver, desfazer e subir as pendências!

Olá pessoal,

Dados os feedbacks que recebi recentemente, temos o TFS Checkout Notification em sua versão 1.1 com as novidades abaixo:

  • Nova janela para exibir os checkouts. Aqui, você pode:
    • Ver os seus checkouts;
    • Fazer check-in de todas as pendências ou somente das selecionadas. É importante ter cuidado com esta funcionalidade, pois se houver alguma pendência que pertença a um Team Project com políticas de check-in, estas serão desobedecidas e o Administrador do TFS (ou seu chefe) receberá uma notificação disso.
    • Desfazer as pendências de check-in;
    • Esta nova janela pode ser acessada clicando no balão de notificação ou através de um atalho no menu de contexto.

O instalador desta nova versão já está disponível aqui.

Os feedbacks são bem vindos!

Um abraço,

TFS Checkout Notification – Chega da galera esquecer os checkouts e ir embora!

Olá pessoal,

Na semana passada eu implementei uma ideia que tive recentemente numa consultoria. O problema era basicamente simples: como ajudar o pessoal que esquece os checkouts na estação de trabalho e vai embora?

Nós nunca sabemos o que o cidadão esqueceu ali. Alguns problemas comuns que isto pode gerar são:

  • Com checkout exclusivo habilitado no Team Project, outros não conseguirão trabalhar nos arquivos presos pela pessoa que esqueceu os checkouts;
  • Caso a máquina do cidadão nunca mais ligue por qualquer motivo, as mudanças estão lá, sem backup e segurança;
  • Em casos comuns de migração de Source Control em Consultorias de ALM, estas modificações não seriam migradas e perderiam associação com o versionador, pois estariam associadas à um Team Project que pode vir a não existir mais.

Entre outras coisas. E principalmente pelo segundo motivo, que recomendamos que ao menos o Shelve seja utilizado ao fim do dia, evitando que checkouts sejam esquecidos no versionador.

Foi pensando em ajudar os desenvolvedores a se lembrarem de remover estas pendências que eu criei o TFS Checkout Notification. Um pequeno app que fica rodando na bandeja do Windows e mostra balões de notificação num intervalo determinado por você caso haja checkouts pendentes. Assim:

TFSCheckoutNotification

O aplicativo se inicia com o Windows e você pode configurar duas formas de ele procurar por pendências:

  • Num intervalo de tempo:
    • Você pode definir um intervalo, em horas ou minutos, para que o app faça a busca por pendências de check-in e o notifique.
  • Assim que o Visual Studio fechar;
    • É possível também configurar o app para verificar se você esqueceu checkouts somente quando o Visual Studio fechar.

Para ir para a página do projeto no GitHub, temos este link.

Para baixá-lo, é só seguir este aqui.

Espero que gostem! E sintam-se à vontade para contribuir com mudanças e sugestões!

Abraços,