Моя установка Discourse устарела (3.2.0.beta4-dev), и мне нужно обновиться до версии 3.5. Я беспокоюсь, что что-то сломается, так как использую несколько плагинов и интеграций, которые не хочу менять (WP Discourse, вход через WordPress с информацией о членстве и плагин Category Lockdown), а в прошлом у меня были проблемы с ручным обновлением.
Какой лучший подход к обновлению? Стоит ли сначала выполнить частичное обновление до другой версии? Есть ли какие-то подводные камни, о которых мне следует знать?
Это имеет несколько полезных побочных эффектов: вы убедитесь, что у вас есть актуальная резервная копия и её безопасная копия. Однако, какой бы метод обновления вы ни выбрали, эти действия необходимо выполнить.
У меня сложилось впечатление, что хорошей практикой будет закомментировать все ваши плагины, но было бы хорошо, если бы кто-то это подтвердил.
Да. На самом деле, знание того, что можно запустить новый сервер и восстановить резервную копию, очень важно. Недавно мне пришлось это сделать, когда на одном из моих серверов вышел из строя SSD-диск. Я хотел бы, чтобы я заранее потренировался (хотя, как оказалось, хотя я не проводил специальных учений, многократное прохождение процесса сотни раз было достаточно, и всё прошло по плану).
В этом нет никаких недостатков, особенно учитывая, что множество плагинов были перенесены в ядро, и какие-то старые могут быть неработоспособны. После того как система будет приведена в рабочее состояние, вы сможете восстановить любые отсутствующие плагины, которые заметите.
Лучшая практика? Храните чек-лист в удобном месте. Вы можете добавить его в интерфейсе UI > админ > обновление, добавив этот CSS в вашу тему (../admin/customize/themes/ edit > css), если когда-нибудь вы или кто-то другой решите обновиться слишком быстро:
.admin-contents.update .d-nav-submenu::before {content: "Чек-лист обновления: Резервное копирование выполнено?" ; "Опубликовано ли объявление Meta за последний месяц?" ; "Проверены ли самые важные баги Meta за прошлый месяц?" ; "Проверена ли совместимость критических плагинов?" ; "Проверена ли совместимость версий Postgres/Redis?" ; "Проверено ли подходящее время для обновления?" ; "Проверено ли наличие рабочей силы для устранения неполадок в случае сбоя обновления?" }
Чек-листы — это хорошая идея. Что касается меня, то, планируя обновление, я жду выхода релиза, даю ему пару дней, выбираю будний день, читаю разделы «Баги» и «Поддержка», чтобы узнать, с какими проблемами сталкиваются пользователи. И жду, пока эти проблемы, если они есть, будут исправлены.
Нет, я на ветке tests-passed. Действительно, моя задержка в несколько дней позволит добавить в репозиторий несколько случайных дополнительных коммитов, но в то же время это даст возможность исправить некоторые ошибки. Конечно, почти все коммиты не вызывают проблем, поэтому я считаю это хорошим компромиссом, хотя мнения могут различаться.
Сразу после выхода новой бета-версии часто происходит всплеск обновлений, поэтому даже если тесты пройдены, лучше подождать несколько дней после выхода обновления, прежде чем устанавливать его. Или, возможно, мы оба придерживаемся одной и той же ошибочной логики!
Думаю, вы увидите что-то вроде процента коммитов, связанных с исправлением багов (не уверен, как это количественно оценить — может, просто посчитать те, где в сообщении коммита есть «FIX»), за 5 дней после релиза и сравнить с процентом за остальное время.
Построение графика оставляю в качестве упражнения для читателя.
