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

Наша команда рассматривает возможность использования Team Foundation Server v.11 (2012) для управления нашими проектами. В настоящее время мы осуществляем управление проектами в распространенных листах. Наша команда разрабатывает программное обеспечение только для внутренних клиентов, и существует много обмена DLL между проектами. Мы также используем SVN для контроля версий исходного кода.

У нас есть решения для разных частей наших приложений: общая библиотека, библиотеки приложений (бизнес-правила и т.д.), веб-сайт Intranet, интернет-сайт, Windows Forms. Вот как выглядит наша структура SVN

SVN
    -CommonLibrary (VS Solution)
        -Source
            -CommonLibrary.Core (VS Project)
            -CommonLibrary.Security (VS Project)
            -CommonLibrary.Web (VS Project)
    -OurCompanyLibrary (VS Solution)
        -Libraries (Projects within this solution reference these)
            -CommonLibrary.Core.dll
            -CommonLibrary.Security.dll
        -Source
            -OurCompanyLibrary.Application1 (VS Project)
            -...
            -OurCompanyLibrary.ApplicationN (VS Project)
    -OurCompanyIntranet (VS Solution) (MVC framework)
        -Libraries (Projects within this solution reference these)
            -CommonLibrary.Core.dll
            -CommonLibrary.Security.dll
            -CommonLibrary.Web.dll
            -OurCompanyLibrary.Application1.dll
        -Source
            -OurCompanyIntranet.Application1 (VS Class Library Project)
            -...
            -OurCompanyIntranet.ApplicationN (VS Class Library Project)
            OurCompanyIntranet.UI (VS Web Project)
    -OurCompanyInternet (VS Solution) (MVC framework)
        -Libraries (Projects within this solution reference these)
            -CommonLibrary.Core.dll
            -CommonLibrary.Security.dll
            -CommonLibrary.Web.dll
            -OurCompanyLibrary.Application1.dll
        -Source
            -OurCompanyInternet.Application1 (VS Class Library Project)
            -...
            -OurCompanyInternet.ApplicationN (VS Class Library Project)
            -OurCompanyInternet.UI (VS Web Project)

Причина разделения кода на несколько решений заключается в том, что мы можем повторно использовать библиотеки приложений в разных ситуациях (приложения Intranet, интернет-приложения, приложения Winform). Кроме того, интранет и интернет-решения содержат несколько приложений. Это наша нынешняя структура. Я не уверен, что это лучшая организационная структура, но она работает для нас.

Проблема с переключением на TFS заключается в том, что один Team Project не может иметь частей в нескольких решениях VS. Например, мы создали проект Team TFS для Application1, чтобы у нас могло быть отставание продукта для этого приложения. Application1 требует изменений в OurCompanyLibrary, OurCompanyIntranet и OurCompanyInternet для завершения приложения, но с использованием TFS будет только одно решение VS для Application1.

Вот пример того, как мы разрабатываем приложение. Вся модель домена и бизнес-правила, которые мы храним в решении OurCompanyLibrary VS. Когда мы разрабатываем приложение, называем его Application1, мы сначала начинаем создавать модель домена и бизнес-правила в проекте OurCompanyLibrary.Application1 VS в рамках решения OurCompanyLibrary VS. После разработки модели домена мы переходим к программированию интерфейса пользователя в решениях OurCompanyIntranet и OurCompanyInternet VS Solutions. Эти решения являются веб-сайтом в стиле MVC. OurCompanyIntranet содержит VS Web Project OurCompanyIntranet.UI, который содержит все представления (файлы .aspx), css, javasciprt и т.д. OurCompanyIntranet также содержит все модели и контроллеры, разделенные приложением (в данном случае - OurCompanyIntranet.Application1). Организация этого в TFS становится проблемой, потому что нам нужен Team Project для Application1, но это приложение может охватывать несколько решений, и мы не хотим дублировать код везде, добавляя те же решения OurCompanyIntranet и OurCompanyInternet VS к исходному контролю.

Как бы вы организовали это в TFS? Есть ли другой способ организовать нашу структуру кода, которая будет иметь больше смысла? Любые статьи или веб-сайты, которые приведут нас в правильном направлении, очень помогут.

Ответ 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 очень интересная статья, особенно раздел "Плюсы/минусы".