Несколько сайтов с кодовым кодом

Ответ 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"

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

Ответ 4

Если я правильно понял проблему, у вас есть код для четырех широко похожих сайтов в одном хранилище. У экземпляра веб-сайта есть пользовательские функции. Пунктир в оригинальной публикации, вопрос, выражает озабоченность по поводу того, что "застрял, делая много копий и вложений". В разных точках вы указываете разочарование "слиянием" и "ручным слиянием".

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

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

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

1) Хостинг в "разметке совершенно по-разному для каждого сайта (кроме сайта администратора, который является просто изменением темы), но базы кода одинаковы".

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

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

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

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

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

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

Ответ 8

Я собираюсь начать с благодарности каждому за вклад.

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

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

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

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

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