דגלי פיצ'רים - Feature Flags מוסבר - איך משחררים פיצ'רים בבטחה

תארו לעצמכם שסיימתם לבנות פיצ'ר גדול, בדקתם אותו, והוא מוכן. עכשיו מגיע הרגע המפחיד - לשחרר אותו לכל המשתמשים בבת אחת ולקוות לטוב, או למצוא דרך זהירה יותר. פה בדיוק נכנסים Feature Flags, אחד הכלים הפשוטים והשימושיים ביותר שיש לצוותי פיתוח כדי להוריד את הפחד מהרגע הזה.

מה זה בעצם דגל תכונה

במהותו, feature flag הוא סוויץ' פשוט, כן או לא, שקובע האם קטע קוד מסוים פעיל או לא. הדגל עצמו לרוב נשמר במסד נתונים או בשירות תצורה ייעודי, לא בקוד עצמו, כדי שאפשר יהיה לשנות אותו בלי לגעת בקוד בכלל. בקוד, זה נראה בערך כמו if (flags.isEnabled("new_checkout")) - הרצה של הגרסה החדשה של הפיצ'ר רק אם הדגל דלוק, ואחרת נופלים חזרה להתנהגות הישנה.

הפרדה בין דיפלוי לשחרור

הרעיון המרכזי שדגלי תכונה מאפשרים הוא הפרדה בין שני דברים שאנשים נוטים לחשוב עליהם כאילו הם אותו הדבר - deploy ו-release. deploy הוא הרגע שבו הקוד החדש מגיע לשרתי הפרודקשן. release הוא הרגע שבו משתמשים אמיתיים מתחילים לראות ולהשתמש בפיצ'ר.

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

שחרור הדרגתי

אחד השימושים הכי נפוצים בדגלי תכונה הוא שחרור הדרגתי. במקום להדליק את הדגל לכל המשתמשים בבת אחת, מדליקים אותו קודם לאחוז קטן - נגיד, קבוצת בדיקה פנימית, ואז חלק קטן מהמשתמשים האמיתיים. אם הכל נראה תקין, מגדילים בהדרגה את האחוז, עד שהפיצ'ר פעיל אצל כולם.

היתרון הגדול בגישה הזאת הוא שאם משהו משתבש, הנזק מוגבל לקבוצה קטנה, ולא לכל בסיס המשתמשים. אתם מגלים בעיות מוקדם, עם חשיפה מבוקרת, במקום לגלות אותן אחרי שכולם כבר נתקלו בהן.

מתג כיבוי מיידי

היתרון השני, ולפעמים החשוב מכולם, הוא שדגל תכונה יכול לשמש כמתג כיבוי - kill switch. אם פיצ'ר שכבר שוחרר מתגלה כבעייתי - איטי מדי, שובר משהו, או פשוט מתנהג לא כמו שציפיתם - אפשר לכבות אותו מיידית על ידי הפיכת הדגל ללא פעיל, בלי לבצע rollback מלא ובלי דיפלוי חדש. זה ההבדל בין תיקון שלוקח דקות לתיקון שלוקח שעה או יותר, בזמן שהמשתמשים חווים את הבעיה.

חשוב לציין שדגלי תכונה הם טכניקה ברמת הקוד, בעוד שטכניקות כמו blue-green deployment או canary release הן טכניקות ברמת התשתית, ששולטות בתעבורה בין גרסאות שרת שלמות. הן פותרות בעיה דומה בכיוון קצת שונה, וברוב הצוותים הבשלים משתמשים בשתי הגישות ביחד, לא בוחרים אחת על חשבון השנייה.

החוב הנשכח - דגלים ישנים

הבעיה שהכי הרבה צוותים מתעלמים ממנה בהתחלה היא מה קורה אחרי שהפיצ'ר כבר שוחרר במלואו ויציב אצל כולם. הדגל, מבחינה טכנית, כבר לא צריך להיות שם - הפיצ'ר תמיד פעיל, אז אפשר פשוט למחוק את הבדיקה if ואת הקוד הישן שהיא מגינה עליו. בפועל, זה כמעט אף פעם לא קורה מספיק מהר.

צוותים צוברים עשרות ואפילו מאות דגלים ישנים לאורך זמן, כשאף אחד לא בטוח יותר אילו מהם עדיין באמת רלוונטיים ואילו כבר מיותרים. זה יוצר קוד מלא בתנאים מיותרים, וסיכון אמיתי - מישהו יכול בטעות לכבות דגל ישן, ולגלות שהוא שובר משהו שהיה תלוי בו, בלי שידע בכלל שהתלות הזאת קיימת. הפתרון הוא פשוט אבל דורש משמעת - להתייחס למחיקת דגל ישן כחלק מובנה מסיום העבודה על פיצ'ר, לא כמשימת ניקיון שדוחים לנצח.

לסיכום

בסופו של דבר, Feature Flags נותנים לצוותי פיתוח שליטה עדינה על מתי ולמי פיצ'ר נחשף, מפרידים בין העלאת קוד לשרת לבין חשיפתו למשתמשים, ומאפשרים גם שחרור הדרגתי וגם כיבוי מיידי במקרה חירום. המחיר הנסתר הוא חוב הדגלים שמצטבר אם לא מנקים לאורך זמן. בקורס צד שרת עוברים על טכניקות כאלה לשחרור בטוח של קוד לפרודקשן, כחלק מהתהליך המלא של בניית מערכת אמיתית.

יש לכם סיפור על פיצ'ר שהיה חייב מתג כיבוי ולא היה לו? נשמח לשמוע בדיסקורד.

הצטרפו לקהילה בדיסקורד