2015-06-10 5 views
0

Это теоретический вопрос о ветвлении, а не о архитектуре кода или слоях.Какова лучшая стратегия ветвления в TFS для совместного использования кода между несколькими командами?

У меня есть проект команды «SuperLibs» с 25 проектами .NET (которые являются библиотеками классов). Структура Команда проекта такова:

  • Main (текущая стабильная версия в стадии разработки)
  • Dev (ответвляются от Main - нестабильная код в стадии разработки)
  • Релизы \ Release 1.0
  • Релизы \ Release 2.0
  • релизы \ и т.д ...

И у меня есть еще один проект команды «SuperLogic», который содержит логику и зависит только от 5 проектов от SuperLib. Структура Команды проекта такова:

  • Main (текущая стабильная версия в стадии разработки)
  • Dev (ответвляется от Main - нестабильный код в стадии разработки)
  • Shared \ SuperLibs \ Release 1.0 (ответвляется от версии 1.0 SuperLibs)
  • Shared \ SuperLibs \ Release 2.0 (разветвленными с версии 2.0 SuperLibs)
  • релизы \ Release 1.0
  • Выпуски \ Release 2.0
  • Релизы \ и т.д. ...

И, наконец, у меня есть третий проект команды «SuperApp», которая зависит как от «SuperLibs» и «SuperLogic». Структура Команды проекта такова:

  • Main (текущая стабильная версия в стадии разработки)
  • Dev (ответвляется от Main - нестабильный код в стадии разработки)
  • Shared \ SuperLibs \ Release 1.0 (ответвляется от версии 1.0 SuperLibs)
  • Shared \ SuperLibs \ Release 2.0 (разветвленный с версии 2.0 SuperLibs)
  • Shared \ SuperLogic \ Release 1.0 (разветвленными с версии 1.0 SuperLogic)
  • Shared \ S uperLogic \ Release 2.0 (не ответвляются от версии 2.0 SuperLogic)
  • Релизы \ Release 1.0
  • Релизы \ Release 2.0
  • Выпуски \ Etc ...

нет бинарных ссылок используются. Используются только ссылки на проекты.

Теперь вот ситуация:

  • Когда я строю «SuperLibs» - все нормально
  • Когда я строю «SuperLogic» - все еще хорошо, потому что SuperLogic есть ссылки на проекты SuperLibs' в папке «Shared \ SuperLibs \ Release xy»
  • Но когда я пытаюсь создать «SuperApp» - он терпит неудачу, потому что он может ссылаться на SuperLogic и SuperLib внутри папки «Shared», но «SuperLogic» в папке «Общие» не может ссылаться "SuperLibs".

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

+0

Я использую Team Foundation Server 2012. – Dima

+0

Почему они являются отдельными командами? Вам нужна разная безопасность для каждого? Различные шаблоны процессов? Очень разные выпуски каденции? Было бы намного проще, если бы у вас просто было три разных дерева в рамках одного и того же командного проекта. Затем вы могли бы добавить проекты библиотек в качестве ссылок на проекты в тех решениях, которые их требуют. –

+0

Это по многим причинам. В основном я бы пошел на один Team Project, но так как не могу - я должен решить его с несколькими Team Projects :) – Dima

ответ

3

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

+0

Но разве он не удалит доступ к исходному коду? – Dima

+0

Да, правильно, вы не должны делиться кодом, используемым более чем одним решением. Это массивный анти-шаблон, который приводит к ухудшению качества кода. –