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, ไฟล์, บริการภายใน, ติดธง, การกำหนดค่า GitOps หากวันหนึ่งคุณเปลี่ยนแบ็กเอนด์การแฟล็กคุณลักษณะ ไม่จำเป็นต้องเขียนแอปพลิเคชันใหม่ทุกที่
35~
36การแยกนี้ดูเหมือนเป็นรายละเอียดทางสถาปัตยกรรม แต่จะรู้สึกได้เมื่อโครงการเติบโตขึ้น
37~
38## บริบทมีชัยไปกว่าครึ่ง
39~
40การเปิดหรือปิดแฟล็กสำหรับทุกคนนั้นมีประโยชน์ แต่ก็มีข้อจำกัด ชีวิตการส่งมอบแบบก้าวหน้าในบริบท:
41~
42- ผู้ใช้ภายในหรือภายนอก
43- แผนฟรีหรือแผนองค์กร
44- หมู่บ้าน;
45- องค์กร;
46- เวอร์ชันแอป;
47- เปอร์เซ็นต์การรับส่งข้อมูลที่มั่นคง
48~
49คีย์สำคัญคือ `targetingKey`: จะต้องมีเสถียรภาพ หากมีการเปลี่ยนแปลงในทุกคำขอ ผู้ใช้อาจจบลงที่ตัวแปร A หนึ่งครั้งและอีกครั้งในตัวแปร B สำหรับการทดสอบนั้นแย่มาก แต่สำหรับการชำระเงินก็อาจเป็นหายนะได้
50~
51## การเปิดตัวที่สมเหตุสมผล
52~
53กระแสที่ฉันชอบคือ:
54~
551. ปรับใช้โดยปิดแฟล็ก;
562. การจุดระเบิดสำหรับนักพัฒนาและ QA;
573. การเปิดเครื่องสำหรับลูกค้านำร่องหรือผู้เช่า
584. การเปิดตัว 5%;
595. การเปิดตัวที่ 25%;
606. การเปิดตัว 100%;
617. การลบโค้ดและแฟล็กเก่าออก
62~
63จุดที่ถูกลืมบ่อยๆคือจุดสุดท้าย ธงชั่วคราวต้องมีวันตาย ถ้ามันคงอยู่ตลอดไป ทุก ๆ refactor ในอนาคตจะต้องถามว่า: "แต่สาขานี้ยังมีประโยชน์อยู่หรือไม่"
64~
65## Kill switch: เตรียมตัวให้พร้อมก่อน
66~
67kill switch คือแฟล็กที่ช่วยคุณเมื่อการพึ่งพาภายนอกเริ่มรบกวนคุณ งานใช้ทรัพยากรมากเกินไป หรือตรรกะใหม่ทำให้เกิดข้อผิดพลาดแปลกๆ
68~
69kill switch ที่ดีจะต้องเป็น:
70~
71- หาง่าย
72- บันทึกไว้ใน runbook;
73- ทดสอบเป็นครั้งคราว
74- สังเกตได้เมื่อเปิดใช้งาน;
75- เป็นอิสระจากส่วนที่อาจแตกหักได้มากที่สุด
76~
77สิ่งที่เลวร้ายที่สุดคือการค้นพบระหว่างเกิดอุบัติเหตุว่ามีธงอยู่ แต่ไม่มีใครรู้ว่าธงยังใช้งานได้อยู่หรือไม่
78~
79## การสังเกตหรือการส่งมอบไม่ก้าวหน้า
80~
81การเปิดคุณลักษณะที่ 10% โดยไม่ดูเมตริกเป็นเพียงการมองโลกในแง่ดีด้วยหลายขั้นตอน
82~
83การเปิดตัวแต่ละครั้งควรตอบคำถามง่ายๆ ดังนี้
84~
85- มีข้อผิดพลาดเพิ่มขึ้นหรือไม่?
86- เวลาแฝงมีการเปลี่ยนแปลงหรือไม่?
87- ผู้ใช้ทำโฟลว์เสร็จสมบูรณ์หรือไม่?
88- มีตั๋วเพิ่มเติมหรือลองอีกครั้งหรือไม่
89- ตัวแปรหนึ่งส่งผลกระทบเพียงเซ็กเมนต์เดียวหรือไม่
90~
91OpenFeature รองรับ hooks รอบการประเมินค่าสถานะ มีประโยชน์สำหรับการบันทึกข้อผิดพลาด การเพิ่มตัวชี้วัด หรือการเชื่อมโยงคะแนนไปที่ 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หากแฟล็กมีไว้สำหรับเลย์เอาต์ คัดลอก หรือการเริ่มต้นใช้งาน ส่วนหน้าก็ใช้ได้ หากเกี่ยวข้องกับสิทธิ์ การเรียกเก็บเงิน ขีดจำกัด หรือข้อมูลที่ละเอียดอ่อน จะต้องอยู่ในแบ็กเอนด์ หากเกี่ยวข้องกับการทดลองการกำหนดเส้นทางหรือการรับส่งข้อมูลสูง Edge อาจสมเหตุสมผล
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, ไฟล์, บริการภายใน, ติดธง, การกำหนดค่า GitOps หากวันหนึ่งคุณเปลี่ยนแบ็กเอนด์การแฟล็กคุณลักษณะ ไม่จำเป็นต้องเขียนแอปพลิเคชันใหม่ทุกที่

