Melhor maneira: reestruturar uma solução existente do Team Foundation Server (TFS)

No meu departamento, estamos desenvolvendo vários AddOns menores para algum servidor de comunicação unificado. Para versão e desenvolvimento distribuído, usamos um Team Foundation Server 2012.

Mas: existe apenas uma solução TFS grande para todos os nossos aplicativos e bibliotecas:

• Solução principal
  • Formulários
    
    • App 1
    • App 2
    • App 3
  • Externals
  • Bibliotecas
    
    • Lib 1
    • Lib 2
  • Ferramentas

O caminho "Aplicativo" contém todos os aplicativos principais. Isso não depende um do outro, mas depende dos projetos Bibliotecas e Externos.

O caminho "Externos" contém algumas DLLs externas mencionadas em nossos Aplicativos e Bibliotecas.

O caminho Bibliotecas contém bibliotecas comumente usadas (modelos de interface do usuário, classes Helper, etc.). Eles não dependem um do outro e são referenciados nos projetos Bibliotecas e Ferramentas.

O caminho Ferramentas contém alguns programas auxiliares, como auxiliares de instalação, atualizar serviços da web etc.

Agora, há alguns pontos importantes pelos quais eu gostaria de mudar essa estrutura:

• Não podemos usar compilações de servidor.
• É desconfortável gerenciar o gerenciamento de scrum TFS com sprints, impedimentos etc. com uma estrutura de solução como essa.
• Todo desenvolvedor sempre tem acesso a todos os projetos na solução.
• Uma compilação completa dura muito tempo se alguém acidentalmente pressionar [F6] no Visual Studio ...

O que você mudaria nesta solução? Como você dividiria esses projetos em soluções menores, como essas soluções deveriam ser estruturadas.

Minha primeira abordagem seria criar um projeto TFS para cada aplicativo, biblioteca e ferramenta. Mas como posso garantir que, por exemplo, o App 2 sempre contenha a versão mais recente da Lib 1? Preciso monitorar as alterações na Lib 1 e atualizar o App 2 manualmente assim que a Lib for alterada? Ou posso de alguma forma forçar o Visual Studio a sempre usar a versão mais recente de um projeto externo?

Edit: No TFS, há apenas uma coleção de projetos de equipe do TFS, contendo um projeto de equipe do TFS. O Projeto de equipe contém uma solução grande do Visual Studio, que contém várias pastas contendo (consulte a estrutura acima), cada uma delas contendo vários projetos de VS.

Minha pergunta é agora, como você reorganizaria:

1. Os projetos da equipe do TFS
2. Os Projetos VS

Atenha-se a um projeto de equipe do TFS, ter vários torna-se um problema ao tentar atualizar e tem algumas limitações quando se trata de cruzar itens de trabalho do projeto de equipe. Em vez disso, você deve fazer uso pesado de Áreas e Iterações.

Divida sua solução VS em várias soluções, uma por aplicativo principal. Isso acelerará muito as compilações locais, bem como o servidor de compilação.

O TFS2012 tem um novo conceito chamado Equipes, cria uma equipe por aplicativo e define iterações e registros pendentes padrão para cada um. Dessa forma, você pode gerenciar o backlog de cada um ou exibir a equipe raiz para ver um backlog acumulado. Em seguida, você pode gerenciar sprints no nível do aplicativo ou no geral, dependendo do que mais lhe convier.

Crie pacotes NuGet para todas as bibliotecas referenciadas por terceiros que ainda não tenham uma. Armazene-os em um repositório privado (pasta compartilhada do Windows) e ative o recurso de restauração de pacotes do NuGet clicando com o botão direito do mouse em todas as soluções e habilitando-o (também permita que a restauração de pacotes baixe pacotes nas configurações vs).

Se você possui bibliotecas internas compartilhadas, crie pacotes NuGet para elas também e crie uma solução vs contendo apenas essa biblioteca. Adicione um comando pós-compilação para criar o pacote nuget ou estenda seu modelo de compilação tfs para fazer isso (há vários modelos por aí que já fazem isso).