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

Question

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

У нас есть решения для различных частей наших приложений: общая библиотека, библиотеки приложений (бизнес-правила и т. Д.), Веб-сайт интрасети, интернет-сайт, 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) 

Причина разделение кода на нескольких решений, потому что мы можем использовать библиотеки приложений в различных ситуациях (интранет-приложения, интернет-приложения, 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? Есть ли другой способ организовать нашу структуру кода, которая будет иметь больше смысла? Любые статьи или веб-сайты, которые приведут нас в правильном направлении, очень помогут.

Answer 1

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

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

С одной команды проекта вы можете еще:

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

Что касается решения:

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

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

Вопрос здесь о ссылках поперечных компонент, если один компонент вы разрабатываете (например Application1) необходим еще один компонент, вы разрабатываете (например, OurCompanyLibrary), то это создает зависимость между обоими и Application1 должны ссылаться на «встроенные сборки» из OurCompanyLibrary ,

Что означает либо:

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

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

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

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

Answer 2

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

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

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

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

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

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

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

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

Answer 3

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

How to build 2 solutions from a single TFS team build definition

Answer 4

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