אסטרטגיות דיפלוי: Rolling, Blue-Green, Canary ו-Feature Flags

מאת צוות מדיה דיל · 03.08.2026 · DevOps · 7 דק׳

מפת דרכים לאסטרטגיות דיפלוי בפרודקשן — recreate, rolling, blue-green, canary ו-feature flags, והחלטות הארכיטקטורה מאחוריהן.

הרגע שבו דיפלוי לפרודקשן הופך ממשימה שגרתית לאירוע מלחיץ עם עצירת נשימה הוא הרגע שבו צריך אסטרטגיית דיפלוי אמיתית. "פשוט מעדכנים את השרת" עובד כשיש שרת אחד ומשתמש אחד; ברגע שיש תעבורה חיה, SLA, ומשתמשים שלא סולחים על שנייה של downtime, הבחירה באסטרטגיית הדיפלוי הופכת להחלטה ארכיטקטונית מרכזית לא פחות מבחירת מסד הנתונים. במאמר הזה נעבור על מפת האסטרטגיות המרכזיות — recreate, rolling, blue-green, canary ו-feature flags — ונבין מתי כל אחת מהן נכונה, ומה המחיר האמיתי שלה.

Recreate: הבסיס שממנו כולם מתחילים

האסטרטגיה הפשוטה ביותר: להוריד את הגרסה הישנה לגמרי, ואז להעלות את החדשה. אין שום מורכבות, אין ניהול מצב בין שתי גרסאות במקביל — אבל יש downtime מובטח, בין שניות בודדות למקרים גרועים דקות ארוכות אם ה-startup של האפליקציה איטי (חימום cache, migrations, health checks). זו אסטרטגיה לגיטימית לחלוטין לסביבות פנימיות, batch jobs, או שירותים עם חלון תחזוקה מוסכם, אבל אסורה כמעט תמיד עבור APIs פונים-לקוח או שירותים קריטיים לעסק.

Rolling Deployment: העדכון ההדרגתי

rolling deployment מחליף instances בהדרגה — instance אחד יורד, גרסה חדשה עולה במקומו, health check מאשר שהיא בריאה, ורק אז ממשיכים ל-instance הבא. זו ברירת המחדל של Kubernetes (RollingUpdate strategy) ושל רוב פלטפורמות ה-orchestration המודרניות, כי היא משיגה zero-downtime בלי הכפלת תשתית: בכל רגע נתון יש מספיק instances חיים כדי לשרת תעבורה. המחיר: לזמן מה יש שתי גרסאות רצות במקביל, מה שדורש שהגרסה החדשה תהיה תואמת אחורה (backward compatible) עם כל מה שהגרסה הישנה עדיין תלויה בו — במיוחד סכימת מסד נתונים ו-API contracts בין שירותים.

פרמטר קריטי נוסף ב-rolling deployment הוא maxUnavailable ו-maxSurge — כמה instances מותר להוריד בו-זמנית וכמה instances נוספים מותר להרים מעבר לכמות המקורית בזמן המעבר. הגדרה שמרנית מדי (maxUnavailable נמוך, maxSurge נמוך) מאיטה את הדיפלוי כולו, בעוד הגדרה אגרסיבית מדי עלולה להוריד קיבולת שירות מתחת לרמה שנדרשת כדי לשרת את העומס הנוכחי, מה שגורם ל-latency spike באמצע דיפלוי לכאורה "בטוח".

Blue-Green: שתי סביבות מלאות

Blue-green מחזיק שתי סביבות פרודקשן זהות לחלוטין — "blue" הפעילה כרגע ו-"green" עם הגרסה החדשה. אחרי שה-green עובר בדיקות מלאות, מחליפים את ה-load balancer או ה-DNS כך שכל התעבורה עוברת אליו באופן מיידי, ו-blue נשארת כ-fallback מיידי אם משהו משתבש. היתרון המרכזי: מעבר אטומי ו-rollback מיידי (סתם מחליפים חזרה את המצביע) בלי צורך לחכות ל-rolling deployment הפוך. המחיר: כפל תשתית מלא — פי שניים עלות compute בזמן המעבר, ומורכבות סנכרון מסד נתונים בין שתי הסביבות אם יש migrations לא-תואמות-אחורה שרצות במקביל לתעבורה החיה על הסביבה הישנה.

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

Canary: חשיפה הדרגתית מבוססת מדדים

