Операції та Управління → Цикли релізів та оновлень

Цикли релізів та оновлень

1) Призначення

• знижує невизначеність і вартість координації,
• зменшує ризик інцидентів і відкатів,
• синхронізує техніку з бізнес-подіями (маркетинг, спорт, фін. звітність),
• підвищує throughput команди без зростання CFR (Change Failure Rate).

2) Моделі релізів: яку вибрати

1. Release Train (поїзди) - фіксовані слоти (наприклад, вт/чт 10:00 EET).

Підходить для багатокомандних монолітів і «важких» доменних змін.

2. Continuous Delivery (за запитом) - кожен merge, що пройшов quality-гейти, може йти в прод.

Підходить для мікросервісів і feature-flag культури.

3. Гібрид - продуктові фронти по поїздах, backend-сервіси «за запитом».

Критерії вибору: зрілість тестів/обсервабіліті, залежність від зовнішніх партнерів (PSP/KYC), вимоги комплаєнсу, розмір організації.

3) Релізний календар і вікна

Єдиний календар (company-wide): слоти релізів, міграції БД, маркетингові кампанії, великі спортивні події, звітні періоди.
Freeze-періоди: чітко визначені вікна, коли допускаються тільки hotfix P1 (наприклад, фінал ЛЧ, Black Friday, податкова звітність).
Регіональні хвилі: спочатку «теплі» ринки/низький трафік, потім - основні; нічні вікна локальних TZ.
Політика перетинів: заборона одночасних змін по одному критичному шляху (платежі, KYC, авторизація).

4) Розгалуження і версіонування

Trunk-based + short-lived branches (feature гілки ≤ 3-5 днів).
Release-гілка - тільки для поїздів/довгих верифікацій; жорсткий back-merge в'main'.
SemVer: `MAJOR. MINOR. PATCH'для бібліотек/SDK; теги артефактів і оточень.
Контракти: схеми (Avro/Protobuf) з back/forward сумісністю; міграції - двофазні.

5) Канвеєри якості (гейти)

1. Static + SAST/DAST + лінтери

2. Unit/Contract/Component тести

3. E2E/Performance smoke (на стейджі)

4. Security/Compliance checks (секрети, ліцензії, політика територій)

5. Release Candidate → підпис, SBOM, артефакти

6. Progressive rollout з авто-гардрейлами (див. § 7)

Всі гейти - код і політика (Policy-as-Code), результати - в артефактах релізу.

6) Середовища і промоути

Dev → Int → Stage → Prod, для даних: Sandbox/Data-Stage.
GitOps промоути, immutable образи, заборона «ручних» правок в проді.
Параметризація: регіони, ліміти, провайдери - через конфіги (аудиторовані).

7) Стратегії розкатки

Canary: 1%→5%→25%→100% (або per-region).
Blue-Green: паралельні середовища + атомарне перемикання.
Feature Flags: функціональні вмикачі/kill-switch; A/B и shadow.
Staged Rollout Mobile/Web: за версіями клієнта/каналами доставки (Store/OTA).

Гардрейли (auto stop): p95 latency ↑> 25%, error%> 2%, падіння авторизацій/депозитів, зростання чарджбеків, burn-rate SLO за 1-годинне вікно> порогу.

8) Узгодження з бізнесом і партнерами

Маркетинг/Події: релізи функціоналу до кампаній із запасом ≥ 48 год.
Партнери (PSP/KYC/Game providers): слоти для сертифікацій/оновлень SDK, подвійні ендпоінти на період міграції.
Підтримка: макроси/FAQ на зміни UX, сторінки статусу, канали ескалації.

9) Оновлення даних і схем

Additive first: спочатку додати, потім перемкнути читання/запис, в кінці - прибрати старе.
Індекси і великі міграції - нічні вікна, по батчах, з чекпойнтами і прогресом.
Версіонування вітрин і словника метрик: оновлення синхронно з релізом, міграції BI - окремо від продових вікон.

10) Комунікації та артефакти

Release Notes (що/навіщо/ризики/rollback), ChangeLog по сервісах.
Календарні інвайти стейкхолдерам, шаблони оголошень (до/під час/після).
War-room канал на час поїздів/великих релізів, частота апдейтів: P1 - кожні 15-20 хв.

11) Метрики ефективності

DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR.
Backout Rate за типами змін.
SLO Compliance% до/після релізів.
Release Debt: «висять» прапори, незавершені міграції, старі залежності.
Business Impact: конверсія, KYC TTV, PSP success, GGR/NGR drift у вікно релізу.

12) Анти-патерни

Big-bang: «все і відразу» без прапорів/канарок.
Реліз в пік трафіку/подій без freeze-винятків.
Без авто-гардрейлів: ручний моніторинг «на око».
Довгоживучі гілки: хворобливі злиття і приховані регресії.
Ручні кроки в проді: немає аудиту і передбачуваності.
Прапори без TTL і власників: «вічні» розгалуження.

13) Чек-листи

Перед релізом

• RFC/тікет, ризик і blast-radius оцінені
• Пройдені гейти CI/CD, артефакти підписані
• План розкатки + стоп-критерії + backout готовий
• Узгодження з календарем, freeze і партнерами
• Дашборди/алерти прив'язані до версії, war-room створений

Під час релізу

• Канарські сходи і авто-стоп активні
• Метрики p95/error%, бізнес-сигнали (auth, KYC, PSP) на моніторі
• Комунікації за розкладом, статус-сторінка оновлюється

Після релізу

• Release Notes і ChangeLog опубліковані
• Видалені прапори/тимчасові винятки (TTL)
• Пост-мортем при відхиленнях ≤ 5 раб. днів
• Оновлені плейбуки та документація

14) Міні-шаблони

• Дата/час: Вт, 10:00–12:00 EET
• Округ: EU (10%→50%→100%), потім LATAM (10%→100%)
• Стоп-критерії: error%> 2% 10 хв, p95> + 25% 10 хв, PSP success <97%
• Backout: перемикання трафіку на попередню версію + відкат прапорів
• Контакти: @RelEng, @SRE-on-call, @Support

• Що нового/Навіщо
• Вплив на користувачів і партнерів
• Ризики та відомі обмеження
• План розкатки/Стоп-критерії/Backout
• Метрики для моніторингу
• Контакти та канали підтримки

15) Інтеграції з сусідніми дисциплінами

Управління змінами: класифікація standard/normal/emergency, CAB, аудит.
Зниження наслідків інцидентів: готові фіча-прапори, квоти, шеддінг.
Аудит конфігурацій: всі промоути через Git, drift-детект і журнал застосувань.
Політики виконання: ліміти/таймаути/ретраї - як код, з примусом.

16) Підсумок

Цикли релізів - це керований ритм між швидкістю і надійністю. Фіксовані слоти там, де потрібна координація; «за запитом» там, де зрілість автоматизації. Скрізь - один календар, прапори і канарські розкатки, автоматичні гардрейли і прозорі комунікації. Так релізи стають передбачуваними, безпечними і економними.