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

Question

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

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

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

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

Answer 1

Вот некоторые общие сведения о настройке, основанные на том, как мы работаем.

* 1004 Subversion * Это не зависит от Sitecore, но мы настроили наш репозиторий следующим образом

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

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

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

• документы - место для размещения документации о сайте. Я настоятельно рекомендую, чтобы при заполнении функций / разделов вы писали небольшое руководство о любых специальных знаниях, необходимых для его работы. Скажем, я работаю над блоком рекомендуемого контента на целевой странице. Это поле будет автоматически извлекать некоторый контент, если он явно не переопределен. Когда я выполняю что-то подобное, я пишу руководство для клиента, используя множество скриншотов. Я отправляю руководство клиенту и помещаю его в папку с документами. Это помогает заказчикам обучать своих сотрудников, а также помогает новым разработчикам быстро освоить работу.
• lib - Здесь мы храним любые библиотеки DLL, которые нам понадобятся в наших проектах.
• test - Место для проведения юнит-тестов.
• src - Здесь мы храним код библиотеки нашего проекта. Итак, здесь у нас будет папка с именем TheProject.Library, и там будет проект Visual Studio для указанного
• web / Website - Здесь мы установили 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). Я своего рода фанат Resharper, он делает так много вещей с разработкой проще и быстрее. На мой взгляд, самое большое преимущество - насколько легко это делает рефакторинг кода, что очень важно делать со временем, чтобы вещи были чистыми и понятными.

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

Гейб

Answer 2

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

Развивающая среда

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

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

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

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

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

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

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

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

Код многократного использования и визуализации

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

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

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

Вот, пожалуйста.

Answer 3

Взгляните на этой серии .

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

Answer 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 !!