Блог

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

Вот мои доводы против:

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

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

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

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

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

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

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

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

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

Мои мысли:

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

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

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

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

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

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