Team Foundation Server: как настроить рабочие пространства для двух приложений, которые совместно используют сборки?

Question

У меня есть вопрос о рабочих пространствах в TFS. В настоящее время я использую TFS 2008 (хотя скоро перейду на TFS 2010), и у меня есть два рабочих пространства:

• Workspace1
• Workspace2

Каждый Workspace1 и Workspace2 содержат разные приложения, которые имеют разные цели, разные пользовательские базы, разные разработчики, которые над ними работают и т. Д. И поэтому было решено, что эти два приложения должны находиться в своих собственных рабочих пространствах, чтобы поддержка отдельного управления сборкой, отдельных разрешений и т. д. Однако в прошлом некоторые ошибки в планировании создавали зависимость от Workspace2 изнутри Workspace1. Чтобы приложение в Workspace1 компилировалось, оно должно ссылаться на некоторые сборки в Workspace 2. Итак, сегодня это выглядит так:

• Workspace1
  • Ссылки на сборки Workspace1 и сборки Workspace2
• Workspace2
  • Ссылки на сборки Workspace2

Теперь я хотел бы посмотреть, есть ли «лучший» способ сделать следующее:

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

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

Итак, мой вопрос действительно тройной:

1. Имеет ли это смысл для кого-то еще?
2. Что я делаю неправильно, что приводит меня в эту ситуацию?
3. Если бы вы оказались в такой ситуации, что бы вы с этим сделали?

Answer 1

1. Извлечение общего кода из собственного проекта
2. Автоматизированные сборки этого нового проекта развернут получившиеся сборки в папку на общей папке
3. Оба существующих проектабудет ссылаться на общий код из общего ресурса

Двоичные файлы не являются исходными и не должны проверяться в системе контроля версий (IMHO).

Answer 2

У вас есть несколько вариантов, у всех есть компромиссы.

1. Разделите «общий код» на отдельный проект TFS. как сказал Джон, у каждого зависимого приложения есть ссылка на место размещения сборки общего проекта.

2. Поместите «общий код» в проект, с которым он наиболее соответствует циклу разработки / выпуска. Под этим я подразумеваю проект, с которым у него есть общая команда разработчиков, общий цикл выпуска и общие спецификации рабочих элементов. Другие проекты, которые являются зависимыми, ссылаются на сборку из этого места размещения проектов.

3. Поместите все проекты, которые «совместно используют» код с общей библиотекой, в один проект TFS вместе с «общим кодом». При необходимости создайте отдельные сборки для каждого решения VS. Даже заблокируйте возможность регистрации в общем решении / проекте, если это необходимо.

Answer 3

давным-давно я трачу много времени, чтобы найти наилучшую структуру файлов в системе контроля версий, и после прочтения руководства по p & p он покажет мне все, что мне нужно, например структурирование проектов и решений в области управления исходными кодами, стратегии ветвления и слияния Управление зависимостями управления исходным кодом в Visual Studio Team System и многие другие полезные вещи: вы можете скачать их с codeplex, перейдя по следующей ссылке http://tfsguide.codeplex.com/

Answer 4

Я думаю, что это зависит от того, какой тип ссылки Workspace 1 имеет на Workspace 2. Если сборки, на которые есть ссылки, выполнены в стиле "Сторонних разработчиков" - я имею в виду, что они не очень часто обновляются и имеют довольно неизменный API, Точно так же ссылка на библиотеку из Интернета будет. Если это так, я бы включил встроенные двоичные файлы в Workspace 2 в Workspace 1 в папке, где на них можно ссылаться. Всякий раз, когда выполняются обновления для двоичных файлов Workspace 2, извлекайте файлы в Workspace 1, копируйте встроенные файлы поверх и проверяйте их.

Если код и API сборок Workspace 2 часто меняются, у вас есть 2 варианта.

1. Вы можете попробовать объединить 2 рабочих пространства (не уверен, насколько это просто).
2. Вы можете попробовать перенести указанные двоичные файлы из Workspace 2 в Workspace 1. Здесь есть информация о том, как это сделать , здесь , но есть ограничения, например, тот факт, что вы не можете ветвиться в Workspace 1 (чтобы сделать ветка релиза / функций), в то время как она имеет ветку с Workspace 2.