Один Codebase несколько сайтов

Question

Мы разработали систему, которая использует единую кодовую базу, состоящую из четырех проектов Visual Studio с веб-сайтом администратора и веб-сайтом, ориентированным на клиента (каждая система имеет свою собственную базу данных MS SQL).

Это прекрасно работает, так как все новые веб-сайты (включая администраторов) ссылаются на одни и те же проекты кодовой базы из SVN, поэтому любые изменения, внесенные в кодовую базу, будут доступны для всех веб-сайтов.

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

Проблема, с которой мы сталкиваемся сейчас, заключается в том, что если есть ошибка, изменение функции или новая функция, мы должны внедрить ее на ВСЕХ сайтах отдельно (как для администратора, так и для сайта клиента). Это начинает сводить нас с ума, а также означает, что мы имеем ОГРОМНУЮ погрешность для реализации изменений.

Я думал об использовании svn: externals, но это станет грязным.

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

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

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

EDIT

Какие моменты вы хотели бы прояснить?

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

Так что мне нужно будет «синхронизировать» файл и папку, например, найденные в app_code, но и здесь есть проблемы.

Сайт 1 и Сайт 2 могут быть совершенно одинаковыми, просто разные темы. У сайта 3 есть и другая тема, но он также имеет некоторый специальный код, который требуется только этому сайту, часть кода в app_code также действует по-разному для сайта 1 и сайта 2

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

Объединение также стало бы большой задачей и заняло бы слишком много времени, поскольку нам нужно было бы объединять только определенные папки и файлы, хотя вы не можете объединить один файл через ветвь (это может быть неправильно).

Например:

В корне есть файл download.aspx, который возвращает поток как ответ, а не страницу, он используется для проталкивания всех запросов на загрузку через систему.

Таким образом, эта страница на Сайте 1 и Сайте 2 одинакова, но на Сайте 3 она делает что-то дополнительное, чего не требуется или не требуется ни одному другому сайту.

Мы не хотим, чтобы эта сделанная на заказ функция была перегрузкой, поскольку мы не хотим / не нуждаемся в ней для других веб-сайтов, теперь мы больше не можем объединять этот файл с основного веб-сайта, его необходимо объединить вручную.

Надеюсь, это лучше объясняет то, чего я пытаюсь достичь.

РЕДАКТИРОВАТЬ 2

Базовая структура сайта

|- App_code
|- App_Themes
|- Bin
|- Content
|     |- Flash
|     |- Images
|     |- Scripts
|     |- Uploaded
|
|- Controls
|     |- MasterPage
|     |     |-MasterPageControls
|     |
|     |- Navigation
|     |- Search
|     |- Templates
|     |     |- Control Templates 
|     |     |- Page Templates
|     |
|     |- WebServices
|     
|- Errors
|

Все, что находится под управлением Navigation, Search, Templates - это файлы .ascx.

В корне есть несколько файлов, включая default.aspx, download.aspx и preview.aspx

Это главные страницы сайта (без учета страниц ошибок), все страницы динамически создаются из БД.

В папке Controls большинство изменений между веб-сайтами происходит в MasterPage и во всех других пользовательских элементах управления.

Answer 1

Я столкнулся с этой проблемой несколько месяцев назад, когда мы начали значительную переписку нашего веб-приложения. У нас было две отдельные версии почти идентичных сайтов. Внутренний код был идентичен на 99%, в то время как JavaScript, CSS и другие внешние элементы сильно отличались. У нас были эти два сайта в отдельных стволах в одном и том же репозитории SVN, и вскоре это стало кошмаром копирования и вставки общего кода между ними. Исправление и объединение было слишком болезненным, чтобы быть полезным из-за небольших изменений в файлах.

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

Каждый сайт получает уникальное имя (скажем, «foo» и «bar»), которое извлекается из файла Web.config во время выполнения. Имя используется для определения того, какой файл конфигурации загружен и какие файлы на стороне клиента использовать. Параметр пуст в SVN. Он устанавливается нашими сценариями развертывания при копировании на веб-серверы. На наших локальных машинах разработки переменная окружения определяет сайт, с которым мы хотим работать.