35~

36การแยกนี้ดูเหมือนเป็นรายละเอียดทางสถาปัตยกรรม แต่จะรู้สึกได้เมื่อโครงการเติบโตขึ้น

37~

38## บริบทมีชัยไปกว่าครึ่ง

39~

40การเปิดหรือปิดแฟล็กสำหรับทุกคนนั้นมีประโยชน์ แต่ก็มีข้อจำกัด ชีวิตการส่งมอบแบบก้าวหน้าในบริบท:

41~

42- ผู้ใช้ภายในหรือภายนอก

43- แผนฟรีหรือแผนองค์กร

44- หมู่บ้าน;

45- องค์กร;

46- เวอร์ชันแอป;

47- เปอร์เซ็นต์การรับส่งข้อมูลที่มั่นคง

48~

49คีย์สำคัญคือ `targetingKey`: จะต้องมีเสถียรภาพ หากมีการเปลี่ยนแปลงในทุกคำขอ ผู้ใช้อาจจบลงที่ตัวแปร A หนึ่งครั้งและอีกครั้งในตัวแปร B สำหรับการทดสอบนั้นแย่มาก แต่สำหรับการชำระเงินก็อาจเป็นหายนะได้

50~

51## การเปิดตัวที่สมเหตุสมผล

52~

53กระแสที่ฉันชอบคือ:

54~

551. ปรับใช้โดยปิดแฟล็ก;

562. การจุดระเบิดสำหรับนักพัฒนาและ QA;

573. การเปิดเครื่องสำหรับลูกค้านำร่องหรือผู้เช่า

584. การเปิดตัว 5%;

595. การเปิดตัวที่ 25%;

606. การเปิดตัว 100%;

617. การลบโค้ดและแฟล็กเก่าออก

62~

63จุดที่ถูกลืมบ่อยๆคือจุดสุดท้าย ธงชั่วคราวต้องมีวันตาย ถ้ามันคงอยู่ตลอดไป ทุก ๆ refactor ในอนาคตจะต้องถามว่า: "แต่สาขานี้ยังมีประโยชน์อยู่หรือไม่"

64~

65## Kill switch: เตรียมตัวให้พร้อมก่อน

66~

67kill switch คือแฟล็กที่ช่วยคุณเมื่อการพึ่งพาภายนอกเริ่มรบกวนคุณ งานใช้ทรัพยากรมากเกินไป หรือตรรกะใหม่ทำให้เกิดข้อผิดพลาดแปลกๆ

68~

69kill switch ที่ดีจะต้องเป็น:

70~

71- หาง่าย

72- บันทึกไว้ใน runbook;

73- ทดสอบเป็นครั้งคราว

74- สังเกตได้เมื่อเปิดใช้งาน;

75- เป็นอิสระจากส่วนที่อาจแตกหักได้มากที่สุด

76~

77สิ่งที่เลวร้ายที่สุดคือการค้นพบระหว่างเกิดอุบัติเหตุว่ามีธงอยู่ แต่ไม่มีใครรู้ว่าธงยังใช้งานได้อยู่หรือไม่

78~

79## การสังเกตหรือการส่งมอบไม่ก้าวหน้า

80~

81การเปิดคุณลักษณะที่ 10% โดยไม่ดูเมตริกเป็นเพียงการมองโลกในแง่ดีด้วยหลายขั้นตอน

82~

83การเปิดตัวแต่ละครั้งควรตอบคำถามง่ายๆ ดังนี้

84~

85- มีข้อผิดพลาดเพิ่มขึ้นหรือไม่?

86- เวลาแฝงมีการเปลี่ยนแปลงหรือไม่?

87- ผู้ใช้ทำโฟลว์เสร็จสมบูรณ์หรือไม่?

88- มีตั๋วเพิ่มเติมหรือลองอีกครั้งหรือไม่

89- ตัวแปรหนึ่งส่งผลกระทบเพียงเซ็กเมนต์เดียวหรือไม่

90~

91OpenFeature รองรับ hooks รอบการประเมินค่าสถานะ มีประโยชน์สำหรับการบันทึกข้อผิดพลาด การเพิ่มตัวชี้วัด หรือการเชื่อมโยงคะแนนไปที่ 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หากแฟล็กมีไว้สำหรับเลย์เอาต์ คัดลอก หรือการเริ่มต้นใช้งาน ส่วนหน้าก็ใช้ได้ หากเกี่ยวข้องกับสิทธิ์ การเรียกเก็บเงิน ขีดจำกัด หรือข้อมูลที่ละเอียดอ่อน จะต้องอยู่ในแบ็กเอนด์ หากเกี่ยวข้องกับการทดลองการกำหนดเส้นทางหรือการรับส่งข้อมูลสูง Edge อาจสมเหตุสมผล

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~