Feature flag: 息を止めずに手を放す

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

1~
2デプロイメントは、コードが本番環境に到着したときに行われます。リリースとは、誰かが実際に使用できるようになることです。この 2 つを混同することは、あらゆる展開を少し緊張した瞬間にする最も簡単な方法の 1 つです。
3~
4feature flag は、この 2 つの瞬間の間にスペースを置く役割を果たします。今日導入し、明日は社内チーム、次にパイロット顧客、そして 10% のユーザーに対して導入できます。何か問題が発生した場合は、フラグをオフにします。必ずしもリリース全体をロールバックする必要はありません。
5~
6## フラグは単なる if ではありません
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 を表す可能性があります。問題は、これを適切に管理しないと、コードに 2 年間残る技術的負債になる可能性があることです。
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、ファイル、内部サービス、フラグ、GitOps 構成など、ルールの由来を決定します。ある日、機能フラグを設定するバックエンドを変更したとしても、アプリケーションをどこでも書き直す必要はありません。
35~
36この分離は建築上の細部のように見えますが、プロジェクトが成長するにつれて感じられます。
37~
38## コンテキストが戦いの半分です
39~
40全員に対するオンまたはオフのフラグは便利ですが、制限があります。プログレッシブ配信はコンテキストの中で行われます。
41~
42- 内部または外部ユーザー。
43- 無料プランまたはエンタープライズプラン;
44- 村;
45- 組織;
46- アプリのバージョン;
47- 安定したトラフィックの割合。
48~
49重要な鍵は `targetingKey` です。安定している必要があります。リクエストごとに変更されると、ユーザーは一度はバリアント A に、もう 1 回はバリアント B に陥る可能性があります。実験の場合は最悪ですが、チェックアウトの場合は悲惨な結果になる可能性があります。
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- バリアントは 1 つのセグメントにのみ影響しますか?
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~
110フロントエンド、バックエンド、それともエッジ?場合によります。
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デプロイメントは、コードが本番環境に到着したときに行われます。リリースとは、誰かが実際に使用できるようになることです。この 2 つを混同することは、あらゆる展開を少し緊張した瞬間にする最も簡単な方法の 1 つです。

4feature flag は、この 2 つの瞬間の間にスペースを置く役割を果たします。今日導入し、明日は社内チーム、次にパイロット顧客、そして 10% のユーザーに対して導入できます。何か問題が発生した場合は、フラグをオフにします。必ずしもリリース全体をロールバックする必要はありません。

6## フラグは単なる if ではありません

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 を表す可能性があります。問題は、これを適切に管理しないと、コードに 2 年間残る技術的負債になる可能性があることです。

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、ファイル、内部サービス、フラグ、GitOps 構成など、ルールの由来を決定します。ある日、機能フラグを設定するバックエンドを変更したとしても、アプリケーションをどこでも書き直す必要はありません。

35~

36この分離は建築上の細部のように見えますが、プロジェクトが成長するにつれて感じられます。

37~

38## コンテキストが戦いの半分です

39~

40全員に対するオンまたはオフのフラグは便利ですが、制限があります。プログレッシブ配信はコンテキストの中で行われます。

41~

42- 内部または外部ユーザー。

43- 無料プランまたはエンタープライズプラン;

44- 村;

45- 組織;

46- アプリのバージョン;

47- 安定したトラフィックの割合。

48~

49重要な鍵は `targetingKey` です。安定している必要があります。リクエストごとに変更されると、ユーザーは一度はバリアント A に、もう 1 回はバリアント B に陥る可能性があります。実験の場合は最悪ですが、チェックアウトの場合は悲惨な結果になる可能性があります。

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- バリアントは 1 つのセグメントにのみ影響しますか?

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~

110フロントエンド、バックエンド、それともエッジ?場合によります。

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~