Canary deployment חושף את הגרסה החדשה לאחוז קטן מהתעבורה בלבד (למשל 5%), בוחן מדדים אמיתיים — error rate, latency, business metrics — ורק אם הם תקינים מגדיל בהדרגה את האחוז עד 100%. זו האסטרטגיה המתוחכמת ביותר מבין הארבע, כי היא היחידה שבפועל בודקת את ההשפעה על משתמשים אמיתיים לפני חשיפה מלאה, ולא מסתמכת רק על health checks טכניים. המימוש דורש תשתית מתקדמת: service mesh (Istio, Linkerd) או API gateway שיודע לפצל תעבורה לפי אחוזים, ומערכת ניטור שיכולה להשוות בזמן אמת בין הגרסה הישנה לחדשה ולהחליט אוטומטית אם להמשיך או לבצע rollback (progressive delivery אוטומטי עם כלים כמו Flagger או Argo Rollouts).

Feature Flags: הפרדה בין Deploy ל-Release

המהפכה הארכיטקטונית האמיתית בעשור האחרון היא ההבנה ש-deploy (הקוד רץ בפרודקשן) ו-release (המשתמשים רואים את הפיצ'ר) הם שני אירועים נפרדים לגמרי. Feature flags מאפשרים לפרוס קוד חדש לגמרי לפרודקשן כשהוא כבוי מאחורי flag, ואז להדליק אותו בהדרגה לאוכלוסיות ספציפיות — עובדים פנימיים, אחוז קטן ממשתמשים, לפי גיאוגרפיה — ללא צורך בדיפלוי נוסף בכלל. זה מבטל את הצורך ב-rollback דרך דיפלוי הפוך; rollback הופך לכיבוי flag, שלוקח שניות במקום דקות. המחיר הוא מורכבות קוד: כל flag שנשאר פעיל לאורך זמן מוסיף branching logic, וללא משמעת לניקוי flags ישנים, הקוד מצטבר לחוב טכני משמעותי.

Shadow Deployment ו-Dark Launches

טכניקה מתקדמת פחות מוכרת: shadow deployment (או mirroring) שולח עותק של תעבורה אמיתית לגרסה החדשה במקביל לגרסה הישנה, אבל התשובה של הגרסה החדשה נזרקת ולא חוזרת למשתמש בפועל — המשתמש תמיד מקבל תשובה מהישן. זה מאפשר לבדוק ביצועים והתנהגות של הגרסה החדשה תחת עומס אמיתי, ללא שום סיכון למשתמשים, אבל דורש זהירות כשיש side effects (כתיבה למסד נתונים, שליחת אימיילים) — shadow traffic שגורם לתופעות לוואי כפולות הוא מלכודת נפוצה שדורשת idempotency או בידוד סביבת ה-shadow.

A/B Testing כאסטרטגיית דיפלוי

בעוד canary עוסק בבטיחות טכנית (האם הגרסה החדשה לא שוברת דברים), A/B testing עוסק בשאלה עסקית — האם הגרסה החדשה באמת טובה יותר. הבדל מרכזי: ב-canary החשיפה גדלה עד 100% ברגע שהמדדים תקינים, בעוד ב-A/B testing שתי הגרסאות יכולות לרוץ במקביל לאורך זמן ממושך (שבועות) כדי לאסוף מדגם סטטיסטי מובהק. מבחינה תשתיתית שתי הטכניקות דומות מאוד — שתיהן דורשות routing מבוסס משתמש/session עקבי (sticky routing כדי שאותו משתמש תמיד יראה את אותה גרסה), אבל המטרה שונה: אחת בודקת יציבות, השנייה בודקת השפעה על מדדי מוצר כמו conversion rate.

נקודה חשובה שמתפספסת לעיתים קרובות: כשמריצים A/B test על שינוי בקצה ה-backend (למשל אלגוריתם דירוג תוצאות), חובה לוודא שהמדידה עצמה לא מוטה — אם הגרסה ה-B איטית יותר בכמה מילישניות, זה עלול להשפיע על מדדי engagement ללא קשר לאיכות האלגוריתם עצמו, ולסלף את מסקנות הניסוי.

איך בוחרים: מטריצת ההחלטה

הבחירה הנכונה תלויה בשלושה גורמים: (1) עלות downtime — עבור מערכות פנימיות recreate מספיק, עבור מערכות פונות-לקוח חובה zero-downtime; (2) עלות תשתית כפולה — blue-green דורש תקציב compute כפול, בעוד rolling לא; (3) רמת הביטחון הנדרשת לפני חשיפה מלאה — אם השינוי מסוכן (שינוי אלגוריתם תמחור, שינוי core business logic) canary עם מדדים אוטומטיים הוא הבחירה הבטוחה ביותר, גם אם הוא היקר ביותר לבנייה. ארגונים בוגרים לרוב משלבים: rolling deployment כברירת מחדל לרוב השינויים, canary לשינויים מסוכנים, ו-feature flags לכל שינוי שנוגע בהתנהגות משתמש נראית לעין.

גורם רביעי שלעיתים מתעלמים ממנו הוא זמן ה-startup של האפליקציה עצמה. שירות שלוקח לו 45 שניות לעלות ולעבור health check (בגלל טעינת מודלים, warm-up של connection pools, JIT compilation) הופך כל אסטרטגיה שמבוססת על מעבר מהיר בין גרסאות לאיטית בהרבה ממה שנראה על הנייר — rolling deployment על 20 instances עם 45 שניות עלייה לכל אחד יכול לקחת 15 דקות גם אם כל שלב בודד "מהיר".

טעויות נפוצות בפרודקשן

הטעות הראשונה היא הזנחת תאימות אחורה בסכימת מסד הנתונים — כל אסטרטגיה שאינה recreate מלא דורשת שהגרסה הישנה והחדשה יעבדו על אותה סכימה בו-זמנית, ולכן migrations חייבים לפעול בשני שלבים (expand-then-contract): קודם מוסיפים עמודה חדשה בלי להסיר את הישנה, פורסים קוד שיודע לעבוד עם שתיהן, ורק אחרי שכל instance עודכן מסירים את הישן. השנייה היא health checks שטחיים מדי (רק "השרת עונה") במקום בדיקה אמיתית של תלויות קריטיות (חיבור למסד נתונים, cache, שירותים חיצוניים). השלישית היא היעדר automated rollback — אם אין מדיניות אוטומטית שמזהה עלייה ב-error rate ומבצעת rollback, הזמן שלוקח לבן אדם לשים לב ולפעול הוא הזמן שבו משתמשים אמיתיים נפגעים. הרביעית היא ניהול session state בזיכרון מקומי של השרת (in-memory sessions) — כל אסטרטגיה שמחליפה instances (rolling, blue-green) תגרום לניתוק משתמשים שה-session שלהם היה שמור רק על ה-instance שהוסר, ולכן state צריך לגור במקום חיצוני משותף (Redis, מסד נתונים) ולא בזיכרון התהליך עצמו.

טעות חמישית, פחות מדוברת אך נפוצה מאוד בפועל: הרצת migrations כחלק מ-startup script של האפליקציה עצמה, כך שכל instance חדש שעולה מנסה להריץ migration באופן עצמאי. ב-rolling deployment עם עשרות instances זה יוצר מרוץ בין תהליכים מקבילים שמנסים לשנות את אותה סכימה בו-זמנית. הפתרון הנכון הוא הרצת migrations כ-job נפרד ומבודד לפני תחילת הדיפלוי, לא כחלק מ-startup של כל instance בנפרד.

תפקיד ה-Load Balancer וה-Service Mesh

כל האסטרטגיות שתוארו כאן נשענות בסופו של דבר על שכבת ניתוב שיודעת להפנות תעבורה באופן דינמי — load balancer קלאסי (ALB, Nginx) מספיק לרוב תרחישי ה-rolling ו-blue-green, אבל canary מדויק ברמת האחוזים ו-A/B testing מבוסס משתמש דורשים בדרך כלל service mesh כמו Istio או Linkerd, שמאפשר routing rules מתוחכמים ברמת בקשה בודדת (headers, cookies, geo) ולא רק ברמת instance. ההשקעה בשכבת ה-routing היא לרוב הגורם המגביל האמיתי — ארגון שרוצה canary אמיתי אבל משתמש ב-load balancer בסיסי בלבד ייתקל במגבלה טכנית לפני שהוא בכלל מגיע לשאלת האסטרטגיה.

סיכום

אין אסטרטגיית דיפלוי "הכי טובה" באופן מוחלט — יש התאמה נכונה לרמת הסיכון, לתקציב התשתית, ולדרישות ה-uptime של המערכת הספציפית. הצוותים הבוגרים ביותר לא בוחרים אסטרטגיה אחת אלא בונים ארגז כלים — rolling כברירת מחדל, blue-green לשינויים גדולים, canary לשינויים מסוכנים ו-feature flags להפרדת deploy מ-release — ומפעילים את הכלי הנכון לפי אופי השינוי.

תגיות: deployment strategies · rolling deployment · blue-green deployment · canary deployment · feature flags · zero-downtime · DevOps

← חזרה לבלוג · צור קשר