Лучшая практика для проекта Sitecore

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

Какой был бы лучший подход для запуска проекта Sitecore? Как бы вы настроили свой проект? Каким будет ваш подход к переработке кода в будущих проектах?

Вкратце: какой опыт у вас есть (если вы работали или работаете над проектами Sitecore) и как вы порекомендуете другим людям работать с Sitecore.

Сейчас мы заняты созданием блоков Sitecore, которые мы можем просто перерабатывать в других проектах, но я точно знаю, что есть 1001 полезные советы и трюки. Надеюсь, у нас есть один Sitecore pro @stackoverflow, который может немного помочь.

ОТВЕТЫ

Ответ 1

Это, как вы сказали, довольно большой вопрос. Вот некоторые из моих мыслей:

Разработка среды

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

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

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

Я добавляю zip файл в subversion, а также добавляю все файлы, которые, я думаю, будут изменены во время проекта, обычно я говорю subversion, чтобы игнорировать папку sitecore, это ускоряет производительность при проверке файлов.

После выполнения действия фиксации другие члены моей команды могут проверить код и начать разработку (после распаковки zip файла, вне курса)

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

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

Часто мы настраиваем автоматизированный сервер сборки, но это еще одна проблема.

Многоразовый код и рендеринг

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

Загрузка кода клиенту

Это делается через пакеты sitecore, обычно с каким-то динамическим выбором для включения файлов, скажем, все ascx файлы в определенной папке меняли последние 5 дней.

Там у вас есть.

Ответ 2

Вот общая информация об установке, основанная на том, как мы это делаем.

Subversion Это не Sitecore, но мы создали наш репозиторий, подобный этому

  • ветки. Это используется для работы с большими обновлениями на сайте, которые могут занять некоторое время. Скажем, например, я хотел обновить, как все боковые панели на сайте работали, и это займет несколько недель. Мы создаем новую ветку и настраиваем еще один экземпляр sitecore для этой ветки dev и делаем то, что нам нужно делать. Когда он будет завершен, мы объединим его обратно в багажник для тестирования и развертывания.
  • теги. Это используется для хранения копии кода, которая никогда не будет объединена обратно в соединительную линию (это разница между этим и ветвями), например, когда мы развертываем обновление до на сайте мы можем создать тег указанного кода, чтобы мы могли вернуться к нему, если это необходимо.
  • trunk. Активный код, все, что здесь указано, всегда должно быть развертываемым.

Багажник Именно здесь мы активно разрабатываем/исправляем ошибки, в зависимости от того, в какой части проекта мы находимся. Мы установили что-то вроде этого (в качестве примера проект называется TheProject)

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

  • docs. Место для размещения документации по сайту. Я настоятельно рекомендую, чтобы при заполнении функций/разделов вы пишете небольшое руководство о любых специальных знаниях, необходимых для его работы. Поэтому скажите, что я работаю над отображаемым содержимым на целевой странице. Этот блок автоматически вытащит некоторый контент, если он явно не переопределен. Что я делаю, когда я заканчиваю что-то вроде этого, я пишу руководство для клиента, используя множество скриншотов. Я отправляю руководство клиенту, а также помещаю его в папку документов. Это помогает клиенту обучать своих сотрудников, а также помогает новым разработчикам быстро справляться с тем, как это делается.
  • lib. Здесь мы храним любые DLL, которые нам понадобятся для ссылок в наших проектах.
  • test - место для тестирования модулей.
  • src. Здесь мы храним код библиотеки для конкретного проекта. Итак, у нас будет папка TheProject.Library, и в ней будет проект визуальной студии для упомянутых
  • web/Веб-сайт. Здесь мы установили Sitecore и являемся корнем сайта. Здесь у нас есть проект, называемый чем-то по строкам TheProject.Web. В проекте мы добавляем все общие вещи, такие как папка web.config/layouts и т.д.

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

Итак, когда мы закончили со всем этим, у нас есть что-то вроде структуры решения/проекта

TheProject (Решение)

  • TheProject.Library
  • TheProject.Web
  • MyCompany.SitecoreLibrary(наша общая библиотека sitecore)

Инструменты Это еще одна общая вещь, но я считаю, что это может действительно помочь ускорить разработку Sitecore. Если вы обнаружите, что делаете что-то снова и снова в Sitecore, используя API, напишите инструмент, чтобы сделать это за вас. Это не только помогает решить любую проблему, которую вы решаете, но также помогает вам лучше ознакомиться с API.

Resharper Это скорее общее предложение .NET для разработки, используйте Resharper (http://www.jetbrains.com/resharper/index.html). Я своего рода ребята-рехарпера, он делает так много вещей с развитием проще и быстрее. На мой взгляд, самое большое преимущество заключается в том, насколько легко он делает код рефакторинга, что очень важно делать со временем, чтобы вещи были чистыми и понятными.

Я надеюсь, что это поможет.

Гейб

Ответ 3

Посмотрите эту серию.

В частности, часть архитектуры компонентов увеличила наш уровень повторного использования.

Ответ 4

При создании проекта Visual Studio в корневой папке Sitecore вы будете хранить все файлы DLL Sitecore внутри каталога bin, не забудьте добавить к проектам ссылки на все эти файлы:

bin\ComponentArt.Web.UI.dll
bin\HtmlAgilityPack.dll
bin\ITHit.WebDAV.Server.dll
bin\Lucene.Net.dll
bin\Mvp.Xml.dll
bin\Newtonsoft.Json.dll
bin\RadEditor.Net2.dll
bin\Sitecore.Kernel.dll
bin\Sitecore.Logging.dll
bin\Sitecore.NVelocity.dll
bin\Sitecore.Zip.dll

Потому что, когда вы очищаете свой проект, и у вас будет только ссылка Sitecore.Kernel.dll(в большинстве случаев), вы потеряете большую часть DLL из каталога bin!!