חמשת השלבים למימוש Continuous Deployment

31 בדצמבר 2011


הפעם רציתי לכתוב על משהו קצת שונה.

 

בפוסטים הקודמים דיברנו על הטעויות שרבים עושים בבחירת שיטת ניהול פרויקטי התוכנה המתאימה להם, למדנו מתי להשתמש בשיטת מפל המים (Waterfall) ודיברנו על שיטת ה – SCRUM שסוחפת את השוק בשנים האחרונות. הפעם רציתי שנשוחח על שיטה מעט שונה: פריסה מתמשכת או בשמה הלועזי Continuous Deployment. אבל לפני שנתחיל רציתי להודות לרן תבורי שחלק מהחומרים בפוסט לקוחים מהרצאה שהוא נתן במסגרת ILTechTalk.

 

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

 

מה זה Continuous Deployment?
בשלוש מילים:
Code to Production.
במשפט אחד: אם קודדתם תכונה חדשה, תיקנתם באג או סתם שיניתם פונט כדי לשפר את יחס ההמרה, בדקתם את השינוי וזה עובד, אין צורך לחכות איתו שנה (במקרה של Waterfall) או אפילו שבועיים עד שהוא יגיע לייצור. ברגע שאתם שלמים עם שלמות ותקינות השינוי, אתם מוזמנים לדחוף אותו לייצור. כן המשמעות של כך היא שאתם יכולים להגיע לעשרות ומאות שחרורי גרסאות ביום.
נשמע מוזר? תחשבו על מזללת המבורגרים, האם הייתם מוכנים לחכות שבועיים להזמנה שלכם, רק בגלל שמישהו צריך לבדוק אם כל הקציצות עטופות כמו שצריך? או שאתם רוצים שמי שהכין לכם את ההזמנה, יסדר לכם אותה על המגש כמה שיותר מהר וימסור לכם אותה כשההמבורגר עדיין טרי ועסיסי?

 

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

 

פריסה מתמשכת בבלוג הפתוח למנהל הפיתוח continuous deployment

 

