Как создавать версии ресурсов, которые совместно используются проектами

Question

Мы используем Team Foundation Server и имеем множество проектов веб-приложений ASP.NET. Каждое из веб-приложений использует собственную систему управления контентом, которую мы разработали самостоятельно. CMS - это веб-приложение ASP.NET.

При развертывании CMS находится в подкаталоге, например "/ Admin". CMS состоит из файлов .aspx и ascx, и соответствующие сборки, конечно же, помещаются в корзину.

В настоящее время файлы CMS существуют отдельно для каждого веб-приложения в системе контроля версий. Другими словами, папка «Admin» существует в каждом веб-приложении, которое зависит от CMS. Это создает очевидные проблемы, поскольку обновления CMS должны распространяться на каждый зависимый сайт. Моя задача - автоматизировать / упростить процесс.

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

Звучит так, что № 2 (из бамбука) - это решение, которое я ищу. Учитывая, что общий код уже находится в каждом отдельном проекте, не могли бы вы кратко описать процесс, который я прохожу в «Разветвлении / Совместном использовании» CMS? Кроме того, стоит отметить, что я не хочу, чтобы файлы .cs распространялись в зависимые проекты, только разметка и сборки. Меняет ли это стратегию? Должен ли я сначала создать событие сборки в общем проекте, чтобы скопировать необходимые файлы в папку «Release», а затем разветвить папку Release?

Answer 1

Это пара популярных способов справиться с этим сценарием.

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

2. Разветвление / совместное использование общего содержимого в каждом дереве контроля версий приложений. Это легко сделать в TFS. Это действительно хорошо, если каждая команда / приложение хочет контролировать, когда они получают последние из общего материала. Это позволяет командам делать свое дело до тех пор, пока они не будут готовы интегрировать общий контент.

Я обычно всегда предпочитаю # 2. Но это действительно зависит от специфики того, как вы хотите / хотите работать.

Answer 2

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

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

Все наши проекты, включая Shared, имеют 4 ветви: разработка, интеграция, подготовка и производство. Поэтому, когда нам нужно внести изменения в нашу общую библиотеку, и мы делаем это в ее ветви разработки, потому что она изолирована. Как только мы счастливы, мы объединяем наши изменения в интеграцию. Мы создаем совместную интеграцию, а затем мы создаем то, что когда-либо затрагивает проекты. Это когда мы начинаем тестировать другие приложения, чтобы увидеть, не вызвали ли наши изменения какие-либо ошибки. Итак ...

1. Одно место для внесения изменений в общую библиотеку
2. Слияние с одной веткой, а не с несколькими ветвями в каждом проекте.
3. Использовать Shared так же просто, как добавить ссылку
4. Один проект и версия Shared могут быть переведены из разработки в производство, не затрагивая другие проекты. Версия .dll Shared копируется в папку bin проектов. После внесения изменений в другой проект он получит самую последнюю версию, когда его проталкивают через ветви.

Answer 3

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

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

Если у вас нет источника для общих частей, скорее всего, установка кода в GAC станет вашим единственным вариантом для создания общей части.