Feature flag: rilasciare senza trattenere il respiro

spinny:~/writing $ less openfeature-feature-flags-progressive-delivery.md

1 
2Il deploy è quando il codice arriva in produzione. Il rilascio è quando qualcuno può davvero usarlo. Confondere le due cose è uno dei modi più veloci per rendere ogni deploy un piccolo momento di tensione.
3 
4I feature flag servono a mettere spazio tra questi due momenti. Puoi deployare oggi, accendere domani per il team interno, poi per un cliente pilota, poi per il 10% degli utenti. Se qualcosa va male, spegni il flag. Non devi per forza fare rollback di tutta la release.
5 
6## Il flag non è solo un if
7 
8Tecnicamente spesso è un `if`. Culturalmente è molto di più.
9 
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14 
15return oldCheckout(input);
16```
17 
18Quel piccolo `if` può rappresentare un rollout graduale, un esperimento, una migrazione, un permesso enterprise o un kill switch operativo. Il problema è che, se non lo gestisci bene, può diventare anche debito tecnico che resta nel codice per due anni.
19 
20## Dove entra OpenFeature
21 
22OpenFeature è una specifica aperta per valutare feature flag con una API comune. L'idea è semplice: il codice applicativo non dovrebbe dipendere direttamente dal vendor o dal sistema interno che usi per i flag.
23 
24L'app chiede:
25 
26```typescript
27const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {
28  targetingKey: user.id,
29  plan: user.plan,
30  country: user.country,
31});
32```
33 
34Il provider decide da dove arrivano le regole: SaaS, file, servizio interno, flagd, configurazione GitOps. Se un giorno cambi backend di feature flagging, l'applicazione non deve essere riscritta ovunque.
35 
36Questa separazione sembra un dettaglio architetturale, ma si sente quando il progetto cresce.
37 
38## Il contesto è metà del lavoro
39 
40Un flag acceso o spento per tutti è utile, ma limitato. La progressive delivery vive nel contesto:
41 
42- utente interno o esterno;
43- piano free o enterprise;
44- paese;
45- organizzazione;
46- versione dell'app;
47- percentuale stabile di traffico.
48 
49La chiave importante è `targetingKey`: deve essere stabile. Se cambia a ogni request, un utente può finire una volta nella variante A e una volta nella variante B. Per un esperimento è pessimo, per un checkout può essere disastroso.
50 
51## Un rollout sensato
52 
53Un flusso che mi piace è questo:
54 
551. deploy con flag spento;
562. accensione per sviluppatori e QA;
573. accensione per un cliente o un tenant pilota;
584. rollout al 5%;
595. rollout al 25%;
606. rollout al 100%;
617. rimozione del vecchio codice e del flag.
62 
63Il punto spesso dimenticato è l'ultimo. Un flag temporaneo deve avere una data di morte. Se resta per sempre, ogni refactor futuro dovrà chiedersi: "ma questo ramo serve ancora?".
64 
65## Kill switch: prepararli prima
66 
67Il kill switch è il flag che ti salva quando una dipendenza esterna inizia a fare scherzi, un job consuma troppe risorse o una nuova logica produce errori strani.
68 
69Un buon kill switch deve essere:
70 
71- facile da trovare;
72- documentato nel runbook;
73- testato ogni tanto;
74- osservabile quando viene attivato;
75- indipendente, per quanto possibile, dalla parte che potrebbe rompersi.
76 
77La cosa peggiore è scoprire durante l'incidente che il flag esiste, ma nessuno sa se funziona ancora.
78 
79## Osservabilità o non è progressive delivery
80 
81Accendere una feature al 10% senza guardare metriche è solo ottimismo con più passaggi.
82 
83Ogni rollout dovrebbe rispondere a domande semplici:
84 
85- gli errori sono aumentati?
86- la latenza è cambiata?
87- gli utenti completano il flusso?
88- ci sono più ticket o retry?
89- una variante impatta solo un segmento?
90 
91OpenFeature supporta hook attorno alla valutazione dei flag. Sono utili per loggare errori, aggiungere metriche o collegare la valutazione a una trace.
92 
93## Naming e ownership
94 
95I nomi contano. `new_ui` non dice nulla. `checkout.v2.enabled` dice molto di più.
96 
97Per ogni flag segnerei almeno:
98 
99- nome;
100- descrizione;
101- owner;
102- default sicuro;
103- motivo per cui esiste;
104- data o condizione di rimozione.
105 
106Un flag senza owner è quasi sempre un flag che nessuno cancellerà.
107 
108## Dove valutarli
109 
110Frontend, backend o edge? Dipende.
111 
112Se il flag riguarda layout, copy o onboarding, il frontend va bene. Se riguarda permessi, billing, limiti o dati sensibili, deve stare sul backend. Se riguarda routing o esperimenti ad alto traffico, l'edge può avere senso.
113 
114La regola semplice: il frontend può migliorare l'esperienza, ma non deve essere l'unica barriera di sicurezza.
115 
116## Conclusione
117 
118I feature flag fatti bene cambiano il rapporto con la produzione. Non eliminano il rischio, ma lo rendono più piccolo e gestibile. Puoi rilasciare a fette, osservare, fermarti, tornare indietro, imparare.
119 
120OpenFeature aggiunge una base pulita: una API comune, provider intercambiabili e un modo più ordinato di far crescere il sistema. Però la disciplina resta tua: default sicuri, nomi chiari, metriche, owner e pulizia.
121 
122Il flag migliore è quello che ti aiuta a rilasciare con calma e poi sparisce quando non serve più.
123 
124## Fonti
125 
126- [OpenFeature: Introduction](https://openfeature.dev/docs/reference/intro/)
127- [OpenFeature: Node.js SDK](https://openfeature.dev/docs/reference/sdks/server/javascript/)
128- [OpenFeature Specification: Flag Evaluation API](https://openfeature.dev/specification/sections/flag-evaluation)
129- [OpenFeature: Hooks](https://openfeature.dev/docs/reference/concepts/hooks/)
130- [CNCF: OpenFeature](https://www.cncf.io/projects/openfeature/)
131

:Feature flag: rilasciare senza trattenere il respirolines 1-131 (END) — press q to close

2Il deploy è quando il codice arriva in produzione. Il rilascio è quando qualcuno può davvero usarlo. Confondere le due cose è uno dei modi più veloci per rendere ogni deploy un piccolo momento di tensione.

4I feature flag servono a mettere spazio tra questi due momenti. Puoi deployare oggi, accendere domani per il team interno, poi per un cliente pilota, poi per il 10% degli utenti. Se qualcosa va male, spegni il flag. Non devi per forza fare rollback di tutta la release.

6## Il flag non è solo un if

8Tecnicamente spesso è un `if`. Culturalmente è molto di più.

10```typescript

