Можно ли сопоставить один проект VSTS с различными локальными рабочими пространствами?

Question

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

Answer 1

Хотя я согласен с Дэниелом в том, что это, вероятно, плохая идея и что есть альтернативы, это вполне возможно;Однако есть одно ограничение: каждое рабочее пространство должно иметь свою собственную копию общего проекта на жестком диске , они могут совместно использовать удаленную копию на сервере.Это очень похоже на модель управления распределенным исходным кодом и может работать просто отлично.

Чтобы сделать это, сначала создайте одно рабочее пространство и сопоставьте папки локально:

 Workspace 1
 $/Common/           => c:\src\1stProject\Shared
 $/ProjectA/Solution => c:\src\1stProject\SolutionA

Затем создайте второерабочее пространство:

 Workspace 2
 $/Common/           => c:\src\2ndProject\Shared
 $/ProjectB/Solution => c:\src\2ndProject\SolutionB

Таким образом, оба проекта совместно используют одно и то же расположение сервера, и изменения, внесенные в Shared, напрямую влияют как на SolutionA, так и на SolutionB.Однако локально каждое решение будет иметь свои локальные ожидающие изменения и т. Д.

Это решение будет работать, пока оба командных проекта находятся в одной коллекции проектов TFS.

Единственное ограничение заключается в том, что этипроекты не могут быть помещены в подпапки друг друга, поэтому вы не можете сделать это:

 Workspace 1
 $/Common/           => c:\src\1stProject\SolutionA\Shared
 $/ProjectA/Solution => c:\src\1stProject\SolutionA

Также не можетеобе рабочие области отображаются в одну и ту же локальную папку:

 Workspace 1
 $/Common/           => c:\src\Shared
 $/ProjectA/Solution => c:\src\1stProject\SolutionA

 Workspace 2
 $/Common/           => c:\src\Shared
 $/ProjectB/Solution => c:\src\1stProject\SolutionB

Альтернативы

Nuget

Вместо непосредственного использования общих источников добавьте NuSpec в общий проект и постройте и опубликуйте пакет NuGet в фиде управления пакетами VSTS учетной записи VSTS.Добавьте ссылку NuGet на SolutionA и SolutionB.Таким образом, двоичные файлы Common являются общими для SolutionA и SolutionB, но общие поддерживаются независимо.Таким образом, также проще обновлять SolutionA с другой частотой, чем SolutionB (это также самая большая ловушка для этого решения).

Git & Submodules / Subtrees

Convertрепозитории TFVC для репозиториев Git.Таким образом, вы можете использовать поддерево или субмодули для ссылки на Common непосредственно из репозитория SolutionA и репозитория SolutionB.

MonoRepo / Один проект, чтобы управлять ими всеми

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

 Workspace Single
 $/Project/Shared    => c:\src\Shared
 $/Project/SolutionA => c:\src\1stProject\SolutionA
 $/Project/SolutionB => c:\src\2ndProject\SolutionB

Результатом будет то же, что и следующий межпроектный макет:

 Workspace Single
 $/CommonProject/    => c:\src\Shared
 $/ProjectA/         => c:\src\1stProject\SolutionA
 $/ProjectB/         => c:\src\2ndProject\SolutionB

Примечание

Inлюбая межпроектная настройка, пользовательский интерфейс Visual Studio и VSTS будет бороться с вами.Команда VSTS работает над тем, чтобы сделать отдельные командные проекты переносимыми между учетными записями.Для того, чтобы сделать это, функции должны быть отброшены в какой-то момент.Например, пользовательский интерфейс в сборке VSTS не будет показывать другие командные проекты в средстве выбора источника.Если вы введете пути вручную, они будут работать (если вы сконфигурируете сборку, чтобы иметь область действия уровня сбора).

Advice

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

Если вам нужно редактировать файлы в любом решении, я настоятельно рекомендую вам изучить Git Subtrees или Git Submodules .Git - это будущее в любом случае, и эти функции позволят вам достичь того, что вам нужно, гораздо проще.Они действительно идут с крутой кривой обучения.

Answer 2

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

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

1. Сопоставить одно рабочее пространство, содержащее все командные проекты, и использовать относительные пути для ссылок.Это не здорово, в идеале каждый командный проект считается совершенно отдельным объектом.
2. Поместите все в один командный проект и поддерживайте единое рабочее пространство для всего.
3. Превратите общий компонент в пакет NuGet и используйте Фид управления пакетами .Каждый потребитель разделяемого компонента может затем ссылаться на общий пакет NuGet.

Я бы сказал, # 1 уже исключен в качестве опции.Каждый командный проект должен быть независимым субъектом, между которым ничего нет.Поскольку у вас есть общие вещи, вы выбрали неправильную организационную структуру.Прекратите использовать несколько командных проектов.

Вариант 2 приемлем, но он немного более грубый.

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

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