Feature Flags e gestione delle release

Feature Flags e gestione delle release

1) Perché le bandiere se ci sono i comunicati?

• Velocità e sicurezza dei rilasci: piccoli incassi + istantanea.
• Controllo del raggio di impatto: rollout progressivo, anelli, stop SLO.
• Esperimenti e A/B: bandiere multivariate, statistiche degli effetti.
• Script operativi: kill-switch per percorsi di pagamento/gioco rischiosi.

Il principio chiave è «ship dark, enable bright» - fornire in anticipo, includere consapevolmente.

2) Tipi di flag

Boolean - Attivato/disattivato filetti, bandiere di arresto di emergenza (kill-switch).
Multivariate: comportamenti (algoritmo A/B/C, limiti, coefficienti).
Config/Remote Config: parametri (timeout, limiti di puntata, dimensioni del bonus).
Permision/Entitlement - Accesso alle funzioni/limiti per ruolo/tiers.
Operational: instradamento del traffico (query shadow, attivazione di un nuovo servizio).

3) Architettura e flussi di dati

Control Plane: console/server di flag, memorizzazione regole/segmenti, controllo.
Data Plane (SDK/Proxy/Edge) - Recupero e cache dei flag, valutazione delle regole localmente (minimo di latenza), folback in caso di indisponibilità.

• Pull: SDK sincronizza config periodicamente (ETag/stream).
• Push/Streaming - Server-Sent Events/WebSocket.
• Edge Cache/Proxy: più vicino all'utente, riduce p99.

• Valutazione locale delle regole (senza hop di rete in hot-path).
• Timeout e folback (senza lettura «bloccante» del flag).
• Firma/versioning degli snapshot dei configli.

4) Targeting e segmenti

Attributi: paese/regione, lingua, piattaforma, livello KYC, livello VIP, rischio-score, età dell'account, metodo di pagamento, limiti di gioco responsabile.
Segmenti: regole salvate con versioni «morbido» (marketing) e «rigido» (compilation).
Priorità/conflitti: regole chiare, «ultimo riscontro» vietato senza test.
Geo/regolatore: caselle di controllo della disponibilità del prodotto per giurisdizione; predici invariati (ad esempio, il divieto di bonus per un paese specifico).

json
{
"flag": "new_withdrawal_flow",
"default": false,
"rules": [
{"when": {"country": "CA", "kyc_level": "FULL"}, "rollout": 25},
{"when": {"segment": "vip_tier_3_plus"}, "rollout": 100},
{"when": {"country": "DE"}, "force": false}
],
"expiresAt": "2026-03-31T00:00:00Z"
}

5) Rollout progressivo: strategie

Canary by%: 1% 5% 25% 50% 100% con uno stop automatico SLO.
Rings, un team interno di utenti beta che una regione globalmente.
Sampling per dispositivi/client - Tieni conto di stick (hash ID).
Shadow traffic - Duplica la query in un nuovo percorso senza influire sull'utente.
Dark launch: attivato, ma non apparente (raccolta di metriche, riscaldamento della cache).

• Peggioramento p95 latitanza API'withdraw '> + 15% in 10 minuti.
• Errori 5xx> 0. 5% o aumento dei guasti del provider di pagamento> + 0. 3 p.p.
• Alert frode/risk-screen è sopra la soglia del segmento.

6) Kill-switch (bandiere di emergenza)

Classe di bandiere separata, visibile SRE/On-Call.
Valutazione locale garantita con cache TTL (millisecondi).
Disconnessioni non restituite: richiere reason + postmortem ticket.
Attività automatica delle integrazioni: disattivazione del bonus, pagamento manuale, divieto di deposito per il provider X.

7) Integrazione con CI/CD e GitOps

CI: validazione di schemi di bandiere, lenti di regole, «prova secca» di targeting su campioni anonimi.
CD: promozioni di flag configure come manufatti (semver), «approval gates» per flag sensibili (pagamenti/compilation).
GitOps: flag in un repository di configurazioni separato, merge-recest = evento di modifica, controllo «da scatola».

8) Sicurezza e compliance

RBAC/ABAC: chi può creare/includere/aumentare la percentuale; separazione dei compiti (sviluppatore ≠ ≠ proprietario del prodotto).
Controllo: chi/quando/cosa/perché; giustificazione (ticket/JIRA), mappatura degli incidenti.
Riduzioni PII: gli attributi di targeting passano per anonimato/hashtag.
Firma snapshot - Verifica integrità SDK/Proxy.
La SLA per la spedizione di configure è degradata in «default sicuro».

9) Osservabilità e metriche

• Tempo di propagazione del flag (p50/p95), hit-rate della cache locale, frequenza degli aggiornamenti.
• Numero di bandiere attive/vecchie/sospese (non ritirate in base alla scadenza).
• Protettori SLO: latitanza, errore, conversione, stabilità del provider.

• DORA: frequenza dei deploy, tempo di accensione, percentuale di guasti dopo l'accensione, MTTR.
• A/B indicatori: CR, ARPPU, segnali LTV, influenza su frod-scoring.

10) Ciclo di vita del flag

1. Design: obiettivo/metrica/proprietario/data di scadenza ('expiresAt'), script di ripristino.
2. Implement: chiamate SDK, folback, telemetria «exposure «/» definizione ».
3. Rollout: lancio progressivo + porta SLO.
4. Stabilize - Fissa gli effetti, aggiorna la documentazione/routine.
5. Cleanup - Rimuove i ramificati del codice, chiude il flag e esegue il controllo dei residui.

