Оновлення інстансу Podorozhnyk до 5.5.6
Короткий операційний огляд для узгодження вікна робіт і відповідальності. Повний технічний план (англійською), покрокові деплої, міграції та прапорці — у репозиторії:
docs/developer/release/5.5.6/release-packs/podorozhnyk.md
Що оновлюємо
| Параметр | Значення |
|---|---|
| Інстанс | podorozhnyk |
| Поточний Engine (kwinst) | release_5.1.0+hotrevert (5.1.0), кастомна лінія |
| Ціль | 5.5.6 (release_5.5.6) |
| Constructor у kwinst | порожнє значення — потрібна звірка з фактичним деплоєм |
Шлях оновлення (контрольні точки)
Послідовність релізів без пропуску обов’язкових зупинок:
5.1.0 → 5.2.2 → 5.2.7 → 5.3.1 → 5.3.5 → 5.3.11 → 5.5.6
Критичні вікна:
- 5.2.2 — FULLTEXT на великих БД: плануйте 1–6+ годин можливого простою/блокування під індексацію.
- 5.3.1 — великий чекпоінт (тикети, syncdb, пост-міграції) — 15–45 хв плюс ручні скрипти після syncdb (див. повний пакет).
- 5.3.5 — обов’язкова зупинка перед 5.3.11 (не стрибати напряму на 5.3.11).
Деталі команд docker exec, міграцій, сидів і feature flags — у файлі Release Pack за посиланням вище.
Ризики та узгодження
- Великий стрибок версій (5.1.x → 5.5.x), кастомний engine (
+hotrevert): потрібна перевірка, що всі хотфікси з кастомної гілки враховані у фінальному коді 5.5.6. - У повному пакеті зазначено High risk score; перед продакшеном — бекап БД, прогін шляху на staging з копією даних за можливості.
- Розділ «Business Impact» у технічному пакеті порожній (немає
client_flowдля автозаповнення) — бізнес-перевірки списком узгодити з власниками ботів.
Наступні кроки
- Затвердити вікно простою з урахуванням FULLTEXT на 5.2.2 та 5.3.1.
- Інженерна звірка кастомної гілки та Constructor.
- Виконати покроковий деплой згідно
podorozhnyk.md, потім tech + business verification з того ж документа.
Generated: 2026-05-06