Feature flag: ปล่อยโดยไม่กลั้นหายใจ

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

:Feature flag: ปล่อยโดยไม่กลั้นหายใจlines 1-131 (END) — press 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}

15return oldCheckout(input);

16```

18`if` เล็กๆ น้อยๆ นั้นสามารถแสดงถึงการเปิดตัวแบบค่อยเป็นค่อยไป การทดลอง การย้ายข้อมูล ใบอนุญาตองค์กร หรือการดำเนินการ kill switch ปัญหาคือหากคุณจัดการไม่ดีก็อาจกลายเป็นหนี้ทางเทคนิคที่ค้างอยู่ในโค้ดเป็นเวลาสองปีได้

20## OpenFeature เข้ามาที่ไหน

22OpenFeature เป็นข้อกำหนดแบบเปิดสำหรับการประเมิน feature flag ด้วย API ทั่วไป แนวคิดนั้นง่ายมาก: รหัสแอปพลิเคชันของคุณไม่ควรขึ้นอยู่กับผู้จำหน่ายหรือระบบภายในที่คุณใช้สำหรับแฟล็กโดยตรง

24แอพถามว่า:

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

34ผู้ให้บริการเป็นผู้ตัดสินใจว่ากฎมาจากไหน: SaaS, ไฟล์, บริการภายใน, ติดธง, การกำหนดค่า GitOps หากวันหนึ่งคุณเปลี่ยนแบ็กเอนด์การแฟล็กคุณลักษณะ ไม่จำเป็นต้องเขียนแอปพลิเคชันใหม่ทุกที่

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

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

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

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

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

44- หมู่บ้าน;

45- องค์กร;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

71- หาง่าย

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

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

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

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

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

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

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

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

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

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

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

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

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

91OpenFeature รองรับ hooks รอบการประเมินค่าสถานะ มีประโยชน์สำหรับการบันทึกข้อผิดพลาด การเพิ่มตัวชี้วัด หรือการเชื่อมโยงคะแนนไปที่ trace

93## การตั้งชื่อและความเป็นเจ้าของ

95ชื่อมีความสำคัญ `new_ui` ไม่พูดอะไรเลย `checkout.v2.enabled` พูดได้มากกว่านั้นมาก

97สำหรับแต่ละธง ฉันจะทำเครื่องหมายอย่างน้อย:

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