11if (await flags.isEnabled('checkout.v2.enabled', context)) {

12 return newCheckout(input);

13}

15return oldCheckout(input);

16```

18Quel piccolo `if` può rappresentare un rollout graduale, un esperimento, una migrazione, un permesso enterprise o un kill switch operativo. Il problema è che, se non lo gestisci bene, può diventare anche debito tecnico che resta nel codice per due anni.

20## Dove entra OpenFeature

22OpenFeature è una specifica aperta per valutare feature flag con una API comune. L'idea è semplice: il codice applicativo non dovrebbe dipendere direttamente dal vendor o dal sistema interno che usi per i flag.

24L'app chiede:

26```typescript

27const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {

28 targetingKey: user.id,

29 plan: user.plan,

30 country: user.country,

31});

32```

34Il provider decide da dove arrivano le regole: SaaS, file, servizio interno, flagd, configurazione GitOps. Se un giorno cambi backend di feature flagging, l'applicazione non deve essere riscritta ovunque.

36Questa separazione sembra un dettaglio architetturale, ma si sente quando il progetto cresce.

38## Il contesto è metà del lavoro

40Un flag acceso o spento per tutti è utile, ma limitato. La progressive delivery vive nel contesto:

42- utente interno o esterno;

43- piano free o enterprise;

44- paese;

45- organizzazione;

46- versione dell'app;

47- percentuale stabile di traffico.

49La chiave importante è `targetingKey`: deve essere stabile. Se cambia a ogni request, un utente può finire una volta nella variante A e una volta nella variante B. Per un esperimento è pessimo, per un checkout può essere disastroso.

51## Un rollout sensato

53Un flusso che mi piace è questo:

551. deploy con flag spento;

562. accensione per sviluppatori e QA;

573. accensione per un cliente o un tenant pilota;

584. rollout al 5%;

595. rollout al 25%;

606. rollout al 100%;

617. rimozione del vecchio codice e del flag.

63Il punto spesso dimenticato è l'ultimo. Un flag temporaneo deve avere una data di morte. Se resta per sempre, ogni refactor futuro dovrà chiedersi: "ma questo ramo serve ancora?".

65## Kill switch: prepararli prima

67Il kill switch è il flag che ti salva quando una dipendenza esterna inizia a fare scherzi, un job consuma troppe risorse o una nuova logica produce errori strani.

69Un buon kill switch deve essere:

71- facile da trovare;

72- documentato nel runbook;

73- testato ogni tanto;

74- osservabile quando viene attivato;

75- indipendente, per quanto possibile, dalla parte che potrebbe rompersi.

77La cosa peggiore è scoprire durante l'incidente che il flag esiste, ma nessuno sa se funziona ancora.

79## Osservabilità o non è progressive delivery

81Accendere una feature al 10% senza guardare metriche è solo ottimismo con più passaggi.

83Ogni rollout dovrebbe rispondere a domande semplici:

85- gli errori sono aumentati?

86- la latenza è cambiata?

87- gli utenti completano il flusso?

88- ci sono più ticket o retry?

89- una variante impatta solo un segmento?

91OpenFeature supporta hook attorno alla valutazione dei flag. Sono utili per loggare errori, aggiungere metriche o collegare la valutazione a una trace.

93## Naming e ownership

95I nomi contano. `new_ui` non dice nulla. `checkout.v2.enabled` dice molto di più.

97Per ogni flag segnerei almeno:

99- nome;

100- descrizione;

101- owner;

102- default sicuro;

103- motivo per cui esiste;

104- data o condizione di rimozione.

105

106Un flag senza owner è quasi sempre un flag che nessuno cancellerà.

107

108## Dove valutarli

109

110Frontend, backend o edge? Dipende.

111

112Se il flag riguarda layout, copy o onboarding, il frontend va bene. Se riguarda permessi, billing, limiti o dati sensibili, deve stare sul backend. Se riguarda routing o esperimenti ad alto traffico, l'edge può avere senso.

113

114La regola semplice: il frontend può migliorare l'esperienza, ma non deve essere l'unica barriera di sicurezza.

115

116## Conclusione

117

118I feature flag fatti bene cambiano il rapporto con la produzione. Non eliminano il rischio, ma lo rendono più piccolo e gestibile. Puoi rilasciare a fette, osservare, fermarti, tornare indietro, imparare.

119

120OpenFeature aggiunge una base pulita: una API comune, provider intercambiabili e un modo più ordinato di far crescere il sistema. Però la disciplina resta tua: default sicuri, nomi chiari, metriche, owner e pulizia.

121

122Il flag migliore è quello che ti aiuta a rilasciare con calma e poi sparisce quando non serve più.

123

124## Fonti

125

126- [OpenFeature: Introduction](https://openfeature.dev/docs/reference/intro/)

127- [OpenFeature: Node.js SDK](https://openfeature.dev/docs/reference/sdks/server/javascript/)

128- [OpenFeature Specification: Flag Evaluation API](https://openfeature.dev/specification/sections/flag-evaluation)

129- [OpenFeature: Hooks](https://openfeature.dev/docs/reference/concepts/hooks/)

130- [CNCF: OpenFeature](https://www.cncf.io/projects/openfeature/)

131