A Git Стратегия управления источником для живого веб-сайта Sitecore

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

Мне дана монументальная задача пересмотреть процедуры управления рисками моей компании в отношении нашей онлайн-работы.

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

Мы запускаем веб-сайт ASP.NET с бэкэнд SQL Server 2005, работаем с Sitecore в качестве нашей CMS. В идеальном мире я бы хотел, чтобы все изменяющиеся части этого сайта CMS находились под контролем источника, включая базу данных.

На данный момент, и я знаю, что это не самая лучшая идея, я запускаю одно решение для всех подрайонов, построенных в Sitecore. Это находится под контролем источника, и благодаря Git мне удалось добавить ветки и нажимать новые функции и легко исправить ошибки (используя Git -flow как мое решение для рабочего процесса). Я все еще новичок в Git, поэтому мне не удалось что-то слишком сложное за пределами фиксации, игнорируя определенные файлы и т.д.

Кроме того, я также хотел бы использовать элемент управления источником, чтобы получить содержимое базы данных под контролем источника. Насколько я понимаю, вы можете сериализовать элементы контента Sitecore как огромное дерево в файловой системе (сохранено как .item файлы, если я правильно помню?). Если это идеальное решение, я также хотел бы добавить их в исходный элемент управления, хотя я точно не знаю, где они будут сохранены в файловой системе. Моя файловая система сейчас выглядит следующим образом:

- Data      (Logs, indexes, etc - is this needed to be in source control?)
- Source    (Helper files, although occasionally modified)
- Website   (Containing all the files I edit, and other essential Sitecore stuff)

Как уже упоминалось, мой текущий репозиторий работает только в моей системе и состоит из одной папки с папкой с .ascx,.ascx.cs,.ascx.cs.designer и нечетным .aspx файлом или двумя. Это, как правило, облегчает мою жизнь при загрузке, например, с помощью

То, что я хотел бы вводить, - это идеальный способ управления этим для всех разработчиков. Несмотря на использование DVCS, я предпочел бы, чтобы живой сервер рассматривался как основной репозиторий, а для всех остальных разработчиков - отталкиваться от него и друг от друга. Мы будем использовать git -flow workflow solution, так как он хорошо соответствует нашему способу развития. Очевидно, я беспокоюсь о том, что это правильно, без разрушения того, что в настоящее время является очень дорогим сайтом с высоким трафиком на сервере без резервного копирования.

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

EDIT: я собираюсь пожертвовать этим, чтобы попытаться получить больше руководств о том, как люди обрабатывают Sitecore с помощью Git.

Чтобы прояснить себя, я НЕ ищу способ создать резервную копию моей работы, а не так, чтобы ряд разработчиков могли работать над ней и убедиться, что код на веб-сайте обновлен с помощью центрального репозитория. Например, я уже упоминал, что я буду использовать Git -flow для управления моим рабочим процессом. Репозиторий происхождения будет существовать на общем сервере (который, скорее всего, будет тестовой средой), и все разработчики будут иметь клоны того, над чем работать и нажимать. Отсюда я хочу, чтобы удалять изменения с исходного репо на общем диске на живой сервер и обратно, если обнаружены ошибки. Я также хотел бы включить сериализованные элементы контента в свое репо.

Ответ 1

Пересмотренный ответ после пересмотренного вопроса:

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

Что делать, если у вас было несколько репозиториев на одном сервере с Live Sitecore? Если вы можете настроить Sitecore для использования разных корней/репозиториев в одной и той же файловой системе, например. вы меняете URL-адрес на http://yoursite.com/blahblah/test для запуска Sitecore в тестовом режиме. Это зависит от того, какую лицензию у вас есть, т.е. Если она привязана к конкретной машине. В любом случае, таким образом, вы можете протестировать свой сайт на другой ветке (например, ветку разработки в тестовом репозитории), прежде чем объединить материал в мастер и позволить ему работать вживую.

Итак, у вас может быть голый репозиторий на сервере, где все нажимают и тянут. И вы могли бы иметь два дополнительных не голых репозитория на одном сервере, один из которых был отмечен мастер-веткой, а другой - с ветвью разработки. При входе через ssh вы можете легко запустить "git pull" в тестовом репозитории, если вы хотите протестировать новые функции тестовой версии вашего сайта Sitecore. Когда вы довольны изменениями, объединитесь в мастер и нажмите, чтобы овладеть своим голой репо и обновите live-репо таким же образом.

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

Оригинальное сообщение:

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

Я также рекомендую вам делать резервные копии данных для центрального репозитория, другими словами, git следует использовать как систему управления версиями, а не как систему резервного копирования. Даже git может выйти из строя и вызвать поврежденные репозитории, а затем вы курите, если у вас нет резервных копий.

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

Ответ 2

Отъезд HedgeHog Team Development Soultions (3.0 - последняя версия). Он удовлетворяет многие из вас при использовании с Visual Studio, Sitecore Rocks, Team City (или другим сервером сборки). Подробнее см. http://hhogdev.com/.

Ответ 3

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

Хранение данных не дорого. На самом деле это не так. Даже когда у вас огромный набор данных. И поэтому, требуя, чтобы все разработчики использовали git, это хорошая идея. Многие организации создали один сервер git, и вы просто нажимаете/тянете на этот сервер. Если ваше решение имеет хорошие и полные тесты, вы будете очень быстро узнавать, если слияние кода нарушит программное обеспечение. Если нет, вы, вероятно, должны использовать центральный сервер git для разработчиков для push/pull, а затем отдельный сервер интеграции выпуска, который использует "git fetch" для слияния и тестирования изменений с центрального сервера.

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

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

Ответ 4

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

Настройте благословенное голое репо на ящике Linux (физическое или виртуальное, не имеет значения).
Инициализировать репо git в рабочей среде, в базовой папке, где все исходный код, файлы конфигурации и данные могут быть добавлены в репо. (Не забудьте установить user.name и user.email, которые будут идентифицировать sysadmin, заботясь о производственных обновлениях.)
Создайте файл дампа SQL Server для каждой схемы и поместите все дампы в специально выделенную папку внутри локального производственного репо.
Сформируйте все файлы (git add --all) и зафиксируйте с комментарием "Первоначальная фиксация, версия X.Y.Z", где номер версии - это то, что вы считаете текущим развертыванием.
Нажмите на благословенное репо.
Клонировать благословенное репо во всех средах разработчиков. (Снова не забудьте указать user.name и user.email для правильной идентификации в commits.)
Начать использование git -flow.

Обратите внимание на шаг 3, где дампы SQL Server создаются и добавляются в репо. Это позволит вам откатить любые будущие изменения в базе данных. Имейте в виду, что вам нужно будет генерировать новые дампы каждый раз, когда вы вносите изменения, но только для фактически измененных схем. Сериализуйте то, что вам нужно для сериализации, и передайте новые сериализации вместе с изменениями схемы. Таким образом, git revert {commit_hash} - это все, что вам нужно, чтобы вернуть те конкретные изменения (без забывания восстановить базу данных, конечно).

Я надеюсь, что это поможет, прямо или косвенно.

P.S: Я не знаю вашу структуру базы данных; если конфигурации хранятся в той же схеме, что и пользовательские данные, это определенно усложняет ситуацию, поскольку вы не можете просто восстановить предыдущий дамп без потери новых (и предположительно важных) пользовательских данных. Я привык к Ruby on Rails, где изменения схемы кодируются как для повышения, так и для понижения; Я надеюсь, что ваша инфраструктура обеспечивает аналогичную функцию.