Рабочие пространства TFS, включая общий код

Question

Мы работаем над улучшением использования нашего сервера TFS/TFVC и переходим к использованию рабочих элементов TFS, и мне поручено выяснить, как это сделать.

У нас есть много проектов, большинство из которых работают с общими библиотеками кода. Наш способ внедрения новых функций состоял в том, чтобы просто включить ссылку на код и собрать все вместе, когда необходимы изменения, вместо ссылки на библиотеки DLL для библиотек.

Мой вопрос вращается вокруг создания рабочих пространств, которые не приводят к затруднениям при обновлении кода в общих библиотеках, а также в основном проекте.

Работая с этим кратко, я создал несколько проектов для каждого продукта, который мы разрабатываем, и похоже, что отдельный разработчик должен обязательно перемещаться между всеми рабочими пространствами, связанными с отдельным проектом, и проверять код для каждый из них. Я чувствую, что это неуклюже и что должен быть лучший способ сделать это.

структура может выглядеть примерно так:

ROOT 
|- Common Code 
|- Team projects (each having their own backlog and referencing "Common Code" 
|--- Product one 
|--- Product two 
|--- Product three 

бы лучший подход будет работать на одном рабочем пространстве и просто создавать команды и иметь заделы для каждого или есть чистый способ позволяет разработчикам использовать общую библиотеку кодов из отдельных проектов команды?

Answer 1

Существует множество соображений, связанных с настройкой ваших командных проектов. Самой важной причиной для разграничения проекта является безопасность. Если вам необходимо убедиться, что разные проекты не видят метаданные других проектов, то один проект Team Project - плохая идея.

Если у ваших команд есть существенные различия в процессе, за которым они следуют, у них также может возникнуть потребность в различных командных проектах, поскольку процесс может быть определен только на уровне проекта, и все команды в рамках одного и того же проекта команды должны следовать (Scrum, CMMI, Agile или пользовательский процесс). Возможно, стоит переместить ваши команды на один и тот же шаблон процесса, однако между Scrum и Agile не так уж много различий, поэтому, если вы не зависеть от CMMI или тяжелого пользовательского шаблона, вы можете практиковать Scrum и что-то другое в Agile в любом шаблон с немного фантазии.

Во всех других случаях может быть полезно рассмотреть creating a single Team Project and using Team Backlogs to represent your projects. Этот подход обычно называется настройкой «Один проект для их всех».

Что касается вашего проекта «common code», я лично рассмотрел бы возможности управления пакетами Visual Studio Team Services для создания пакетов NuGet изменений, внесенных в общий код. The ALM Rangers have written some guidance on setting this up in the past, it's not updated to the latest version of VS and TFS, but it does give a nice outline of the process. Затем включите эти общие библиотеки в качестве ссылок пакета NuGet на другие ваши проекты. Это дает вам больший контроль над тем, когда конкретные проекты обновляются до определенной версии общих библиотек, и это приводит к хорошему разделению между различными проектами с использованием общих библиотек. Сделав это, вам также легче настроить такие вещи, как Continuous Integration, Gated Checkins и т. Д., Работая со сложными рабочими пространствами, сделает это сложнее, как вы узнаете.

Так это будет выглядеть следующим образом:

+- YourAccount.visualstudio.com 
    +- CompanyProject (Team Project) 
    +- TFVC Repository (Can only be one) 
     +- Common (folder) 
     +- Project 1 (folder) 
     +- Project 2 (folder) 
     +- Project 3 (folder) 
    +- Package Management nuget repository 
     +- Common 
    +- Teams 
     +- Root/Company 
      +- Project 1 
      +- Project 2 
      +- Project 3 

Если переместить свои проекты в Git, он также становится немного легче, так как вы можете иметь несколько Git репозиториев в рамках того же проекта.