Torrent Gear

CI/CD для ігрових платформ: канарські релізи та фічефлаги

1) Чому прогресивна доставка критична для iGaming

Реал-тайм і гроші: помилки в логіні/депозитах/ставках б'ють по виручці миттєво.

Піки трафіку: промо і турніри → ризик «лавини» багів.

Мульти-ринки та бренди: потрібно поетапний випуск з можливістю прицільного відключення функцій.

Мета: релізи, які можна включати поступово, вимірювати вплив на SLO, і моментально відкочувати без даунтайму.

2) Еталонна архітектура CI/CD

CI (build & test):

1. Скан вихідних (SAST), збірка артефактів/образів (SBOM, підпис).

2. Юніт/контракт/інтеграційні тести, e2e на тестовому стенді.

3. Валідація маніфестів (OPA/Kyverno), лінтінг Helm/Kustomize.

CD (progressive delivery):

GitOps (Argo CD/Flux) як єдиний механізм застосування.
Argo Rollouts/Flagger для canary/blue-green/shadow.
Release-gates: промоут тільки якщо SLO зелені (логін/депозит/ставка).
Авто-rollback при порушенні порогів.

Середовища: 'dev → stage → canary-prod → prod'( по ринках/брендах). Для canary - окремий namespace/комірка.

3) Безпека ланцюжка поставки

Immutable образи по'sha256', заборона'latest'.

Підпис образів (Cosign) + перевірка на admission-вебхуці.

Скан вразливостей (SCA) як «blocking step».

Секрети - з Vault/Cloud SM через External Secrets; аудит доступу.

4) Канарські релізи: патерни

Варіанти:

Canary по трафіку: 1% → 5% → 10% → 25% → 50% → 100%.
Canary за сегментами: тільки співробітники, потім один бренд/ринок, потім весь регіон.
Shadow: дзеркало реального трафіку без впливу на відповіді (для «важких» змін).
Blue-Green: два ідентичних стека, миттєве перемикання маршруту.

Гейти та інваріанти:

SLI: успішність логіна/депозиту/ставки, p95 API і WS-RTT, 4xx/5xx, черга ретраїв.
Бізнес-SLO: конверсія registratsiya→depozit, частка успішних висновків.
«Жорсткі» стоп-сигнали: зростання чарджбек-помилок, падіння success ratio PSP, помилки провайдера ігор.

Приклад (Argo Rollouts, фрагмент):

yaml strategy:
canary:
steps:
- setWeight: 5
- pause: {duration: 5m}
- analysis: {templates: [{templateName: deposit-slo}]} # гейт по SLO
- setWeight: 25
- pause: {duration: 10m}
- analysis: {templates: [{templateName: auth-error-rate}]}
- setWeight: 50
- pause: {}

5) Фічефлаги: управління ризиком без релізу

Типи прапорів:

Release flags - включення нової функції (канареїти можна «всередині» версії).
Ops flags (kill-switch) - миттєве відключення дорогих/нестабільних частин (наприклад, новий провайдер ігор).
Experiment flags - A/B для UI/порогів.
Permissioning flags - доступ тільки для markets/VIP/партнерів.

Правила експлуатації:

Прапори - в централізованому сервісі/SDK (Unleash/LaunchDarkly/Rollout, або свій).
TTL на прапор і «борги» - очищаємо після стабілізації.
Логуйте «рішення прапора» з'trace _ id'( для налагодження).
Зберігайте «pre-sets» для аварій (кнопка «повернути стару платіжку»).

Приклад (JSON-конфіг):

json
{
"feature": "payments_v2",  "rules": [
{"if": "market in ['DE','SE']", "rollout": 0. 25},   {"if": "brand == 'X' && user. isEmployee", "rollout": 1. 0}
],  "kill_switch": false
}

6) SLO-гейти і автовідкат

Помилка бюджету: якщо за вікно 10-15 хв SLI виходить за пороги - автопауза і відкат.

Джерела метрик: Prometheus/OTel → Argo Rollouts/Flagger AnalysisRun.

Демпфер помилкових спрацьовувань: «захист від сплесків» (required consecutive violations ≥ 3).

Приклади порогів:

`login_success_ratio ≥ 99. 9%`
`p95_payments_deposit ≤ 400ms`
`ws_rtt_p95 ≤ 120ms`
'deposit _ success _ by _ psp ≥ 99%'( по кожному PSP)

7) Міграції БД і сумісність без даунтайму

Шаблон expand → migrate → contract:

1. Expand: додати нові колонки/індекси, зробити схеми сумісними (подвійний запис).

2. Migrate: додаток пише в старе + нове, читає з нового за фічефлагом.

