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: конверсия регистрация→депозит, доля успешных выводов.
«Жёсткие» стоп-сигналы: рост чарджбэк-ошибок, падение 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» и строгие политики безопасности — и ваши релизы станут предсказуемыми, быстрыми и управляемыми даже под пиковыми нагрузками и строгим комплаенсом.