Feature flag: suelta sin contener la respiración

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

1 
2La implementación es cuando el código llega a producción. La liberación es cuando alguien realmente puede usarlo. Confundirlos es una de las formas más rápidas de hacer que cada despliegue sea un momento un poco tenso.
3 
4Los feature flag sirven para poner espacio entre estos dos momentos. Puede implementarlo hoy, iniciarlo mañana para el equipo interno, luego para un cliente piloto y luego para el 10% de los usuarios. Si algo sale mal, apaga la bandera. No necesariamente es necesario revertir toda la versión.
5 
6## La bandera no es sólo un si
7 
8Técnicamente suele ser un `if`. Culturalmente es mucho más.
9 
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14 
15return oldCheckout(input);
16```
17 
18Ese pequeño `if` puede representar un despliegue gradual, un experimento, una migración, un permiso empresarial o un kill switch operativo. El problema es que si no se gestiona bien también puede convertirse en deuda técnica que se queda en el código durante dos años.
19 
20## ¿Dónde entra OpenFeature?
21 
22OpenFeature es una especificación abierta para evaluar feature flag con un API común. La idea es simple: el código de su aplicación no debe depender directamente del proveedor o del sistema interno que utiliza para las banderas.
23 
24La aplicación pregunta:
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 
34El proveedor decide de dónde provienen las reglas: SaaS, archivo, servicio interno, flagd, configuración de GitOps. Si un día cambia el backend de marcado de funciones, no es necesario reescribir la aplicación en todas partes.
35 
36Esta separación parece un detalle arquitectónico, pero se siente a medida que crece el proyecto.
37 
38## El contexto es la mitad de la batalla
39 
40Una bandera de encendido o apagado para todos es útil, pero limitada. La entrega progresiva vive en contexto:
41 
42- usuario interno o externo;
43- plan gratuito o empresarial;
44- aldea;
45- organización;
46- versión de la aplicación;
47- porcentaje estable de tráfico.
48 
49La clave importante es `targetingKey`: debe ser estable. Si cambia con cada solicitud, un usuario puede terminar una vez en la variante A y otra en la variante B. Para un experimento es terrible, para una compra puede ser desastroso.
50 
51## Un lanzamiento sensato
52 
53Un flujo que me gusta es este:
54 
551. desplegar con la bandera apagada;
562. encendido para desarrolladores y control de calidad;
573. encendido para un cliente o inquilino piloto;
584. 5% de implementación;
595. lanzamiento al 25%;
606. 100% de implementación;
617. eliminación del código y la bandera antiguos.
62 
63El punto que a menudo se olvida es el último. Una bandera temporal debe tener una fecha de muerte. Si permanece para siempre, cada refactor futuro tendrá que preguntarse: "¿pero esta rama sigue siendo útil?".
64 
65## Kill switch: prepáralos primero
66 
67El kill switch es la bandera que te salva cuando una dependencia externa comienza a molestarte, un trabajo consume demasiados recursos o una nueva lógica produce errores extraños.
68 
69Un buen kill switch debe ser:
70 
71- fácil de encontrar;
72- documentado en el runbook;
73- probado ocasionalmente;
74- observable cuando se activa;
75- independiente, en la medida de lo posible, de la pieza que podría romperse.
76 
77Lo peor es descubrir durante el accidente que la bandera existe, pero nadie sabe si todavía funciona.
78 
79## Observabilidad o entrega no progresiva
80 
81Activar una función al 10% sin mirar las métricas es solo optimismo con múltiples pasos.
82 
83Cada implementación debe responder preguntas simples:
84 
85- ¿Han aumentado los errores?
86- ¿Ha cambiado la latencia?
87- ¿Los usuarios completan el flujo?
88- ¿Hay más tickets o reintentos?
89- ¿Una variante afecta sólo a un segmento?
90 
91OpenFeature admite ganchos alrededor de la evaluación de banderas. Son útiles para registrar errores, agregar métricas o vincular la calificación a un trace.
92 
93## Denominación y propiedad
94 
95Los nombres importan. `new_ui` no dice nada. `checkout.v2.enabled` dice mucho más.
96 
97Para cada bandera marcaría al menos:
98 
99- nombre;
100- descripción;
101- dueño;
102- valor predeterminado seguro;
103- razón por la que existe;
104- fecha o condición de expulsión.
105 
106Una bandera sin dueño es casi siempre una bandera que nadie borrará.
107 
108## Dónde evaluarlos
109 
110¿Frontend, backend o borde? Depende.
111 
112Si la bandera es para diseño, copia o incorporación, la interfaz está bien. Si se trata de permisos, facturación, límites o datos confidenciales, debe estar en el backend. Si se trata de experimentos de enrutamiento o de mucho tráfico, la ventaja puede tener sentido.
113 
114La regla simple: el frontend puede mejorar la experiencia, pero no debería ser la única barrera de seguridad.
115 
116## Conclusión
117 
118Los feature flag bien hechos cambian la relación con la producción. No eliminan el riesgo, pero lo hacen más pequeño y manejable. Puedes soltar en rodajas, observar, detenerte, retroceder, aprender.
119 
120OpenFeature agrega una base limpia: un API común, proveedores intercambiables y una forma más ordenada de hacer crecer el sistema. Pero la disciplina sigue siendo tuya: valores predeterminados seguros, nombres claros, métricas, propietarios y limpieza.
121 
122La mejor bandera es la que te ayuda a soltar con calma y luego desaparece cuando ya no es necesaria.
123 
124## Fuentes
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: suelta sin contener la respiraciónlines 1-131 (END) — press q to close

2La implementación es cuando el código llega a producción. La liberación es cuando alguien realmente puede usarlo. Confundirlos es una de las formas más rápidas de hacer que cada despliegue sea un momento un poco tenso.

4Los feature flag sirven para poner espacio entre estos dos momentos. Puede implementarlo hoy, iniciarlo mañana para el equipo interno, luego para un cliente piloto y luego para el 10% de los usuarios. Si algo sale mal, apaga la bandera. No necesariamente es necesario revertir toda la versión.

6## La bandera no es sólo un si

8Técnicamente suele ser un `if`. Culturalmente es mucho más.

10```typescript

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