11) Esempi di implementazione

11. 1 Web/Node. js

ts
// Инициализация SDK (псевдо)
const flags = await sdk.init({ sdkKey: process.env.FLAGS_KEY, user: { id: userIdHash, country, vipTier } });

// Не блокировать рендер:
const showNewCashout = flags.bool("new_withdrawal_flow", false);

if (showNewCashout) {
renderNewFlow();
} else {
renderClassic();
}

11. 2 Kotlin / JVM

kotlin val client = FlagsClient(sdkKey = System.getenv("FLAGS_KEY"))
val context = UserContext(id = userHash, country = country, kycLevel = kyc)
val enabled = client.getBoolean("risk_guard_withdrawals", default = true, context = context)
if (!enabled) {
// аварийный режим: все выводы в manual review routeToManual()
}

11. 3 NGINX (toggle esterno tramite map)

nginx map $http_x_feature $cashout_new {
default 0;
"~enabled" 1;
}

location /withdraw {
if ($cashout_new) { proxy_pass http://new_flow; }
if (!$cashout_new) { proxy_pass http://classic_flow; }
}

12) Gestione del rischio e passi progressivi

Passo di attivazione: 1% dei dipendenti 5% «beta», 10% RU, 25% EU, 100% tranne DE (regolatore).

Limitatori: max. 1 passo/30 min; la stabilità delle metriche per una finestra di 15 minuti

Auto-stop: regole a livello di piattaforma (vedere più avanti OPA).

rego package flags.guard

deny[msg] {
input.flag == "new_withdrawal_flow"
input.metrics["withdraw_5xx_rate"] > 0.5 msg:= "Stop rollout: withdraw 5xx too high"
}

13) Controllo di accesso e negoziazione

Change Types: standard (sicuri) vs sensibili (pagamenti/pagamenti/limiti).
Approvals - Proprietario del prodotto + tech. responsabile + compilation (per giurisdizioni).
Finestre temporanee (freeze) - Non includere/estendere in periodi ad alto rischio (prime time, tornei di grandi dimensioni).

14) Esperimenti e statistiche

Esposure events: logifichiamo la soluzione del flag con gli attributi.
Analista: valore attuale rollout, segmenti, effetto sulla conversione/errore.
Controlli statistici: split corretto, covariati di controllo (dispositivi/geo).
Etica e regolazione: evitare segmentazioni limitate dal diritto locale.

15) Anti-pattern

Bandiere a lunga vita senza «expiresAt», «cimitero dei rami» in codice.
Chiamata di rete SDK a hot-path.
Targeting PII ridondante, nessun anonimato degli attributi.
Attivazione senza sicurezza SLO/auto-stop.
Nessun kill-switch per flussi ad alto rischio (depositi/conclusioni/bonus).
Modifiche manuali «segrete» delle bandiere senza controllo o giustificazione.

16) Assegno foglio di implementazione (0-60-90)

0-30 giorni

Selezionare una piattaforma di flag/preparare self-host (SDK, proxy, cash).
Inserisci schema («flag», «owner», «purpose», «expiresAt», «risk _ level»).
Connetti le metriche SLO alla piattaforma (latitanza/errori API chiave).

31-60 giorni

Aggiungi approvals su flag sensibili, protettori OPA.
Configura strategie progressive (percent/rings), pannello kill-switch.
Incorporare linter schema flag in CI; Iniziare a ripulire i primi sospesi.

61-90 giorni

Integrazione completa con il GitOps (modifica MR flag, controllo).
Dashboard visivi: coverage SDK, tempo di distribuzione,% kash.
Flag Debt Day regolare - Rimuove il codice e chiude i flag.

17) Metriche di maturità

Tecnica: p95 accettazione configurazione <5 c; cache hit-rate SDK> 95%;% flag con 'expiresAt'> 90%.

Processi: flag 100% sensibili con approvals; Tempo medio di ripristino <3 minuti

Igiene in codice: percentuale di bandiere chiuse entro 30 giorni dall'inclusione globale> 80%.
Effetto business: miglioramento DORA (frequenza di rilascio ↑, MTTR ↓), riduzione degli incidenti di rilascio.

18) Applicazioni: modelli e criteri

Schema flag (YAML)

yaml flag: new_withdrawal_flow owner: payments-team risk_level: high purpose: "Новый поток вывода средств"
expiresAt: "2026-03-31T00:00:00Z"
sla:
propagation_p95_ms: 3000 slo_guards:
withdraw_p95_ms_increase_pct: 15 withdraw_5xx_rate_pct: 0.5 approvals:
required: ["product_owner","tech_lead","compliance"]

Politica «Nessuna bandiera eterna» (condizionale)

yaml rules:
- check: expiresAt max_days_from_now: 180 action: error

Contratto evento SDK (exposure)

json
{
"event": "flag_exposure",
"flag": "new_withdrawal_flow",
"variant": "on",
"userKey": "hash_abcdef",
"context": {"country":"CA","vipTier":"3"},
"traceId": "9f1c...a2",
"ts": 1730623200000
}

19) Conclusione

La feature Flags è una maniglia del volume per le modifiche. Collegare le attivazioni progressive, le guardie SLO, il controllo rigido e la pulizia regolare, e agganciare le bandiere a CI/CD e GitOps. Di conseguenza, i comunicati diventeranno frequenti, gestibili e sicuri e il rischio di incidenti sarà prevedibile e controllato.