הפריסה היא כאשר הקוד מגיע לייצור. שחרור הוא כאשר מישהו באמת יכול להשתמש בו. בלבול בין השניים הוא אחת הדרכים המהירות ביותר להפוך כל פריסה לרגע מתוח מעט.
feature flag משמשים להצבת רווח בין שני הרגעים הללו. אתה יכול לפרוס היום, להפעיל מחר עבור הצוות הפנימי, לאחר מכן עבור לקוח פיילוט, ולאחר מכן עבור 10% מהמשתמשים. אם משהו משתבש, כבה את הדגל. אתה לא בהכרח צריך להחזיר את כל המהדורה לאחור.
הדגל הוא לא רק אם
טכנית זה לרוב if. מבחינה תרבותית זה הרבה יותר.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
if הקטן הזה יכול לייצג השקה הדרגתית, ניסוי, הגירה, אישור ארגוני או kill switch תפעולי. הבעיה היא שאם אתה לא מנהל את זה טוב, זה יכול להפוך גם לחוב טכני שנשאר בקוד שנתיים.
היכן נכנס OpenFeature
OpenFeature הוא מפרט פתוח להערכת feature flag עם API משותף. הרעיון הוא פשוט: קוד היישום שלך לא אמור להיות תלוי ישירות בספק או במערכת הפנימית שבה אתה משתמש עבור דגלים.
האפליקציה שואלת:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
הספק מחליט מהיכן מגיעים הכללים: SaaS, קובץ, שירות פנימי, flagd, תצורת GitOps. אם יום אחד תשנה את הקצה האחורי של סימון תכונה, האפליקציה לא חייבת להיכתב מחדש בכל מקום.
ההפרדה הזו נראית כמו פרט אדריכלי, אבל היא מורגשת ככל שהפרויקט גדל.
ההקשר הוא חצי מהקרב
דגל הפעלה או כיבוי לכולם הוא שימושי, אך מוגבל. חיי משלוח מתקדמים בהקשר:
- משתמש פנימי או חיצוני;
- תוכנית חינמית או ארגונית;
- כפר;
- ארגון;
- גרסת האפליקציה;
- אחוז תעבורה יציב.
המפתח החשוב הוא targetingKey: עליו להיות יציב. אם זה משתנה עם כל בקשה, משתמש יכול להגיע פעם אחת בגרסה A ופעם אחת בגרסה B. עבור ניסוי זה נורא, עבור קופה זה יכול להיות הרסני.
השקה הגיונית
זרימה שאני אוהב היא זו:
- לפרוס עם הדגל כבוי;
- הצתה למפתחים ו-QA;
- הפעלה ללקוח טייס או לשוכר;
- השקה של 5%;
- השקה ב-25%;
- השקה של 100%;
- הסרת קוד ודגל ישנים.
הנקודה שנשכחת לעתים קרובות היא האחרונה. לדגל זמני חייב להיות תאריך פטירה. אם זה יישאר לנצח, כל רפקטור עתידי יצטרך לשאול: "אבל האם הענף הזה עדיין שימושי?".
Kill switch: הכינו אותם קודם
ה-kill switch הוא הדגל שמציל אותך כאשר תלות חיצונית מתחילה להתעסק איתך, עבודה צורכת יותר מדי משאבים, או היגיון חדש מייצר שגיאות מוזרות.
kill switch טוב חייב להיות:
- קל למצוא;
- מתועד בספר ההפעלה;
- נבדק מדי פעם;
- ניתן לצפייה כאשר מופעל;
- עצמאי, ככל האפשר, מהחלק שעלול להישבר.
הדבר הגרוע ביותר הוא לגלות במהלך התאונה שהדגל קיים, אבל אף אחד לא יודע אם הוא עדיין עובד.
יכולת צפייה או לא מסירה מתקדמת
הפעלת תכונה ב-10% מבלי להסתכל על מדדים היא רק אופטימיות עם מספר שלבים.
כל השקה צריכה לענות על שאלות פשוטות:
- האם השגיאות גדלו?
- האם השהיה השתנה?
- האם משתמשים משלימים את הזרימה?
- האם יש עוד כרטיסים או ניסיונות חוזרים?
- האם גרסה משפיעה רק על פלח אחד?
OpenFeature תומך בווים סביב הערכת דגל. הם שימושיים לרישום שגיאות, הוספת מדדים או קישור הדירוג ל-trace.
מתן שמות ובעלות
שמות חשובים. new_ui לא אומר כלום. checkout.v2.enabled אומר הרבה יותר.
עבור כל דגל הייתי מסמן לפחות:
- שם;
- תיאור;
- בעלים;
- ברירת מחדל בטוחה;
- סיבה מדוע הוא קיים;
- תאריך או מצב ההסרה.
דגל ללא בעלים הוא כמעט תמיד דגל שאף אחד לא ינוק.
היכן להעריך אותם
Frontend, Backend או Edge? תלוי.
אם הדגל מיועד לפריסה, להעתקה או לכניסה, החזית תקין. אם זה נוגע להרשאות, חיוב, מגבלות או נתונים רגישים, זה חייב להיות בצד האחורי. אם זה כולל ניתוב או ניסויים עם תנועה גבוהה, הקצה עשוי להיות הגיוני.
הכלל הפשוט: ה-frontend יכול לשפר את החוויה, אבל זה לא אמור להיות מחסום האבטחה היחיד.
מסקנה
ה-feature flag שנעשה היטב משנה את הקשר עם הייצור. הם לא מבטלים את הסיכון, אבל הם הופכים אותו לקטן יותר וניתן לניהול. אפשר לשחרר בפרוסות, להתבונן, לעצור, לחזור, ללמוד.
OpenFeature מוסיף בסיס נקי: API משותף, ספקים ניתנים להחלפה, ודרך מסודרת יותר להצמיח את המערכת. אבל המשמעת נשארת שלך: ברירות מחדל בטוחות, שמות ברורים, מדדים, בעלים וניקיון.
הדגל הטוב ביותר הוא זה שעוזר לך להשתחרר ברוגע ואז נעלם כשאין בו צורך יותר.