3. Contract: після стабілізації - видалити старе.

Інструменти: Liquibase/Flyway, міграції в CI, «idempotent & backward-compatible» правила.

Анти-пастка: заборона міграцій, що ламають стару версію, поки канарка <100%.

8) Тестова стратегія під прогресивну доставку

Контракти (Pact/Buf) між сервісами та зовнішніми провайдерами (PSP/ігри).

E2E-сценарії: логін → депозит → ставка → сетлмент → виведення (і негативні шляхи).

Синтетика в проді (canary-комірок): пробні депозити/ставки малими сумами.

Тести фічефлагів: у кожній гілці - конфігурація прапорів для dev/stage/canary.

9) Оркестрація релізів по доменах

Auth/профіль: короткі тайм-аути і ліміти; тест 2FA/SSO.

Платежі/гаманець: canary тільки на малу частку і один ринок; строгий моніторинг PSP-квот.

Game-gateway (WS): окремі нодпули; PDB; sticky-routing; фічефлаг на новий codec/протокол.

Промо/бонуси: ідемпотентність '/promo/claim'; обмежувачі на canary-трафіку.

10) GitOps-потік (приклад)

1. Merge в main → CI зібрав, підписав образ, прогнав тести.

2. Бот оновив версію в canary-маніфесті → Argo CD застосував.

3. Argo Rollouts: 5% трафіку + аналіз метрик.

4. Автопромоут до 25/50/100% або автовідкат.

5. PR для «повного прод» і очищення прапорів/конфігів.

11) Спостережуваність і телеметрія релізів

Мітки'version','rollout _ step','flag _ variant'в метриках/логах/трейсах.

Дашборди «Release Health»: SLI по ключовим флоу, порівняння'baseline vs canary'.

Логи рішень фічефлагів (rate-limited), трейс-лінки на проблемні спани.

12) Інциденти, відкат, хотфікси

Runbook: «як відкотити реліз/вимкнути прапор/перемкнути PSP».

Кнопка Kill-switch: миттєве відключення нової функції без деплоя.

Хотфікс: hot-patch через canary на 1-5% + прискорений промоут при зелених SLO.

13) Комплаєнс і аудит

Повна трассируемость: хто/коли/що викотив, які прапори і де включені.

WORM-журнали релізів і змін прапорів.

Політика «чотирьох очей» для платіжних сервісів і міграцій БД.

14) Приклади конфігурацій

GitHub Actions (фрагмент CI):

yaml jobs:
build-test:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- run: make test
- run: make build && cosign sign --key $COSIGN_KEY image:tag
- run: trivy image --exit-code 1 image:tag
- run: sbom generate image:tag > sbom. spdx. json

Feature-flag в коді (псевдо):

python if flags. is_enabled("payments_v2", user=ctx. user, market=ctx. market):
result = deposit_v2(req)
else:
result = deposit_v1(req)

OPA-політика (заборона небезпечних Pod):

rego deny[msg] {
input. request. kind. kind == "Pod"
not input. request. object. spec. securityContext. runAsNonRoot msg:= "runAsNonRoot is required"
}

15) Чек-лист (prod-ready)

GitOps включений; ручні'kubectl apply'заборонені.
Образи підписані, уразливості в нормиках; admission перевіряє підпис.
Canary/blue-green налаштовані; Release-gates по SLO підключені.
Фічефлагі з kill-switch; журнал рішень прапорів.
Міграції за схемою expand→migrate→contract; подвійний запис при переходах.
Дашборди'baseline vs canary'; автовідкат за метриками.
Runbook відкату/перемикання PSP/відключення провайдера ігор.
Контракти з зовнішніми провайдерами протестовані на canary.
Політики безпеки (OPA/Kyverno), секrets з Vault/SM.
Очищення «мертвих» прапорів і конфігів після релізу.

16) Типові пастки

Канарка «по IP», а не по реальних сегментах гравців → спотворення метрик.

Відсутність SLO-гейтів → канарка їде «на око».

Ламаючі міграції схеми при активній старій версії.

Необмежені ретраї/ідемпотентність у платежах → каскади дублів.

«Вічні» фічефлаги без TTL → хаос в конфігурації.

Єдиний PSP в канарці → не можна порівняти success ratio.

Резюме

CI/CD для iGaming - це прогресивна доставка + конфігурованість у часі: канарні релізи, фічефлаги з kill-switch, SLO-гейти і автовідкати. Додайте безпечні міграції, GitOps-дисципліну, телеметрію «baseline vs canary» і суворі політики безпеки - і ваші релізи стануть передбачуваними, швидкими і керованими навіть під піковими навантаженнями і суворим комплаєнсом.