Operations and → Management Release and Update Cycles

Release and update cycles

1) Purpose

• reduces the uncertainty and cost of coordination,
• reduces the risk of incidents and rollbacks,
• synchronizes technology with business events (marketing, sports, Fin. reporting),
• improves throughput of commands without CFR (Change Failure Rate) growth.

2) Release models: which one to choose

1. Release Train - Fixed slots (e.g. Tue/Thur 10:00 EET)

Suitable for multi-team monoliths and "heavy" domain changes.

2. Continuous Delivery (on request) - every merge that has passed quality gates can go to food.

Suitable for microservices and feature-flag culture.

3. Hybrid - product fronts on trains, backend services "on demand."

Selection criteria: maturity of tests/observability, dependence on external partners (PSP/KYC), compliance requirements, organization size.

3) Release calendar and windows

Single calendar (company-wide): release slots, database migrations, marketing campaigns, major sporting events, reporting periods.
Freeze periods: clearly defined windows where only hotfix P1 is allowed (e.g. Champions League final, Black Friday, tax reporting).
Regional waves: first "warm" markets/low traffic, then - basic; night windows of local TZs.
Crossing policy: prohibition of simultaneous changes along one critical path (payments, KYC, authorization).

4) Branching and versioning

Trunk-based + short-lived branches (feature branches ≤ 3-5 days).
Release-branch - only for trains/long verifications; hard back-merge in 'main'.
SemVer: `MAJOR. MINOR. PATCH 'for libraries/SDK; tags of artifacts and environments.
Contracts: schemes (Avro/Protobuf) with back/forward compatibility; migrations - two-phase.

5) Quality channels (gates)

1. Static + SAST/DAST + Linters

2. Unit/Contract/Component tests

3. smoke E2E/Performance (on stage)

4. Security/Compliance checks

5. Release Candidate → signature, SBOM, artifacts

6. Progressive rollout with auto-gardrails (see § 7)

All gates - code and policy (Policy-as-Code), results - in release artifacts.

6) Environments and Promotions

Dev → Int → Stage → Prod, for data: Sandbox/Data-Stage.
GitOps promotions, immutable images, prohibition of "manual" edits in prod.
Parameterization: regions, limits, providers - through configs (audited).

7) Rolling strategies

Canary: 1%→5%→25%→100% (или per-region).
Blue-Green: parallel environments + atomic switching.
Feature Flags: functional switches/kill-switch; A/B и shadow.
Staged Rollout Mobile/Web: by client version/delivery channel (Store/OTA).

Gardrails (auto stop): p95 latency ↑> 25%, error%> 2%, drop in authorizations/deposits, growth in chargebacks, burn-rate SLO for 1-hour window> threshold.

8) Coordination with business and partners

Marketing/Events: releases of functionality for campaigns with a margin ≥ 48 hours.
Partners (PSP/KYC/Game providers): slots for SDK certifications/updates, dual endpoints for the migration period.
Support: macros/FAQ for UX changes, status pages, escalation channels.

9) Data and schema updates

Additive first: first add, then switch read/write, at the end - remove the old.
Indices and large migrations - night windows, by batches, with checkpoints and progress.
Window and metric dictionary versioning: updates synchronously with release, BI migrations - separately from production windows.

10) Communications and artifacts

Release Notes (what/why/risks/rollback), ChangeLog by service.
Calendar invites to stakeholders, ad templates (before/during/after).
War-room channel for the duration of trains/major releases, update frequency: P1 - every 15-20 minutes.

11) Performance metrics

DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR.
Backout Rate by change type.
SLO Compliance% before/after releases.
Release Debt: "hanging" flags, incomplete migrations, old dependencies.
Business Impact: Conversion, KYC TTV, PSP success, GGR/NGR drift to release window.

12) Anti-patterns

Big-bang: "all at once" without flags/canaries.
Release at peak traffic/events without freeze exceptions.

No auto-gardrails: manual monitoring "by eye."

Long-lived branches: painful mergers and hidden regressions.
Manual steps in sales: no audit and predictability.
Flags without TTL and owners: "eternal" branches.

13) Checklists

Before release

• RFC/ticket, risk and blast-radius evaluated
• CI/CD gates passed, artifacts signed
• Rolling plan + stop criteria + backout ready
• Coordination with calendar, freeze and partners
• Dashboards/alerts bound to version, war-room created

At the time of release

• Canary stages and auto-stop are active
• p95/error% metrics, business signals (auth, KYC, PSP) on monitor
• Scheduled communications, status page refreshed

After release

• Release Notes and ChangeLog Published
• Removed Flags/Temporary Exceptions (TTL)
• Post-mortem in case of deviations ≤ 5 working days
• Updated playbooks and documentation

14) Mini templates

• Date/Time: Tue, 10am-12pm EET
• Constituency: EU (10%→50%→100%) then LATAM (10%→100%)
• Stop criteria: error%> 2% 10 min, p95> + 25% 10 min, PSP success <97%
• Backout: switch traffic to previous version + flag rollback
• Contact: @ RelEng, @ SRE-on-call, @ Support

• What's new/Why
• Impact on users and partners
• Risks and known limitations
• Rolling plan/Stop criteria/Backout
• Metrics for monitoring
• Contacts and support channels

15) Integration with neighboring disciplines

Change management: classification standard/normal/emergency, CAB, audit.
Reducing the consequences of incidents: ready-made feature flags, quotas, shedding.
Configuration audit: all promotions through Git, drift detection and application log.
Execution policies: limits/timeouts/retrays - like code, with coercion.

16) The bottom line

Release cycles are a controlled rhythm between speed and reliability. Fixed slots where coordination is needed; "on demand" where automation maturity is. Everywhere - one calendar, flags and canary rolls, automatic gardrails and transparent communications. So releases become predictable, safe and economical.