Sitecore лучшие практики - PullRequest
6 голосов
/ 06 августа 2009

Мы настраиваем нашу первую миграцию на Sitecore. У нас есть несколько многоязычных сайтов с контентом, хранящимся в полях базы данных с LCID. Пользовательские элементы управления выполняют вызовы из базы данных для отображения контента на разных языках. Мы переносим наш контент в элементы Sitecore и хотели бы использовать API Sitecore для получения контента из наших пользовательских элементов управления для построения структур данных.

Я хотел бы знать, как структурировать проекты Visual Studio для разработки Sitecore, чтобы использовать существующие решения VS. Дублируем ли мы файлы и конфигурации Sitecore .dll всем решениям или используем одну установку Sitecore?

Кроме того, как вы устанавливаете необходимые файлы в производстве для поддержки нескольких сайтов, которые существуют как отдельные сайты в IIS? Нужно ли нам иметь дубликаты всех необходимых DLL-файлов и файлов конфигурации в отдельной папке /sitecore для каждого веб-сайта, или мы совместно используем одну папку с виртуальной папкой на каждом сайте, указывая на одну и ту же физическую папку /sitecore?

Ответы [ 5 ]

6 голосов
/ 03 августа 2011

По моему опыту, «все под 1 веб-сайтом IIS» для нескольких сайтов с Sitecore работает только тогда, когда у вас нет следующего:

  1. Различные SSL-сертификаты на сайт : IIS разрешает только один SSL-сертификат на комбинацию IP-адрес / порт и только один на веб-сайт в IIS. У нас есть 4 разных сертификата SSL с подстановочными знаками (для 4 разных базовых доменов), поэтому у нас должно быть как минимум 4 отдельных веб-сайта IIS.
  2. Различные виртуальные каталоги для сайта : если вы хотите, чтобы виртуальный каталог был доступен на одном сайте, но не на другом, вам нужно иметь разные сайты в IIS.

Если у вас есть какое-либо из этих требований, это должны быть разные веб-сайты в IIS (или требования должны обрабатываться вне IIS).

Что касается того, как вы это настраиваете, следует иметь в виду, что нам сказали, что для нескольких установок Sitecore на сервере требуется другая / несколько лицензий.

Поэтому для нас нам пришлось использовать одну и ту же установку для нескольких сайтов в IIS, поскольку у нас были оба эти требования (и только одна лицензия). У всех сайтов была одна и та же установка Sitecore (все общие файлы, включая DLL и web.config). Недостатки:

  • что любые изменения конфигурации или DLL вызывают перезапуски для всех сайтов
  • что каждый веб-сайт имеет свой собственный домен приложения (таким образом, он увеличивает требования к памяти, а кэш в памяти не используется совместно)
  • этот домен приложения представляет собой отдельный процесс, поэтому любое обслуживание или запланированная операция (т. Е. Очистка медиа-кэша) выполняется на каждом веб-сайте и обращается к одним и тем же файлам. Это может вызвать проблемы с производительностью и параллелизмом. Нам пришлось запустить некоторые из этих процессов из задач, запланированных извне, и только на нашем сайте редактирования, чтобы предотвратить конфликты.
  • , поскольку у нас есть только один конфигурационный файл, мы не можем отключить функции редактирования для веб-сайтов доставки контента. Это означает, что нам пришлось использовать функции IIS для предотвращения редактирования на веб-сайтах доставки контента.
  • мы должны были воспринимать это как многосерверную установку sitecore, что означало, что нам нужно было настроить stager для очистки кэша при публикации. мы использовали stager, доступный в Shared Source Library.
4 голосов
/ 13 августа 2009

В общем, мы рекомендуем запускать все под 1 веб-сайтом IIS. Это экономит много проблем конфигурации и развертывания. Кроме того, использование нескольких веб-сайтов не является целесообразным.

Настройки проектов можно сделать довольно просто. Просто убедитесь, что цели сборки установлены в / Website / bin-папке установки Sitecore. Если это так, вы можете использовать все что угодно. Вы можете связать Sitecore.Kernel как элемент решения в Visual Studio.

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

2 голосов
/ 26 ноября 2016
  • Вы должны начать с пустого решения веб-приложения без файлов / sitecore вообще. Если вам нужно добавить файл или изменить файл sitcore, создайте структуру папок в своем проекте, чтобы при развертывании он перезаписывал существующий файл sitecore.
  • Все изменения конфигурации Sitecore должны быть в решении, в папке / App_Confif / Include / z_ [Client].
  • Все ваши dll для Sitecore должны поступать с официального сайта sitecore Лента NuGet , где вы указываете версию sitecore, не используя «последний» в NuGet.
  • Ваш web.config должен быть готовым к использованию Sitecore web.config и использовать преобразования, чтобы превратить web.config в то, что нужно в сборке.
  • Вы должны разработать в соответствии с Руководствами Helix для структуры вашего проекта.
  • Все изменения элемента Sitecore должны отслеживаться при выборе программного обеспечения для сериализации. Будь то TDS или Единорог .