12 return newCheckout(input);

13}

15return oldCheckout(input);

16```

18Ese pequeño `if` puede representar un despliegue gradual, un experimento, una migración, un permiso empresarial o un kill switch operativo. El problema es que si no se gestiona bien también puede convertirse en deuda técnica que se queda en el código durante dos años.

20## ¿Dónde entra OpenFeature?

22OpenFeature es una especificación abierta para evaluar feature flag con un API común. La idea es simple: el código de su aplicación no debe depender directamente del proveedor o del sistema interno que utiliza para las banderas.

24La aplicación pregunta:

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```

34El proveedor decide de dónde provienen las reglas: SaaS, archivo, servicio interno, flagd, configuración de GitOps. Si un día cambia el backend de marcado de funciones, no es necesario reescribir la aplicación en todas partes.

36Esta separación parece un detalle arquitectónico, pero se siente a medida que crece el proyecto.

38## El contexto es la mitad de la batalla

40Una bandera de encendido o apagado para todos es útil, pero limitada. La entrega progresiva vive en contexto:

42- usuario interno o externo;

43- plan gratuito o empresarial;

44- aldea;

45- organización;

46- versión de la aplicación;

47- porcentaje estable de tráfico.

49La clave importante es `targetingKey`: debe ser estable. Si cambia con cada solicitud, un usuario puede terminar una vez en la variante A y otra en la variante B. Para un experimento es terrible, para una compra puede ser desastroso.

51## Un lanzamiento sensato

53Un flujo que me gusta es este:

551. desplegar con la bandera apagada;

562. encendido para desarrolladores y control de calidad;

573. encendido para un cliente o inquilino piloto;

584. 5% de implementación;

595. lanzamiento al 25%;

606. 100% de implementación;

617. eliminación del código y la bandera antiguos.

63El punto que a menudo se olvida es el último. Una bandera temporal debe tener una fecha de muerte. Si permanece para siempre, cada refactor futuro tendrá que preguntarse: "¿pero esta rama sigue siendo útil?".

65## Kill switch: prepáralos primero

67El kill switch es la bandera que te salva cuando una dependencia externa comienza a molestarte, un trabajo consume demasiados recursos o una nueva lógica produce errores extraños.

69Un buen kill switch debe ser:

71- fácil de encontrar;

72- documentado en el runbook;

73- probado ocasionalmente;

74- observable cuando se activa;

75- independiente, en la medida de lo posible, de la pieza que podría romperse.

77Lo peor es descubrir durante el accidente que la bandera existe, pero nadie sabe si todavía funciona.

79## Observabilidad o entrega no progresiva

81Activar una función al 10% sin mirar las métricas es solo optimismo con múltiples pasos.

83Cada implementación debe responder preguntas simples:

85- ¿Han aumentado los errores?

86- ¿Ha cambiado la latencia?

87- ¿Los usuarios completan el flujo?

88- ¿Hay más tickets o reintentos?

89- ¿Una variante afecta sólo a un segmento?

91OpenFeature admite ganchos alrededor de la evaluación de banderas. Son útiles para registrar errores, agregar métricas o vincular la calificación a un trace.

93## Denominación y propiedad

95Los nombres importan. `new_ui` no dice nada. `checkout.v2.enabled` dice mucho más.

97Para cada bandera marcaría al menos:

99- nombre;

100- descripción;

101- dueño;

102- valor predeterminado seguro;

103- razón por la que existe;

104- fecha o condición de expulsión.

105

106Una bandera sin dueño es casi siempre una bandera que nadie borrará.

107

108## Dónde evaluarlos

109

110¿Frontend, backend o borde? Depende.

111

112Si la bandera es para diseño, copia o incorporación, la interfaz está bien. Si se trata de permisos, facturación, límites o datos confidenciales, debe estar en el backend. Si se trata de experimentos de enrutamiento o de mucho tráfico, la ventaja puede tener sentido.

113

114La regla simple: el frontend puede mejorar la experiencia, pero no debería ser la única barrera de seguridad.

115

116## Conclusión

117

118Los feature flag bien hechos cambian la relación con la producción. No eliminan el riesgo, pero lo hacen más pequeño y manejable. Puedes soltar en rodajas, observar, detenerte, retroceder, aprender.

119

120OpenFeature agrega una base limpia: un API común, proveedores intercambiables y una forma más ordenada de hacer crecer el sistema. Pero la disciplina sigue siendo tuya: valores predeterminados seguros, nombres claros, métricas, propietarios y limpieza.

121

122La mejor bandera es la que te ayuda a soltar con calma y luego desaparece cuando ya no es necesaria.

123

124## Fuentes

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