Проект TFS с несколькими решениями Visual Studio

Ответ 1

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

Вы используете два командных проекта, когда есть две команды совершенно разных людей, работающие над совершенно другим проектом, с совершенно другой методологией/процессом.

С одним Team Project вы все еще можете:

• Имейте много ветвей (связанных или нет).
• Имейте управление Source Control на минимальном уровне, который вам нужен.
• Разделите свой проект на подкатегории (функциональные, технические, независимо от того, что вам нужно), используя путь области (который является деревом node) рабочего элемента. Таким образом, у вас может быть один большой продукт или специализированные.
• Общие отчеты по всему вашему проекту или по конкретной области (по-прежнему используя Area Path, но в службах Reporting Services)
• Поверьте мне, что это лучший способ пойти, и многие люди (включая меня в первый раз) ошибаются, используя несколько Team Project, и после этого им придется заплатить цену. Вам нужна хорошая иерархическая структура Source Control и хорошее дерево пути.

Относительно решений:

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

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

Проблема здесь о ссылках на перекрестные компоненты, если один компонент, который вы разрабатываете (например, Application1), нуждается в другом компоненте, который вы разрабатываете (например, OurCompanyLibrary), тогда он создает зависимость между ними, и Application1 должен ссылаться на "встроенные сборок" нашей Библиотеки.

Это подразумевает:

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

• Воспользуйтесь новым стандартом Nuget и настройте собственный сервер Nuget (очень легко сделать) и создайте собственный Nuget пакеты для компонентов, на которые будут ссылаться другие.

• Самый простой способ - включить все ваши зависимости, разработанные внутри компании в решении, чтобы убедиться, что они построены, когда это необходимо. Это легко сделать, но ваш проект Application1 будет включать большинство ваших проектов VS. Я не говорю, что это хороший или плохой способ пойти, это ваш звонок. Когда-то простой способ - лучший.

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

Ответ 2

Как вы это предсказывали: -

OurCompanyLibrary будет решением VS.

OurCompanyLibrary.Application1... OurCompanyLibrary.ApplicationN будет VS-проектами в этом решении.

OurCompanyLibrary.ApplicationX.dlls будут ссылками в решениях OurCompanyIntranet и OurCompanyInternet VS.

Я не уверен, что понимаю вашу проблему.

Проект VS VS в нашей библиотеке будет раздельно строиться, создавая собственную dll, на которую можно было бы ссылаться в двух других решениях. Если проблема связана со всеми приложениями в рамках проекта VS Team Project (OurCompanyLibrary), то ответ будет заключаться в создании отдельного VS Team Project для каждого приложения - OurCompanyLibrary1 для Application1, OurCompanyLibrary2 для Application2 и т.д. Разработка каждого Приложения затем полностью автономна и отделена от других.

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

Я не знаю, поможет ли это вам, но удачи с ним!

Ответ 3

Если это приложение, которое при запуске в productionciton внесет минимальные изменения в структуру папки/решения. В TFS в определении сборки вы можете выбрать несколько проектов или вы также можете поместить несколько решений в сборку script, как в приведенном ниже примере

Как создать 2 решения из одного определения сборки команды TFS

Ответ 4

Если вы хотите иметь централизованную отчетность для всей базы кода, вы должны изучить возможность использования one TeamProject для размещения всего.
Чтобы затем провести различие между различными компонентами/частями вы можете использовать отдельные области внутри этого TeamProject.
this очень интересная статья, особенно раздел "Плюсы/минусы".