אז איך עושים את זה?
השיטה הזאת היא אחת משיטות ניהול פיתוח התוכנה הצעירות ביותר, וחמשת השלבים למימושה נוסחו בתחילת 2009 ע"י אריק רייס:



  1. מטמיעים פתרון (Continuous Integration (CI: פתרון CI אחראי על זיהוי של הכנסת קוד (Commit) למערכת ניהול התצורה (SVN, TFS וכו'), משיכת הקוד, קימפול, Build, התקנה והרצת כל הבדיקות שכתבתם (והכוונה רק לבדיקות שלא אורכות יותר מ – 5 דקות להרצה). כמובן שהתנאי למימוש הנ"ל דורש עבודה עם Unit Tests או בעברית TDD. הכלים המומלצים למימוש הם: TeamCity, Hudson ואני יכול להמליץ לכם גם על FinalBuilder.


  2. מרחיבים את ה – CI להתקנה ובקרה: מטמיעים רכיב Post Commit Hook במערכת בקרת התצורה שלכם (מומלץ מאוד להטמיע מערכת מודרנית כדוגמת SVN, GIT או TFS). הרכיב הזה יזהה Commit ויתחיל באופן אוטומטי את תהליך הבדיקות, כולל בדיקות סטנדרטים. במקרה שהוספתם בתיאור את הסימון #release ולאחריו #deploy, יתווסף לתהליך גם מהלך התקנה (כן, לא בבדיקות, בסביבת הייצור).


  3. מתחילים הכי מהר ולאט לאט מגבירים: מתחילים עם סקריפט הפצה פשוט שמופעל ע"י #deploy ולאט לאט משפרים ומוסיפים כדי לסגור את כל הפערים וזאת על מנת לפתח מערכת חיסונית מלאה. כיוון שהרצת Unit Tests בזמן ה – Build לא מבטיחה הצלחה בייצור (כמו שאתם בוודאי יודעים כבר), דאגו לסמן V על כל הנושאים הבאים:



    1. Code Review מסודר כמו שדיברנו עליו בפוסט קודם.


    2. Unit Tests לכל הקוד (רצוי מאוד לשאוף ל – 100% כיסוי קוד).


    3. Integration Tests/E2E כדי לסמלץ תהליכים עסקיים מרכזיים (רצוי לשאוף במדד הזה ל – 40% כיסוי קוד).


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


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


  4. מנטרים בזמן אמת: ניטור מלא של התהליכים העסקיים (ולא רק של ניצולת ה – CPU) על מנת לזהות שינויים חריגים. לדוגמה אם היינו מפתחים כמו בפייסבוק היינו מנטרים את מספר התמונות שמועלות, מספר התיוגים, הסטטוסים וכו'.


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

למי זה מתאים?
השיטה הזאת מתאימה בעיקר לארגונים המספקים תוכנה כשירות (בנקים, חברות אינטרנט וכו') שבהם היכולת למסור תכונה ו/או תיקון חדש בכל רגע נתון לייצור היא בעלת ערך עסקי רב. בארגונים כאלו CD מאפשר את הקטנת עלות המלאי בתהליך ל – 0. חברות שמפתחות מוצר להתקנה אצל לקוחות יזכו ליתרון בשימוש בשיטה הזאת בכך שיוכלו להקטין את זמן האינטגרציה וישפרו את הגמישות בהחלטה על נקודת הקפאת התכולות (Feature Freeze).

 

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

 

נשמע מעניין?

בפוסט הבא נדבר על Case Study מהתעשייה על מימוש של פריסה מתמשכת. אין לכם חשק להמתין? תעיפו מבט על התהליך ב – Outbrain.

 

מימשתם Continuous Deployment? רוצים לממש? נשמע לכם מוזר? רוצים לשתף אותנו בניסיונכם? בדיוק בשביל זה יש את ההערות למטה…

 

נהנית מהפוסט? רישום לבלוג הפתוח למנהל הפיתוח יבטיח לכם עדכונים חדשים ישירות לדוא"ל!

 

ממשיכים לפתח,
משה קפלן

 

משה קפלן הוא יזם, מרצה ויועץ בתחום פיתוח התוכנה

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

4 תגובות

  1. שלומי הסן - מנהל פיתוח3 בינואר 2012 ב 7:21

    רציתי לציין שפוסטים שלך מעולים
    זה במיוחד

    הגב
  2. Moshe Kaplan3 בינואר 2012 ב 12:06

    תודה שלומי!

    ממשיכים לפתח,
    משה קפלן

    הגב
  3. רומן6 בינואר 2012 ב 17:22

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

    תודה רבה.

    הגב
  4. Moshe Kaplan7 בינואר 2012 ב 11:30

    שלום רומן,

    קודם כל תודה.
    אני לא בטוח שיש שיטה להבטיח שתבין את הלקוח ב – 100%, אבל השיטה היא בד"כ התאמת ציפיות ותקשורת מולו בתדירות גבוהה. אני לא בטוח שרשימת פונקציות היא הפתרון הנכון (אלא אם הלקוח הוא גוף טכני בעצמו) אלא צריך להתמקד בתוצרים גראפיים). יש מספר טכניקות שאפשר להשתמש בהן:
    1. בפרויקטים גדולים שימוש ב – SRR: סקר דרישות לקוח שבו הספק מציג ללקוח את דרישות הלקוח (נשמע מוזר, אבל מגדיל את הסיכוי שאתם הבנתם מה הלקוח רוצה).
    2. שימוש ב – Mockups וצילומי מסכים (שאין מאחוריהם קוד) ומדגימים את התהליך. להרבה מאוד אנשים קשה לדמיין (או "לראות מעבר לשיפוץ"), והם צריכים שכספק תעזור לו לתסגור את הפער.
    3. אספקת תוצרים בתדירות גבוהה: גם לקוח שהיה סגור על מה שביקש, הולך להרצאות, משוחח עם חברים ומגלה דברים חדשים, והתוצאה שהדרישות משתנות. ע"י אספקת תוצרים מהירה, תוכלו להקטין את הסיכוי למחשבות נוספות אצל הלקוח (ובמקרה הצורך להתקדם איתו צעד אחר צעד בשינוי אצלו).
    4. תקשורת: אם אין לכם תוצר, שיחת טלפון בפער ביום יומיים ועדכון הלקוח, יכולים לגלות את רמת העניין אצל הלקוח והאם יש שינויים אצלו בבית (רעיונות חדשים, בוס חדש, רה ארגון או כל צרה אחרת).

    ממשיכים לפתח,
    משה קפלן

    הגב