Feature flag: thả ra mà không nín thở

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

1 
2Triển khai là khi mã được đưa vào sản xuất. Phát hành là khi ai đó thực sự có thể sử dụng nó. Nhầm lẫn cả hai là một trong những cách nhanh nhất khiến mỗi lần triển khai trở nên căng thẳng một chút.
3 
4feature flag dùng để tạo khoảng trống giữa hai khoảnh khắc này. Bạn có thể triển khai ngay hôm nay, khởi động vào ngày mai cho nhóm nội bộ, sau đó cho khách hàng thí điểm, sau đó cho 10% người dùng. Nếu có sự cố xảy ra, hãy tắt cờ. Bạn không nhất thiết phải khôi phục toàn bộ bản phát hành.
5 
6## Cờ không chỉ là nếu
7 
8Về mặt kỹ thuật, nó thường là `if`. Về mặt văn hóa thì còn hơn thế nữa.
9 
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14 
15return oldCheckout(input);
16```
17 
18`if` nhỏ đó có thể đại diện cho việc triển khai dần dần, thử nghiệm, di chuyển, giấy phép doanh nghiệp hoặc kill switch hoạt động. Vấn đề là nếu bạn không quản lý tốt, nó cũng có thể trở thành khoản nợ kỹ thuật tồn tại trong code suốt hai năm.
19 
20## OpenFeature xuất hiện ở đâu
21 
22OpenFeature là thông số kỹ thuật mở để đánh giá feature flag với điểm chung API. Ý tưởng rất đơn giản: mã ứng dụng của bạn không nên phụ thuộc trực tiếp vào nhà cung cấp hoặc hệ thống nội bộ mà bạn sử dụng cho cờ.
23 
24Ứng dụng hỏi:
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 
34Nhà cung cấp quyết định các quy tắc đến từ đâu: SaaS, tệp, dịch vụ nội bộ, gắn cờ, cấu hình GitOps. Nếu một ngày nào đó bạn thay đổi tính năng gắn cờ phụ trợ, ứng dụng sẽ không cần phải viết lại ở mọi nơi.
35 
36Sự tách biệt này có vẻ giống như một chi tiết kiến trúc, nhưng nó được cảm nhận khi dự án phát triển.
37 
38## Bối cảnh là một nửa trận chiến
39 
40Cờ bật hoặc tắt dành cho mọi người đều hữu ích nhưng có giới hạn. Cuộc sống giao hàng tiến bộ trong bối cảnh:
41 
42- người dùng nội bộ hoặc bên ngoài;
43- gói miễn phí hoặc doanh nghiệp;
44- làng bản;
45- tổ chức;
46- phiên bản ứng dụng;
47- Tỷ lệ lưu lượng truy cập ổn định.
48 
49Chìa khóa quan trọng là `targetingKey`: nó phải ổn định. Nếu nó thay đổi theo mọi yêu cầu, người dùng có thể một lần ở biến thể A và một lần ở biến thể B. Đối với một thử nghiệm thì điều đó thật tồi tệ, còn đối với việc thanh toán thì điều đó có thể là thảm họa.
50 
51## Triển khai hợp lý
52 
53Một dòng chảy tôi thích là thế này:
54 
551. triển khai khi tắt cờ;
562. đánh lửa cho các nhà phát triển và QA;
573. bật cho khách hàng hoặc người thuê thí điểm;
584. Triển khai 5%;
595. triển khai ở mức 25%;
606. Triển khai 100%;
617. loại bỏ mã và cờ cũ.
62 
63Điểm thường bị lãng quên là điểm cuối cùng. Một lá cờ tạm thời phải có ngày chết. Nếu nó tồn tại mãi mãi, mọi nhà tái cấu trúc trong tương lai sẽ phải hỏi: "nhưng nhánh này còn hữu ích không?".
64 
65## Kill switch: chuẩn bị trước
66 
67kill switch là cờ giúp bạn cứu nguy khi một phần phụ thuộc bên ngoài bắt đầu làm phiền bạn, một công việc tiêu tốn quá nhiều tài nguyên hoặc logic mới tạo ra các lỗi lạ.
68 
69Điểm kill switch tốt phải là:
70 
71- dễ tìm;
72- được ghi lại trong sổ ghi chép;
73- thỉnh thoảng được thử nghiệm;
74- có thể quan sát được khi được kích hoạt;
75- độc lập, càng xa càng tốt, khỏi phần có thể bị vỡ.
76 
77Điều tồi tệ nhất là trong vụ tai nạn phát hiện ra rằng lá cờ tồn tại nhưng không ai biết liệu nó có còn hoạt động hay không.
78 
79## Khả năng quan sát được hoặc phân phối không lũy tiến
80 
81Bật một tính năng ở mức 10% mà không xem số liệu chỉ là sự lạc quan qua nhiều bước.
82 
83Mỗi lần triển khai phải trả lời các câu hỏi đơn giản:
84 
85- lỗi có tăng lên không?
86- độ trễ có thay đổi không?
87- người dùng có hoàn thành quy trình không?
88- có thêm vé hoặc thử lại không?
89- một biến thể chỉ tác động đến một phân khúc phải không?
90 
91OpenFeature hỗ trợ các móc nối xung quanh việc đánh giá cờ. Chúng rất hữu ích khi ghi lại lỗi, thêm số liệu hoặc liên kết xếp hạng với trace.
92 
93## Đặt tên và quyền sở hữu
94 
95Tên quan trọng. `new_ui` không nói gì. `checkout.v2.enabled` nói lên nhiều điều hơn thế.
96 
97Đối với mỗi lá cờ tôi sẽ đánh dấu ít nhất:
98 
99- tên;
100- Sự miêu tả;
101- người sở hữu;
102- mặc định an toàn;
103- lý do tại sao nó tồn tại;
104- ngày hoặc điều kiện loại bỏ.
105 
106Một lá cờ không có chủ sở hữu hầu như luôn là một lá cờ mà không ai có thể xóa được.
107 
108## Đánh giá chúng ở đâu
109 
110Frontend, backend hay edge? Phụ thuộc.
111 
112Nếu cờ dành cho bố cục, sao chép hoặc giới thiệu thì giao diện người dùng vẫn ổn. Nếu nó liên quan đến quyền, thanh toán, giới hạn hoặc dữ liệu nhạy cảm thì nó phải nằm ở phần phụ trợ. Nếu nó liên quan đến việc định tuyến hoặc thử nghiệm lưu lượng truy cập cao, thì lợi thế có thể có ý nghĩa.
113 
114Quy tắc đơn giản: giao diện người dùng có thể cải thiện trải nghiệm nhưng đó không phải là rào cản bảo mật duy nhất.
115 
116## Kết luận
117 
118Việc feature flag được thực hiện tốt sẽ thay đổi mối quan hệ với sản xuất. Chúng không loại bỏ rủi ro nhưng làm cho nó nhỏ hơn và dễ quản lý hơn. Bạn có thể phát hành theo từng lát, quan sát, dừng lại, quay lại, học hỏi.
119 
120OpenFeature bổ sung một nền tảng sạch: API chung, các nhà cung cấp có thể hoán đổi cho nhau và một cách gọn gàng hơn để phát triển hệ thống. Nhưng kỷ luật vẫn là của bạn: mặc định an toàn, tên rõ ràng, số liệu, chủ sở hữu và độ sạch sẽ.
121 
122Lá cờ tốt nhất là lá cờ giúp bạn thảnh thơi một cách bình tĩnh rồi biến mất khi không còn cần thiết nữa.
123 
124## Nguồn
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: thả ra mà không nín thởlines 1-131 (END) — press q to close

2Triển khai là khi mã được đưa vào sản xuất. Phát hành là khi ai đó thực sự có thể sử dụng nó. Nhầm lẫn cả hai là một trong những cách nhanh nhất khiến mỗi lần triển khai trở nên căng thẳng một chút.

4feature flag dùng để tạo khoảng trống giữa hai khoảnh khắc này. Bạn có thể triển khai ngay hôm nay, khởi động vào ngày mai cho nhóm nội bộ, sau đó cho khách hàng thí điểm, sau đó cho 10% người dùng. Nếu có sự cố xảy ra, hãy tắt cờ. Bạn không nhất thiết phải khôi phục toàn bộ bản phát hành.

6## Cờ không chỉ là nếu

8Về mặt kỹ thuật, nó thường là `if`. Về mặt văn hóa thì còn hơn thế nữa.

10```typescript

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

