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

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

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

לפני הכל אזהרה

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

מה זה Continuous Deployment?

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

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

מה זה לא?

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

אז איך עושים את זה?

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

  1. מטמיעים פתרון (Continuous Integration (CI: פתרון CI אחראי על זיהוי של הכנסת קוד (Commit) למערכת ניהול התצורה (SVN, TFS וכו’), משיכת הקוד, קימפול, Build, התקנה והרצת כל הבדיקות שכתבתם (והכוונה רק לבדיקות שלא אורכות יותר מ – 5 דקות להרצה). כמובן שהתנאי למימוש הנ”ל דורש עבודה עם Unit Tests או בעברית TDD. הכלים המומלצים למימוש הם: TeamCityHudson ואני יכול להמליץ לכם גם על 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? רוצים לממש? נשמע לכם מוזר? רוצים לשתף אותנו בניסיונכם? בדיוק בשביל זה יש את ההערות למטה.

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

משה קפלן

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

הגב

2 תגובות על "חמשת השלבים למימוש Continuous Deployment"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
עדי
Guest

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

לפעמים יש צורך בבדיקות QA ואי אפשר להסתפק בבדיקות אוטומטיות (בעיקר לאחר שינויי UI – בשרתי אינטרנט בעיקר יש תוכן javascript רב היום שלמרות שיש כל מיני כלים שמאפשרים בדיקה שלהם – תהליך זה מעט מורכב יותר ועדיין לא מספק.

משה קפלן
Guest

שלום עדי,

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

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

wpDiscuz

תגיות לכתבה: