Feature flag: suelta sin contener la respiración

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

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

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~