TFS и совлокальные проекты в нескольких решениях

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

 - = folder, | = Visual Studio Solution
-SVN
   - Internet
      | Ourcompany.com
      | Oursecondcompany.com
   - Intranet
      | UniformOrdering website
      | MessageCenter website
   - Shared
      | ErrorLoggingModule
      | RegularExpressionGenerator
      | Anti-Xss
      | OrgChartModule etc...

Итак..

Решение OurCompany.com в папке Интернета будет иметь проект веб-сайта, а также будет включать проекты ErrorLoggingModule, RegularExpressionGenerator и Anti-Xss из общей папки.

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

Мы предпочитаем иметь ссылку на проект на ссылку .dll, потому что, прежде всего, если нам нужно добавить или исправить функцию в модуле ErrorLoggingModule, работая на веб-сайте OurCompany.com, это прямо там. Кроме того, это позволяет нам создавать каждое решение и видеть, что изменения в общем кодовом сломе нарушают любые другие приложения. Это также хорошо работает на сервере сборки, если я прав.

В SVN нет проблем с этим. SVN и Visual Studio не связаны друг с другом в способе управления источниками TFS. Мы никогда не выяснили, как работать с этим типом структуры в TFS, когда мы его использовали, потому что в TFS проект TFS всегда привязывался к Visual Studio Solution. Репозиторий исходного кода был дочерним элементом проекта TFS, поэтому, если бы мы этого захотели, нам пришлось дублировать общий код в каждом репозитории исходного кода проекта TFS. Как сказал мой коллега, это "ломает каждую известную передовую практику повторного использования кода и простоты". Для нас было достаточно разговора о сделке, и мы переключились на SVN.

Теперь, однако, мы столкнулись с действительно исправлением наших процессов разработки, а управление жизненным циклом приложений TFS довольно близко к тому, что мы хотим, и как мы хотим работать. Наша единственная точка привязки - это проблема с общим кодом.

Мы оцениваем другие коммерческие и с открытым исходным кодом, но поскольку мы уже платим за TFS за наши подписки MSDN, а TFS - это в точности то, что мы хотим, мы бы ДЕЙСТВИТЕЛЬНО хотели найти способ решения этой проблемы,

Кто-нибудь еще сталкивался с этим и придумал решение?

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

Как всегда, я открыт для ответов, таких как "Ты смотришь на все это неправильно, болтливый, ЗДЕСЬ, как это ДОЛЖНО быть сделано.

Ответ 1

Я думаю, здесь есть некоторые недоразумения. Во-первых, вы можете иметь несколько (столько, сколько хотите) решений в одном проекте TFS. Кроме того, один проект Visual Studio может иметь любое количество решений, относящихся к нему.

Во-вторых, какую версию TFS вы используете? 2010 отличается от 2005/08 в том, как он обрабатывает проекты TFS.

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

Я начну с нескольких.

Настройте проект TFS для кода вашей общей библиотеки и другие для каждого вашего обычного проекта. В рамках процесса разработки этой общей библиотеки проверьте завершенные сборки. Затем вставьте эти сборки в любой другой проект TFS, в который вы хотите их использовать. Когда вы выполняете обновление функции или исправляете ошибку в общей библиотеке, просто объедините ветку в любой другой проект TFS, в который вы хотите включить обновления.

Это позволяет делать общие изменения для одного приложения без необходимости нажимать на них все.

Если вы хотите, чтобы один проект TFS содержал все, просто добавьте папки для каждого проекта Visual Studio, который вы хотите. Визуальные студийные решения могут без проблем возвращаться к проектам за пределами их базового дерева. Теперь, когда вы настраиваете такие вещи, как Builds для каждого решения, убедитесь, что вы ограничиваете, какой каталог выдает сервер сборки/часы. Таким образом у вас нет его создания одного из ваших внутренних сайтов, когда изменения были внесены на внешний сайт.

Ответ 2

Записывайте это только в надежде, что когда-нибудь кто-нибудь кому-нибудь поможет, я боюсь, что я слишком поздно, чтобы ответить на ваш первоначальный вопрос;) У нас очень похожая ситуация, и ваш вопрос (и последующие ответы) позволил нам правильно настроить TFS.

Чтобы использовать ваш пример, чтобы объяснить нашу настройку:

# = Project Collection, > = Team Project, | = VS project
# SVN
    > Internet
        | OurCompany
        | OurCompany2
    > Intranet
        | UniformOrdering
        | MessageCentre
    > Shared
        | ErrorLogging
        | RegularExpression

Это означает, что работа может быть назначена (с использованием шаблонов Scrum в Sharepoint) в любой из проектов Team (в нашем случае это приложения SAAS), и разработчик может выбрать, чтобы открыть любой или все проекты VS, чтобы получить работу сделал.

Большинство старших разработчиков (те, которые работают с несколькими продуктами) имеют одно решение VS (возможно, "WholeEnterprise.sln", чтобы продолжить аналогию), которое содержит ВСЕ различные проекты VS и поэтому может работать над любыми/всеми из них в любое время. Мы также можем гарантировать, что проекты будут построены правильно, и все зависимости будут обновлены до нажатия на обновление.

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