פריסת דגלי פיצ'רים: מפתרונות מאולתרים למערכת תעשייתית

Feature flag deployment: היכן נשברת ההשקה בקנה מידה

השקה מבוקרת באמצעות דגלי תכונה — מה שבפרקטיקה הענפית מכונה feature flag deployment — נשענת על הפרדה פשוטה: הקוד מגיע לפרודקשן ללא תלות בשאלה אם התכונה דלוקה או כבויה.

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

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

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

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

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

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

השקה מבוקרת של דגלים: אפקטים במספרים מדידים

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

מהירות אספקת שינויים

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

מתווסף אפקט חמישי — יכולת חיזוי: ההפעלה מתבצעת בשלבים, 5% מהתעבורה, אחר כך 25%, ואז 100%, עם עצירה למדדים בין שלב לשלב. גם החזרה למצב הקודם הופכת לפעולה אחת.

צמצום מחלקת הכשלים

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

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

מצבי השקה של דגלים: תצורה, שירות, היברידי

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

קריטריונים לבחירה תחת עומס

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

מגבלות האפשרויות

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

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

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

1. ביקורת דגלים. סורקים מאגרים ותצורות, אוספים מרשם: מפתח, מקום הצהרה, מי קורא, בעלים, תוחלת חיים. בדרך כלל מחצית מהרשומות מתות או דלוקות תמיד.
2. סיווג וניקוי. מחלקים לדגלי רליז, תפעול, ניסוי וחירום; לכל סוג כללי שמות והסרה משלו. את המיותר מסירים לפני תחילת העבודה.
3. סכמת אחסון יעד. מגדירים היכן נשמר מצב הדגלים, איך הוא מגיע לאפליקציה ומה להחזיר אם המאגר אינו זמין. ערך ברירת המחדל — בטוח.
4. סכמת השקה. מגדירים את חלק התעבורה לענף החדש, סדר החזרה לאחור וחלון ההחלפות. מועד הסרת הדגל נקבע מראש, יחד עם תאריך.
5. בדיקה לפני השקה. מריצים את שני המצבים של כל דגל בסביבת בדיקה, בודקים מדדים ולוגים של החלפות. דגלים שלא עברו לא נכנסים לפרודקשן.
6. פיילוט ומסירה לתפעול. מפעילים את המערכת על שירות אחד, מודדים את זמן אספקת השינוי ומספר התקלות, ואז משכפלים. לצוות מוסרים את המרשם, הרשאות גישה, נוהל הסרה והוראות תורנות.

קריטריונים למוכנות

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

מה נשאר במאגר: סכמות, מדיניויות, נהלים

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

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

נוהל שינוי תצורה ותפקידים

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

מקרה בוחן: איך השקת דגלים הפסיקה לשבור רליזים

התמונה ההתחלתית

דגלי ההשקה חיו בקבצי תצורה בסביבות הבדיקה ונערכו ידנית: עד סוף הספרינט המצב של סביבת הבדיקה וסביבת העבודה התפצל, והשוואה לפני הוצאה גזלה מהמהנדס התורן 3-4 שעות. אפשר היה לכבות פונקציה בעייתית רק בהשקה חוזרת — מרגע התלונה הראשונה של משתמש ועד העצירה עברו 40-60 דקות.

מחזור הרליז ארך שבועיים; מתוך 20 הוצאות, 8 הוחזרו לאחור, ועוד 5 דרשו תיקונים דחופים מעל הרליז. מתג שנשכח נמצא לעתים קרובות יותר דרך פניות ולא בבדיקות: לא היה ריוויו נפרד לשינויי דגלים, והיסטוריית העריכות לא נשמרה בשום מקום.

התוצאה שהתקבלה

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

• החזרת פונקציה לאחור — 90 שניות במקום 40-60 דקות: ההחלפה אינה דורשת בנייה והשקה.
• שיעור ההוצאות עם החזרה לאחור — מ-40% ל-6%.
• מחזור רליז — השקות יומיות של 1-2 פונקציות במקום הוצאה אחת לשבועיים.
• עומס על התורן — 20 דקות בשבוע להשוואה במקום 4 שעות לפני כל רליז.

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

במה שונה feature flag ממשתנה סביבה?

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

ההבדל הוא прежде всего במחזור החיים. משתנה סביבה הוא ישות ארוכת חיים, משנים אותו לעתים רחוקות ובמודע. דגל נולד למשימה מסוימת — פריסה הדרגתית, ניסוי, מפסק חירום — וחייב למות יחד איתה. דגל בלי תאריך הסרה ובלי בעלים הופך אחרי כמה חודשים לענף לוגיקה בלתי נראה.

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

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

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

ספקות של מהנדסים: זמינות, ביקורת, ניקוי דגלים

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

מי ואיך משנה דגלים — האם נשאר עקבות?

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

איך מחלקים הרשאות בין צוותים?

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

הרי דגלים ייערמו — מי מנקה אותם?

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

מה עם תמיכה לאחר ההטמעה?

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

נדבר על המשימה: מה לשלוח להערכה ולתוכנית

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

מה לשלוח להערכה ולתוכנית:

• רשימת שירותים וסביבות שבהן דרושים דגלי תכונה (feature flags): כמה סביבות בדיקה, במה נבדלות התצורות, היכן נמצאים הפרמטרים.
• איך מושקים רליזים היום: שלבים ידניים, מי מחליף את התנהגות המערכת, האם אפשר להחזיר פונקציונליות אחת לאחור בלי לגעת בשאר.
• סכמת תפקידים והרשאות: למי מותר לשנות דגל בפרודקשן, האם נדרש יומן שינויים ואישור של מהנדס נוסף.
• כאבים נוכחיים: מה נשבר לעתים קרובות יותר בהשקה, כמה זמן אורכת החזרה לאחור, היכן נאלצים לתקן קוד באופן זמני.
• מגבלות: מחזור רליז, חלונות לשינויים, דרישות לבידוד קונטורים ואבטחה.
• יעדים מדידים: תוך כמה זמן צריך להיות אפשרי לכבות פונקציונליות, ולפי אילו סגמנטים לפרוס שינויים.

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

תארו את המשימה — נחזור עם הערכה ותוכנית עבודה, שבה רואים מה אנחנו עושים בכל שלב ומה אתם מקבלים בסוף.