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

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

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

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

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

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

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

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


person msweltzdk    schedule 02.01.2017    source источник
comment
PS, какую версию TFS вы используете? Управление пакетами было введено совсем недавно, остальная часть настройки будет работать с любой версией TFS / VSTS с 2012 года. Если ваша версия TFS еще не поддерживает управление пакетами, вы можете рассмотреть возможность использования ProGet. Он предлагает бесплатную версию, которой достаточно для начала.   -  person jessehouwing    schedule 02.01.2017
comment
@jessehouwing Мы недавно обновились до TFS 2017, так что мне, кажется, просто нужно заглянуть в Управление пакетами. Я новичок в области эксплуатации, так как очень скоро перехожу с должности разработчика на ИТ-операции / DevOps. Я очень благодарен за вашу помощь.   -  person msweltzdk    schedule 02.01.2017


Ответы (1)


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

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

Во всех других случаях может быть полезно рассмотреть возможность создания единого командного проекта и использования бэклогов группы для представления ваших проектов.. Такой подход обычно называют настройкой «Один проект, чтобы управлять всеми».

Что касается вашего проекта «общего кода», я бы лично рассмотрел возможность использования функций управления пакетами Visual Studio Team Services для создания пакетов NuGet с изменениями, внесенными в общий код. Рейнджеры ALM уже писали некоторые инструкции по настройке этого параметра, оно не обновлено до последней версии. VS и TFS, но это дает хорошее представление о процессе. Затем включите эти общие библиотеки в качестве ссылок на пакеты NuGet для других ваших проектов. Это дает вам больше контроля над тем, когда определенные проекты обновляются до определенной версии общих библиотек, и приводит к четкому разделению между различными проектами, использующими общие библиотеки. После этого также будет проще настроить такие вещи, как непрерывная интеграция, закрытые проверки и т. Д., Работа со сложными рабочими пространствами усложнит это, как вы сами обнаружите.

Это будет выглядеть так:

+- 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 в одном проекте.

person jessehouwing    schedule 02.01.2017
comment
Следуя этому подходу, я могу представить, что у нас будет возможность использовать разные шаблоны процессов, если, скажем, одна команда работает со Scrum, а другая - с Agile, да? - person msweltzdk; 02.01.2017
comment
У нас есть несколько библиотек классов, составляющих нашу общую базу кода, но я бы предположил, что это отдельные пакеты NuGet, и, следовательно, не проблема. - person msweltzdk; 02.01.2017
comment
Нет, в одном проекте, чтобы управлять всеми настройками, все команды должны использовать один и тот же шаблон процесса. - person jessehouwing; 02.01.2017
comment
Совместное использование кода, а не двоичных файлов - серьезный антипаттерн кодирования. - person MrHinsh - Martin Hinshelwood; 02.01.2017
comment
@jessehouwing Arh, значит, CompanyProject будет нашим командным проектом, и у нас будет несколько репозиториев в этом проекте? Не могли бы мы, если бы мы использовали подход NuGet, иметь индивидуальные репозитории с командой для каждого? Уходя от одного, чтобы править всеми - подход - person msweltzdk; 02.01.2017
comment
Нет, если вы не перейдете на Git. У вас может быть только один репозиторий TFVC для каждого командного проекта. Таким образом, вам нужно будет создать корневую папку в этом репо для каждого проекта исходного кода. - person jessehouwing; 02.01.2017
comment
@jessehouwing Спасибо за разъяснения. Используя управление пакетами, мы могли бы иметь несколько командных проектов с отдельными репозиториями, верно? В моей голове мы бы тогда устранили необходимость в общем коде, поскольку у нас были бы просто пакеты NuGet, которые мы могли бы использовать всякий раз, когда нам это нужно. - person msweltzdk; 02.01.2017