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`: עליו להיות יציב. אם זה משתנה עם כל בקשה, משתמש יכול להגיע פעם אחת בגרסה A ופעם אחת בגרסה B. עבור ניסוי זה נורא, עבור קופה זה יכול להיות הרסני.
50~
51## השקה הגיונית
52~
53זרימה שאני אוהב היא זו:
54~
551. לפרוס עם הדגל כבוי;
562. הצתה למפתחים ו-QA;
573. הפעלה ללקוח טייס או לשוכר;
584. השקה של 5%;
595. השקה ב-25%;
606. השקה של 100%;
617. הסרת קוד ודגל ישנים.
62~
63הנקודה שנשכחת לעתים קרובות היא האחרונה. לדגל זמני חייב להיות תאריך פטירה. אם זה יישאר לנצח, כל רפקטור עתידי יצטרך לשאול: "אבל האם הענף הזה עדיין שימושי?".
64~
65## Kill switch: הכינו אותם קודם
66~
67ה-kill switch הוא הדגל שמציל אותך כאשר תלות חיצונית מתחילה להתעסק איתך, עבודה צורכת יותר מדי משאבים, או היגיון חדש מייצר שגיאות מוזרות.
68~
69kill 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הכלל הפשוט: ה-frontend יכול לשפר את החוויה, אבל זה לא אמור להיות מחסום האבטחה היחיד.
115~
116## מסקנה
117~
118ה-feature 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`: עליו להיות יציב. אם זה משתנה עם כל בקשה, משתמש יכול להגיע פעם אחת בגרסה A ופעם אחת בגרסה B. עבור ניסוי זה נורא, עבור קופה זה יכול להיות הרסני.

50~

51## השקה הגיונית

52~

53זרימה שאני אוהב היא זו:

54~

551. לפרוס עם הדגל כבוי;

562. הצתה למפתחים ו-QA;

573. הפעלה ללקוח טייס או לשוכר;

584. השקה של 5%;

595. השקה ב-25%;

606. השקה של 100%;

617. הסרת קוד ודגל ישנים.

62~

63הנקודה שנשכחת לעתים קרובות היא האחרונה. לדגל זמני חייב להיות תאריך פטירה. אם זה יישאר לנצח, כל רפקטור עתידי יצטרך לשאול: "אבל האם הענף הזה עדיין שימושי?".

64~

65## Kill switch: הכינו אותם קודם

66~

67ה-kill switch הוא הדגל שמציל אותך כאשר תלות חיצונית מתחילה להתעסק איתך, עבודה צורכת יותר מדי משאבים, או היגיון חדש מייצר שגיאות מוזרות.

68~

69kill 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הכלל הפשוט: ה-frontend יכול לשפר את החוויה, אבל זה לא אמור להיות מחסום האבטחה היחיד.

115~

116## מסקנה

117~

118ה-feature 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~