Мой лакмусовый бумажник - могу ли я создать сайт с помощью инструмента Sim и развернуть код и элементы проекта, работает ли мой сайт? В некоторых ситуациях мы извлекаем содержимое производства / этапа из Sitecore с помощью PowerShell , копируем пакет на сервер Nuget и разворачиваем его для разработки / CI с PowerShell.

Для создания сайта я использовал инструменты Sim с командной строкой или этот скрипт Powershell .

Вы не одиноки в своем разочаровании. Я столкнулся с несколькими клиентами, у которых есть более подходящий сайт Sitecore в своем решении. Развертывания и обновления всегда очень сложны. Но если вы разрабатываете решение, которое не содержит реальных файлов Sitecore и может быть развернуто на пустом сайте с помощью CI. Тогда вы будете в отличной форме.

1 голос
/ 14 декабря 2017

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

1. Как структурировать проект Sitecore

Я работаю разработчиком sitecore уже более 3 лет. Исходя из моего опыта, лучшая практика - это создать один проект Sitecore, который является высшим уровнем вашего решения. Вам не нужно устанавливать dll-файлы sitecore для всего проекта, просто сохраните старый код как есть и включите его в базовый код. Например, я только что закончил проект, в который клиент хочет перейти, используя Sitecore, решение уже было, оно имеет 4 проекта:

  1. ABC.Web ==> самый высокий слой
  2. ABC.Data ==> работа со слоем данных
  3. ABC.Services => уровень бизнес-обработки
  4. ABC.Domain ==> Общий слой

Мы создали новый проект, который должен установить dll Sitecore, который на самом деле заменит ABC.Web (самый высокий уровень), который будет содержать весь код Sitecore MVC и ничего не заменит на старый код. С этого момента мы можем работать как с данными из старой системы (ссылаясь на библиотеки ABC.Services), так и с Sitecore.

2. Как установить необходимые файлы в производство для поддержки нескольких сайтов?

Sitecore поддерживает мультисайты, структурируя дерево контента Sitecore и конфигурацию litte. Вам НЕ ТРЕБУЕТСЯ создавать отдельные сайты в IIS, на самом деле это ОДИН сайт с разными доменами. В файле конфигурации с именем SiteDefinition.config (или вы можете добавить свой собственный файл конфигурации) вы в основном задаете домен с начальным элементом. Sitecore распознает домен, который совпадает с доменом в файле конфигурации, и перенаправляет на начальный элемент соответственно. Например. В изображении я создал 2 сайта (по сути, это 2 ветви дерева контента sitecore) с начальными элементами (MySite1 и MySite2)

enter image description here

это мой конфиг

<sites>
      <site name="MySite1" patch:before="site[@name='website']"
            virtualFolder="/"
            physicalFolder="/"
            rootPath="/sitecore/content"
            startItem="/content/MySite1/home"
            database="web"
            domain="extranet"
            allowDebug="true"
            cacheHtml="true"
            htmlCacheSize="50MB"
            enablePreview="true"
            enableWebEdit="true"
            enableDebugger="true"
            disableClientData="false"/>
       <site name="MySite2" patch:before="site[@name='website']"
            virtualFolder="/"
            physicalFolder="/"
            rootPath="/sitecore/content"
            startItem="/content/MySite2/home"
            database="web"
            domain="extranet"
            allowDebug="true"
            cacheHtml="true"
            htmlCacheSize="50MB"
            enablePreview="true"
            enableWebEdit="true"
            enableDebugger="true"
            disableClientData="false"/>
    </sites>

Вы можете обратиться к этому руководству для более подробной информации

https://briancaos.wordpress.com/2010/03/01/working-with-multiple-sites-in-sitecore/

1 голос
/ 12 января 2017

На вопрос № 2:

Мы используем Руководящие принципы Helix / Habitat , Похоже, это источник наилучшей практики Sitecore. Все обучение sitecore предполагает создание проекта вне Sitecore и импорт только тех вещей, которые вам нужны. Для конфигурации я бы посоветовал быстро прочитать this

Это правда о SSL, и пулы приложений могут стать проблемой. Развертывание на сайте одного клиента обрушит все, в зависимости от настроек.

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

...