לפני שנרחיב על פריסה מתמשכת [Continuous Deployment] ראוי להציג את הגישה המקובלת לפריסת תכנה ברוב חברות הרשת. גישה זאת כוללת לרוב שילוב מסוים של השלבים הבאים:
- תכנון אוסף תכונות חדשות של המוצר, כתיבת הגדרות עסקיות וטכניות.
- מימוש התכונות [Features] וכתיבת בדיקות. לרוב אין מעבר חד בין תת השלבים הנ"ל אך הם מתבצעים פחות או יותר ברצף. ככל שהפיתוח יותר מונחה בדיקות, יש פחות (אם בכלל) הפרדה בין שלב מימוש לבדיקות. בקבוצות בינוניות וגדולות קוד המקור לתכונות שונות נשלח לענפים שונים במאגר הקוד [Code Repository]. ענפים אילו ממוזגים לקראת סיום השלב לענף הייצור. במקרים קשים,כתיבת קוד הבדיקה נעשה ע"י קבוצה שונה.
- בקרת איכות [Quality Assurance] ידנית ע"י קבוצה פחות טכנית מצוות ההנדסה. לרוב בדיקה זאת נעשית בסביבת הערכות [Staging Environment].
- פריסת התכנה בסביבת הייצור [Production Environment] והשקת התכונות החדשות.
כתוצאה מכך, הזמן הנע בין כתיבת קוד המקור ועד הגעת הקוד לסביבת הייצור יכול לנוע בין ימים, מספר שבועות בממוצע ועד לחודשים!
שיטה זו דומה לרכב הנוסע על גלגלים מרובעים. אם מתאמצים הרכב ינוע, אך התנועה לא תהיה חלקה, עצירה פתאומיות או שינוי כיוון יתלוו במאמצים רבים, ולקחת טיפה רברס (אפילו בלי פלטפורמה) תהיה משימה כמעט בלתי אפשרית.
פריסה ממשכת באה לקצר זמנים אלה לדקות בודדות ומיושמת בעיקר בחברות הזנק קלילות [Lean Startup]. חברת הזנק קלילה שמה חשיבות רבה על בניית הלקוח, לא ע"י ניחושים או שאלת הלקוח מה הוא רוצה, אלא תוך מעקב אחרי התנהגות בתנאי שוק אמתיים. פריסה ממשכת מאפשרת למנהלי המוצר להאיץ את תהליך הפקת הלקחים בעזרת שינוי תכניות ותעדופים על המקום.
מיד לאחר סיומם המוצלח של סדרת הבדיקות כל מהנדס יכול לשלוח לפריסה יחידות תכנה של אותה גרסא. יחידות תכנה אילו הם לרוב צד שרת או קוד הרץ על דפדפן. מכאן שבשיטה זאת הגלגל יותר עגול, יש פחות שלבי פיתוח, והשוני בין הקוד הרץ בסביבת הפיתוח לסביבת הייצור הוא מזערי.
חשוב לציין שבשיטה זו יש אבחנה ברורה בין פריסה והשקה [Release]. בעוד שפריסה היא מונח הנדסי, השקה היא בידי אנשי המוצר. התכנון העסקי ושחרור תכונות לא תלוי יותר בזמני מחזור של ארגון ההנדסה. תכונות חדשות זמינות רק למשתמשים מתוך הארגון הרואים איך התכונות נבנות לנגד עיניהם ויכולים לבקש שינויים תוך כדי תנועה. כאשר המהנדסים מכריזים שסיימו אוסף תכונות ואנשי המוצר מחליטים שהגיע הזמן לשחרר, לא נותר אלא לשחרר מתג וירטורלי שחושף את התכונה לתנועת הייצור.
לפני מספר חודשים לדוגמה, דיבר איש מוצר אם אחד מלקוחות המפתח של קצ'ינג. תוך כדי שיחה התברר שצריך לשנות תכונה מסוימת באתר על מנת שתתאים לאותו לקוח. מאחר בסביבת הפיתוח של המהנדסים יש כמעת אותו קוד הרץ בסביבת הייצור, השינויים בצד שרת וממשק משתמש מומשו בדקות ספורות ויכולנו להתקשר ללקוח לאחר כעשרים דקות על מנת לבקש חוות דעת על השינוי. אין צורך לתאר את הרושם החיובי על הלקוח והיתרון העסקי בתגובה מהירה לאותות מהשוק.
בשיטה זאת אין קבוצת בדיקת איכות, וקוד חדש מגיע לסביבת מוצר תוך דקות בודדות. בממוצע יש כעשרים פריסות ביום וניתן לשלוח קוד לייצור תוך פחות מחמש דקות. צוותים העובדים בפריסה ממשכת מקדשים מאמצים רבים לבדיקות, ונותנים ביטחון רב באמינותם. הבדיקות אינם אלא קו הגנה אליהם נוספים קווי הגנה בצורת בדיקה עצמית של התכנה בסביבת השרת, וניטור ברמות טכניות ועסקיות. במידה ואחת מהבדיקות נכשלת הגרסא נמשכת חזרה וגרסא הקודמת נפרסת מחדש. מאחר וכל השירותים רצים באשכול, מספיק שיחידה בודדת נכשלת, כל האשכול מוחזר לגרסא הקודמת. לרוב, אם ישנם בעיות הם מתגלות תוך כדי פריסת היחידה הראשונה באשכול, יחידה זאת אינה זמינה לתנועת "ייצור" אלא עד שהיא עוברת סדרת בדיקות עצמיות ובדיקות שילוב [Integration Tests] עם כלי בדיקה מערכתיים כמו סלניום [Selenium].
עוד על היבטים טכניים של פריסה ממשכת בהמשך.
[3] תכונה: Feature
[4] מאגר קוד: Code Repository such as GIT and SVN
[5] בקרת איכות: Quality Assurance - QA
[6] סביבת הערכות: Staging Environment
[7] סביבת הייצור: Production Environment
[9] השקה: Release
[10] בדיקות שילוב: Integration Tests
[11] סלניום: Selenium
