Feature flag: відпустіть, не затримуючи дихання

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

1~
2Розгортання – це коли код надходить у виробництво. Звільнення – це коли хтось дійсно може цим скористатися. Сплутати ці два – один із найшвидших способів зробити кожне розгортання трохи напруженим моментом.
3~
4feature flag служить для розміщення проміжку між цими двома моментами. Ви можете розгорнути сьогодні, завтра розпочати роботу для внутрішньої команди, потім для пілотного клієнта, потім для 10% користувачів. Якщо щось піде не так, вимкніть прапор. Вам не обов’язково відкочувати весь випуск.
5~
6## Прапор - це не просто якщо
7~
8Технічно це часто `if`. Культурно це набагато більше.
9~
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14~
15return oldCheckout(input);
16```
17~
18Цей маленький `if` може означати поступове розгортання, експеримент, міграцію, дозвіл підприємства або операційну kill switch. Проблема полягає в тому, що якщо ви не керуєте ним належним чином, це також може стати технічним боргом, який залишається в коді протягом двох років.
19~
20## Де тут OpenFeature
21~
22OpenFeature є відкритою специфікацією для оцінки feature flag із загальним API. Ідея проста: ваш код програми не повинен залежати безпосередньо від постачальника або внутрішньої системи, яку ви використовуєте для прапорів.
23~
24Додаток запитує:
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~
34Постачальник вирішує, звідки беруться правила: SaaS, файл, внутрішня служба, flagd, конфігурація GitOps. Якщо одного дня ви зміните бекенд позначення функцій, програму не доведеться переписувати всюди.
35~
36Це поділ здається архітектурною деталлю, але це відчувається в міру того, як проект росте.
37~
38## Контекст — половина успіху
39~
40Прапор увімкнення чи вимкнення для всіх корисний, але обмежений. Прогресивне постачання живе в контексті:
41~
42- внутрішній або зовнішній користувач;
43- вільний або корпоративний план;
44- село;
45- організованість;
46- версія програми;
47- стабільний відсоток трафіку.
48~
49Важлива клавіша `targetingKey`: вона має бути стабільною. Якщо він змінюється з кожним запитом, користувач може опинитися один раз у варіанті А і один раз у варіанті Б. Для експерименту це жахливо, для перевірки це може бути катастрофічним.
50~
51## Розумне впровадження
52~
53Потік, який мені подобається, такий:
54~
551. розгорнути зі знятим прапором;
562. запалювання для розробників і QA;
573. включення для пілотного замовника або орендаря;
584. 5% розгортання;
595. розгортання на 25%;
606. 100% розгортання;
617. видалення старого коду та прапора.
62~
63Останній пункт, про який часто забувають. Тимчасовий прапор повинен мати дату смерті. Якщо це залишиться назавжди, кожному майбутньому рефактору доведеться запитати: «а чи ця гілка все ще корисна?».
64~
65## Kill switch: спочатку приготуйте їх
66~
67kill switch — це прапорець, який рятує вас, коли зовнішня залежність починає заважати вам, робота споживає забагато ресурсів або нова логіка породжує дивні помилки.
68~
69Хороший kill switch має бути:
70~
71- легко знайти;
72- задокументовано в журналі операцій;
73- тестується час від часу;
74- спостерігаються при активації;
75- незалежно, наскільки це можливо, від частини, яка може зламатися.
76~
77Найгірше під час аварії виявити, що прапор є, але ніхто не знає, чи він досі працює.
78~
79## Спостережуваність чи не прогресивна доставка
80~
81Увімкнути функцію на 10%, не дивлячись на показники, — це лише оптимізм із кількома кроками.
82~
83Кожен випуск має відповідати на прості запитання:
84~
85- чи побільшало помилок?
86- чи змінилася затримка?
87- чи завершують користувачі потік?
88- є ще квитки чи повторні спроби?
89- чи впливає варіант лише на один сегмент?
90~
91OpenFeature підтримує хуки навколо оцінки прапора. Вони корисні для реєстрації помилок, додавання показників або зв’язування рейтингу з trace.
92~
93## Назва та право власності
94~
95Імена мають значення. `new_ui` нічого не говорить. `checkout.v2.enabled` говорить набагато більше.
96~
97Для кожного прапора я б позначив принаймні:
98~
99- ім'я;
100- опис;
101- власник;
102- безпечний дефолт;
103- причина його існування;
104- дата або умова вилучення.
105~
106Безхазяйний прапор – це майже завжди прапор, який ніхто не зніме.
107~
108## Де їх оцінити
109~
110Frontend, backend чи edge? Залежить.
111~
112Якщо прапорець для макета, копіювання або адаптації, інтерфейс підійде. Якщо це стосується дозволів, виставлення рахунків, лімітів або конфіденційних даних, це має бути на сервері. Якщо це стосується маршрутизації або експериментів із високим трафіком, перевага може мати сенс.
113~
114Просте правило: інтерфейс може покращити досвід, але він не повинен бути єдиним бар’єром безпеки.
115~
116## Висновок
117~
118feature flag зроблено добре змінює відносини з виробництвом. Вони не усувають ризик, але роблять його меншим і більш керованим. Ви можете випускати фрагменти, спостерігати, зупинятися, повертатися назад, вчитися.
119~
120OpenFeature додає чисту основу: загальний API, взаємозамінних постачальників і більш охайний спосіб розвитку системи. Але дисципліна залишається за вами: безпечні параметри за замовчуванням, чіткі імена, показники, власники та чистота.
121~
122Найкращий прапор – це той, який допомагає спокійно звільнитися, а потім зникає, коли він більше не потрібен.
123~
124## Джерела
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

2Розгортання – це коли код надходить у виробництво. Звільнення – це коли хтось дійсно може цим скористатися. Сплутати ці два – один із найшвидших способів зробити кожне розгортання трохи напруженим моментом.

4feature flag служить для розміщення проміжку між цими двома моментами. Ви можете розгорнути сьогодні, завтра розпочати роботу для внутрішньої команди, потім для пілотного клієнта, потім для 10% користувачів. Якщо щось піде не так, вимкніть прапор. Вам не обов’язково відкочувати весь випуск.

6## Прапор - це не просто якщо

8Технічно це часто `if`. Культурно це набагато більше.

10```typescript

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

