Стратегия Git Source Control для живого сайта Sitecore

Question

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

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

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

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

---

РЕДАКТИРОВАТЬ: Я собираюсь назначить награду за это, чтобы попытаться получить больше руководств о том, как люди обрабатывают Sitecore с Git.

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

Answer 1

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

Answer 2

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

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

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

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

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

---

Оригинальный пост:

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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