12 return newCheckout(input);

13}

15return oldCheckout(input);

16```

18`if` nhỏ đó có thể đại diện cho việc triển khai dần dần, thử nghiệm, di chuyển, giấy phép doanh nghiệp hoặc kill switch hoạt động. Vấn đề là nếu bạn không quản lý tốt, nó cũng có thể trở thành khoản nợ kỹ thuật tồn tại trong code suốt hai năm.

20## OpenFeature xuất hiện ở đâu

22OpenFeature là thông số kỹ thuật mở để đánh giá feature flag với điểm chung API. Ý tưởng rất đơn giản: mã ứng dụng của bạn không nên phụ thuộc trực tiếp vào nhà cung cấp hoặc hệ thống nội bộ mà bạn sử dụng cho cờ.

24Ứng dụng hỏi:

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

34Nhà cung cấp quyết định các quy tắc đến từ đâu: SaaS, tệp, dịch vụ nội bộ, gắn cờ, cấu hình GitOps. Nếu một ngày nào đó bạn thay đổi tính năng gắn cờ phụ trợ, ứng dụng sẽ không cần phải viết lại ở mọi nơi.

36Sự tách biệt này có vẻ giống như một chi tiết kiến trúc, nhưng nó được cảm nhận khi dự án phát triển.

38## Bối cảnh là một nửa trận chiến

40Cờ bật hoặc tắt dành cho mọi người đều hữu ích nhưng có giới hạn. Cuộc sống giao hàng tiến bộ trong bối cảnh:

42- người dùng nội bộ hoặc bên ngoài;

43- gói miễn phí hoặc doanh nghiệp;

44- làng bản;

45- tổ chức;

46- phiên bản ứng dụng;

47- Tỷ lệ lưu lượng truy cập ổn định.

49Chìa khóa quan trọng là `targetingKey`: nó phải ổn định. Nếu nó thay đổi theo mọi yêu cầu, người dùng có thể một lần ở biến thể A và một lần ở biến thể B. Đối với một thử nghiệm thì điều đó thật tồi tệ, còn đối với việc thanh toán thì điều đó có thể là thảm họa.

51## Triển khai hợp lý

53Một dòng chảy tôi thích là thế này:

551. triển khai khi tắt cờ;

562. đánh lửa cho các nhà phát triển và QA;

573. bật cho khách hàng hoặc người thuê thí điểm;

584. Triển khai 5%;

595. triển khai ở mức 25%;

606. Triển khai 100%;

617. loại bỏ mã và cờ cũ.

63Điểm thường bị lãng quên là điểm cuối cùng. Một lá cờ tạm thời phải có ngày chết. Nếu nó tồn tại mãi mãi, mọi nhà tái cấu trúc trong tương lai sẽ phải hỏi: "nhưng nhánh này còn hữu ích không?".

65## Kill switch: chuẩn bị trước

67kill switch là cờ giúp bạn cứu nguy khi một phần phụ thuộc bên ngoài bắt đầu làm phiền bạn, một công việc tiêu tốn quá nhiều tài nguyên hoặc logic mới tạo ra các lỗi lạ.

69Điểm kill switch tốt phải là:

71- dễ tìm;

72- được ghi lại trong sổ ghi chép;

73- thỉnh thoảng được thử nghiệm;

74- có thể quan sát được khi được kích hoạt;

75- độc lập, càng xa càng tốt, khỏi phần có thể bị vỡ.

77Điều tồi tệ nhất là trong vụ tai nạn phát hiện ra rằng lá cờ tồn tại nhưng không ai biết liệu nó có còn hoạt động hay không.

79## Khả năng quan sát được hoặc phân phối không lũy tiến

81Bật một tính năng ở mức 10% mà không xem số liệu chỉ là sự lạc quan qua nhiều bước.

83Mỗi lần triển khai phải trả lời các câu hỏi đơn giản:

85- lỗi có tăng lên không?

86- độ trễ có thay đổi không?

87- người dùng có hoàn thành quy trình không?

88- có thêm vé hoặc thử lại không?

89- một biến thể chỉ tác động đến một phân khúc phải không?

91OpenFeature hỗ trợ các móc nối xung quanh việc đánh giá cờ. Chúng rất hữu ích khi ghi lại lỗi, thêm số liệu hoặc liên kết xếp hạng với trace.

93## Đặt tên và quyền sở hữu

95Tên quan trọng. `new_ui` không nói gì. `checkout.v2.enabled` nói lên nhiều điều hơn thế.

97Đối với mỗi lá cờ tôi sẽ đánh dấu ít nhất:

99- tên;

100- Sự miêu tả;

101- người sở hữu;

102- mặc định an toàn;

103- lý do tại sao nó tồn tại;

104- ngày hoặc điều kiện loại bỏ.

105

106Một lá cờ không có chủ sở hữu hầu như luôn là một lá cờ mà không ai có thể xóa được.

107

108## Đánh giá chúng ở đâu

109

110Frontend, backend hay edge? Phụ thuộc.

111

112Nếu cờ dành cho bố cục, sao chép hoặc giới thiệu thì giao diện người dùng vẫn ổn. Nếu nó liên quan đến quyền, thanh toán, giới hạn hoặc dữ liệu nhạy cảm thì nó phải nằm ở phần phụ trợ. Nếu nó liên quan đến việc định tuyến hoặc thử nghiệm lưu lượng truy cập cao, thì lợi thế có thể có ý nghĩa.

113

114Quy tắc đơn giản: giao diện người dùng có thể cải thiện trải nghiệm nhưng đó không phải là rào cản bảo mật duy nhất.

115

116## Kết luận

117

118Việc feature flag được thực hiện tốt sẽ thay đổi mối quan hệ với sản xuất. Chúng không loại bỏ rủi ro nhưng làm cho nó nhỏ hơn và dễ quản lý hơn. Bạn có thể phát hành theo từng lát, quan sát, dừng lại, quay lại, học hỏi.

119

120OpenFeature bổ sung một nền tảng sạch: API chung, các nhà cung cấp có thể hoán đổi cho nhau và một cách gọn gàng hơn để phát triển hệ thống. Nhưng kỷ luật vẫn là của bạn: mặc định an toàn, tên rõ ràng, số liệu, chủ sở hữu và độ sạch sẽ.

121

122Lá cờ tốt nhất là lá cờ giúp bạn thảnh thơi một cách bình tĩnh rồi biến mất khi không còn cần thiết nữa.

123

124## Nguồn

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