12 return newCheckout(input);

13}

14~

15return oldCheckout(input);

16```

17~

18Цей маленький `if` може означати поступове розгортання, експеримент, міграцію, дозвіл підприємства або операційну kill switch. Проблема полягає в тому, що якщо ви не керуєте ним належним чином, це також може стати технічним боргом, який залишається в коді протягом двох років.

19~

20## Де тут OpenFeature

21~

22OpenFeature є відкритою специфікацією для оцінки feature flag із загальним API. Ідея проста: ваш код програми не повинен залежати безпосередньо від постачальника або внутрішньої системи, яку ви використовуєте для прапорів.

23~

24Додаток запитує:

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~

34Постачальник вирішує, звідки беруться правила: SaaS, файл, внутрішня служба, flagd, конфігурація GitOps. Якщо одного дня ви зміните бекенд позначення функцій, програму не доведеться переписувати всюди.

35~

36Це поділ здається архітектурною деталлю, але це відчувається в міру того, як проект росте.

37~

38## Контекст — половина успіху

39~

40Прапор увімкнення чи вимкнення для всіх корисний, але обмежений. Прогресивне постачання живе в контексті:

41~

42- внутрішній або зовнішній користувач;

43- вільний або корпоративний план;

44- село;

45- організованість;

46- версія програми;

47- стабільний відсоток трафіку.

48~

49Важлива клавіша `targetingKey`: вона має бути стабільною. Якщо він змінюється з кожним запитом, користувач може опинитися один раз у варіанті А і один раз у варіанті Б. Для експерименту це жахливо, для перевірки це може бути катастрофічним.

50~

51## Розумне впровадження

52~

53Потік, який мені подобається, такий:

54~

551. розгорнути зі знятим прапором;

562. запалювання для розробників і QA;

573. включення для пілотного замовника або орендаря;

584. 5% розгортання;

595. розгортання на 25%;

606. 100% розгортання;

617. видалення старого коду та прапора.

62~

63Останній пункт, про який часто забувають. Тимчасовий прапор повинен мати дату смерті. Якщо це залишиться назавжди, кожному майбутньому рефактору доведеться запитати: «а чи ця гілка все ще корисна?».

64~

65## Kill switch: спочатку приготуйте їх

66~

67kill switch — це прапорець, який рятує вас, коли зовнішня залежність починає заважати вам, робота споживає забагато ресурсів або нова логіка породжує дивні помилки.

68~

69Хороший kill switch має бути:

70~

71- легко знайти;

72- задокументовано в журналі операцій;

73- тестується час від часу;

74- спостерігаються при активації;

75- незалежно, наскільки це можливо, від частини, яка може зламатися.

76~

77Найгірше під час аварії виявити, що прапор є, але ніхто не знає, чи він досі працює.

78~

79## Спостережуваність чи не прогресивна доставка

80~

81Увімкнути функцію на 10%, не дивлячись на показники, — це лише оптимізм із кількома кроками.

82~

83Кожен випуск має відповідати на прості запитання:

84~

85- чи побільшало помилок?

86- чи змінилася затримка?

87- чи завершують користувачі потік?

88- є ще квитки чи повторні спроби?

89- чи впливає варіант лише на один сегмент?

90~

91OpenFeature підтримує хуки навколо оцінки прапора. Вони корисні для реєстрації помилок, додавання показників або зв’язування рейтингу з trace.

92~

93## Назва та право власності

94~

95Імена мають значення. `new_ui` нічого не говорить. `checkout.v2.enabled` говорить набагато більше.

96~

97Для кожного прапора я б позначив принаймні:

98~

99- ім'я;

100- опис;

101- власник;

102- безпечний дефолт;

103- причина його існування;

104- дата або умова вилучення.

105~

106Безхазяйний прапор – це майже завжди прапор, який ніхто не зніме.

107~

108## Де їх оцінити

109~

110Frontend, backend чи edge? Залежить.

111~

112Якщо прапорець для макета, копіювання або адаптації, інтерфейс підійде. Якщо це стосується дозволів, виставлення рахунків, лімітів або конфіденційних даних, це має бути на сервері. Якщо це стосується маршрутизації або експериментів із високим трафіком, перевага може мати сенс.

113~

114Просте правило: інтерфейс може покращити досвід, але він не повинен бути єдиним бар’єром безпеки.

115~

116## Висновок

117~

118feature flag зроблено добре змінює відносини з виробництвом. Вони не усувають ризик, але роблять його меншим і більш керованим. Ви можете випускати фрагменти, спостерігати, зупинятися, повертатися назад, вчитися.

119~

120OpenFeature додає чисту основу: загальний API, взаємозамінних постачальників і більш охайний спосіб розвитку системи. Але дисципліна залишається за вами: безпечні параметри за замовчуванням, чіткі імена, показники, власники та чистота.

121~

122Найкращий прапор – це той, який допомагає спокійно звільнитися, а потім зникає, коли він більше не потрібен.

123~

124## Джерела

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~