Feature flag: rilasciare senza trattenere il respiro

spinny:~/writing $ vim 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~

NORMAL · openfeature-feature-flags-progressive-delivery.md [readonly]131 lines · :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}

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~