הפעם רציתי לכתוב על משהו קצת שונה.
לפני הכל אזהרה
במבט ראשון השיטה שנדבר עליה תראה לכם כמו "שכונה" אבל אחרי שנעמיק בה נגלה שיש בה כמה דברים מאוד מעניינים שמאפשרים לארגון לשחרר גרסאות במהירות, איכות וגמישות שלא היו קיימות קודם לכן.
מה זה Continuous Deployment?
בשלוש מילים: Code to Production.
במשפט אחד: אם קודדתם תכונה חדשה, תיקנתם באג או סתם שיניתם פונט כדי לשפר את יחס ההמרה, בדקתם את השינוי וזה עובד, אין צורך לחכות איתו שנה (במקרה של Waterfall) או אפילו שבועיים עד שהוא יגיע לייצור. ברגע שאתם שלמים עם שלמות ותקינות השינוי, אתם מוזמנים לדחוף אותו לייצור. כן המשמעות של כך היא שאתם יכולים להגיע לעשרות ומאות שחרורי גרסאות ביום.
נשמע מוזר? תחשבו על מזללת המבורגרים, האם הייתם מוכנים לחכות שבועיים להזמנה שלכם, רק בגלל שמישהו צריך לבדוק אם כל הקציצות עטופות כמו שצריך? או שאתם רוצים שמי שהכין לכם את ההזמנה, יסדר לכם אותה על המגש כמה שיותר מהר וימסור לכם אותה כשההמבורגר עדיין טרי ועסיסי?
מה זה לא?
השיטה הזאת היא לא תחליף לעבודה מסודרת, ואין פה כוונה שתעברו לשיטת העבודה הידועה לשמצה של שליפת קוד וזריקתו לייצור ללא בדיקה מינימאלית. המטרה בפריסה מתמשכת היא פיתוח לפי דרישה, בדיקה בפיתוח (עדיף אוטומטית כדי שניתן יהיה לוודא שאף חלק במערכת לא נפגע), ולאחר מכן העלאה מבוקרת לייצור תוך וידוא בכל שלב שהתנהגות המערכת לא השתנתה.
אז איך עושים את זה?השיטה הזאת היא אחת משיטות ניהול פיתוח התוכנה הצעירות ביותר, וחמשת השלבים למימושה נוסחו בתחילת 2009 ע"י
אריק רייס:
-
מטמיעים פתרון (Continuous Integration (CI: פתרון CI אחראי על זיהוי של הכנסת קוד (Commit) למערכת ניהול התצורה (SVN, TFS וכו'), משיכת הקוד, קימפול, Build, התקנה והרצת כל הבדיקות שכתבתם (והכוונה רק לבדיקות שלא אורכות יותר מ - 5 דקות להרצה). כמובן שהתנאי למימוש הנ"ל דורש עבודה עם Unit Tests או בעברית TDD. הכלים המומלצים למימוש הם:
TeamCity,
Hudson ואני יכול להמליץ לכם גם על
FinalBuilder.
-
מרחיבים את ה - CI להתקנה ובקרה: מטמיעים רכיב Post Commit Hook במערכת בקרת התצורה שלכם (מומלץ מאוד להטמיע מערכת מודרנית כדוגמת SVN, GIT או TFS). הרכיב הזה יזהה Commit ויתחיל באופן אוטומטי את תהליך הבדיקות, כולל בדיקות סטנדרטים. במקרה שהוספתם בתיאור את הסימון #release ולאחריו #deploy, יתווסף לתהליך גם מהלך התקנה (כן, לא בבדיקות, בסביבת הייצור).
-
מתחילים הכי מהר ולאט לאט מגבירים: מתחילים עם סקריפט הפצה פשוט שמופעל ע"י #deploy ולאט לאט משפרים ומוסיפים כדי לסגור את כל הפערים וזאת על מנת לפתח מערכת חיסונית מלאה. כיוון שהרצת Unit Tests בזמן ה - Build לא מבטיחה הצלחה בייצור (כמו שאתם בוודאי יודעים כבר), דאגו לסמן V על כל הנושאים הבאים:
-
-
Unit Tests לכל הקוד (רצוי מאוד לשאוף ל - 100% כיסוי קוד).
-
Integration Tests/E2E כדי לסמלץ תהליכים עסקיים מרכזיים (רצוי לשאוף במדד הזה ל - 40% כיסוי קוד).
-
מנגנון בדיקה עצמית, שישמש כל שירות לבדיקת תקינות כל הממשקים שלו לפני שהוא מכריז לשירותים האחרים על זמינותו למתן שירות.
-
תהליך העלאה מסודר של שרת אחרי שרת, שמבטיח להמנע מקטסטרופה אם יש בעיות בגרסה.
-
מנטרים בזמן אמת: ניטור מלא של התהליכים העסקיים (ולא רק של ניצולת ה - CPU) על מנת לזהות שינויים חריגים. לדוגמה
אם היינו מפתחים כמו בפייסבוק היינו מנטרים את מספר התמונות שמועלות, מספר התיוגים, הסטטוסים וכו'.
-
מתחקרים: תחקור מהיר ומתמיד של באגים ועבודה במחזורים קצרים לתיקונם כמו ב
מתודולגיית Lean ששוחחנו עליה בפוסט הקודם.
למי זה מתאים?
השיטה הזאת מתאימה בעיקר לארגונים המספקים תוכנה כשירות (בנקים, חברות אינטרנט וכו') שבהם היכולת למסור תכונה ו/או תיקון חדש בכל רגע נתון לייצור היא בעלת ערך עסקי רב. בארגונים כאלו CD מאפשר את הקטנת עלות המלאי בתהליך ל - 0. חברות שמפתחות מוצר להתקנה אצל לקוחות יזכו ליתרון בשימוש בשיטה הזאת בכך שיוכלו להקטין את זמן האינטגרציה וישפרו את הגמישות בהחלטה על נקודת הקפאת התכולות (Feature Freeze).
ממה צריך להזהר?כמו בכל השיטות "המהירות" אנחנו צריכים לזהות שמהירות ושחרור מהיר לייצור לא באות על חשבון יעדים אסרטגיים. לכן הקדישו מחשבה לגבי מה שאתם רוצים למכור ואיך,
גבשו אסטרטגיה ורק לאחר מכן התחילו לפתח...
נשמע מעניין?
בפוסט הבא נדבר על Case Study מהתעשייה על מימוש של פריסה מתמשכת. אין לכם חשק להמתין? תעיפו מבט על
התהליך ב - Outbrain.
מימשתם Continuous Deployment? רוצים לממש? נשמע לכם מוזר? רוצים לשתף אותנו בניסיונכם? בדיוק בשביל זה יש את ההערות למטה...
משה קפלן הוא יזם, מרצה ויועץ בתחום פיתוח התוכנה