Файловая структура файлов, специфичных для сайта, будет выглядеть следующим образом:

|- Config
|     |- AppSettings.foo.config      <- overrides Web.config AppSettings for "foo" site
|     |- AppSettings.bar.config      <- overrides Web.config AppSettings for "bar" site
|- Content
|     |- CSS
|          |- main.css               <- default CSS file for all sites
|          |- main.foo.css           <- CSS overrides for "foo" site
|     |- Images
|          |- logo.jpg               <- default logo
|          |- logo.foo.jpg           <- logo used if site name is "foo"
|          |- logo.bar.jpg           <- logo used if site name is "bar"

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

Answer 2

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

Теперь я решил (более или менее) проблему.

Что я сделал, так это переместил все изображения в папки «Темы», а также создал подпапки в папках шаблонов и элементов управления, в которых будут размещаться специальные элементы управления. Я уже создал некоторые функции в схеме базы данных, которые помогли мне вместе с этим.

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

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

В совокупности мы нашли решение, поэтому я не уверен, кому присудить очки?

Answer 3

Три мысли в порядке возрастания полезности и усилия:

1) Отмечаем, что «разметка для каждого сайта совершенно разная (кроме административного сайта, который является просто изменением темы), но основы кода одинаковы».

Сколько «кода» вы можете перенести в проект DLL, который становится общим? Если это почти все, то вы можете поддерживать отдельные проекты для каждого из наборов разметки, и они будут использовать библиотеки DLL в качестве ссылки.

Очевидно, что если у вас есть много кода, которого нет в AppCode, это вообще не осуществимо. Если нет, то это может быть быстрый путь к меньшему безумию.

2) Можно ли будет поддерживать хранилище для общего кода с отдельными хранилищами для каждого из сайтов? Затем вам нужно будет создать собственный сценарий развертывания для обработки извлечения исходного кода из правильных репозиториев и помещения его в нужные места.

В зависимости от того, насколько тесно связан код / ​​разметка, это также может оказаться невозможным.

3) Наконец, как насчет перемещения различного кода в базу данных и создания приложения при развертывании?

Очевидно, что это самое сложное, но оно доставит вас туда, куда вы хотите.

Answer 4

Создание сервера непрерывной интеграции . Практика генерации активного кода.

См. 10 советов по интеграции CodeSmith в ваши процессы .

Answer 5

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

Если вы все делаете правильно, вы должны иметь возможность экспортировать / публиковать исходную кодовую базу на любой данный сайт в любое время и не портить вещи. Любые настройки должны оставаться неизменными.

Answer 6

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

Я так понимаю, вы используете svn для распространения нового кода на четыре хоста.

Возможно, ваша кодовая база приближается к точке, в которой общий материал можно с пользой считать библиотекой. С этой точки зрения каждый из четырех веб-сайтов считается приложением, созданным из библиотеки. Если это так, то, возможно, имеет смысл предоставить каждому из четырех приложений свой собственный репозиторий в Subversion. Разработка будет заключаться в том, чтобы отделить общие функции от пользовательских функций, возможно, сделав API-интерфейс в «библиотечном» коде более четким. Затем каждый хост проверяет код библиотеки и свое собственное приложение.

Это близко к тому, что вы думаете?

Answer 7

Вы говорите, что у вас есть один репозиторий SVN с базой кода для всех сайтов. Так что, если я не понимаю, не могли бы вы просто переместить какие-либо общие компоненты в этот репозиторий?

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

Таким образом, эта страница на Сайте 1 и Сайте 2 одинакова, но на Сайте 3 она делает что-то дополнительное, чего не требует ни один другой сайт. Мы не хотим, чтобы эта специальная функция была перегрузкой, поскольку мы не хотим / не нуждаемся в ней для других сайтов

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

Answer 8

Я не уверен, что правильно понимаю вашу ситуацию, но вы можете найти подсказки о том, как поддерживать SVN-репозиторий в Subversion book , в главе 4.

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

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