Является ли хранение нескольких продуктов в рамках одного проекта TFS плохой идеей?

Question

Team Foundation Server 2008 развернут в качестве нашей системы управления исходным кодом.Команда, отвечающая за несколько продуктов, просит, чтобы все их продукты были включены в один проект TFS.Их причина в том, что все продукты находятся в одинаковом домене.

Вот мои причины против:

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

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

Какие плюсы / минусы?

Answer 1

У меня есть опыт хранения нескольких решений Visual Studio (отдельных продуктов) в одном командном проекте TFS как в TFS2008, так и в TFS2010.Вот мое мнение.

В обеих версиях мы создаем папку для Продукта, затем папку для филиалов (Основная и т. Д.). Это позволяет легко увидеть, над каким продуктом мы работаем, и мы можемувидеть историю продукта отдельно от других продуктов.Непрерывная интеграция прекрасно работает с несколькими определениями сборки, по одному для каждого продукта.Мы создаем только одно сопоставление рабочей области для всего командного проекта TFS.

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

В TFS2010 рабочие элементы имеют раздел Области и итерации.Мы используем Район для определения Продукта.Таким образом, каждый рабочий элемент получает область, соответствующую названию продукта.Это очень хорошо сработало для нас.

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

Использование одного командного проекта имеет некоторые преимущества: 1. Для управления существует только один командный проект, и существует только один сайт Share Point.2. Вы можете легко просматривать историю всего командного проекта.

Answer 2

Мои мысли:

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

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

Единственное, что вы можете потерять, сложив все это вместе, - это быстрая и простая отчетность. Если все находится в собственном командном проекте, встроенная отчетность работает «из коробки». Если вы соберете все воедино, вам потребуется настроить дополнительные области и итерации, чтобы создавать отчеты и отслеживать.

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

Answer 3

Использование одного командного проекта для более чем одного программного обеспечения является вполне приемлемым решением, если вы не используете для них отдельные шаблоны. У Мартина Хиншелвуда есть подробное сообщение в блоге на эту тему.

http://blog.hinshelwood.com/when-should-i-use-areas-in-tfs-instead-of-team-projects-in-team-foundation-server-2010/