אז… אתם רוצים Continuous Deployment?

המחשבה כנראה הולכת כך: “CD זה טוב => אנחנו רוצים להיות טובים יותר => בואו נעשה CD”.

(ייתכן, כמובן, והייתה התעמקות – אך פשוט לא נחשפתי אליה.)Continuous Delivery היא כבר שאיפה סטנדרטית: כמעט כולם רוצים להיות שם. כ”כ הרבה נמצאים “בתהליך…”. כרגיל…

בפוסט הזה אני רוצה לחזור ולדבר על הציפיות הסבירות מ CD, על המשמעות, המעבר, וכו׳…

הפשט

בדומיין שאנו מדברים עליו יש 3 פרקטיקות דומיננטיות, שנהוג לפרש אותן בערך כך:

• Continuous Integration (בקיצור CI) – יש לנו שרת Build עם בדיקות אוטומטיות. כל כמה זמן (לילה?) – כל הבדיקות רצות ואנו מגלים אם יש בעיות בקוד – ואז מתקנים.
• Continuous Delivery (בקיצור CD) – יש לנו שרת Build אוטומטי, שגם אורז את הקוד ל Delivery. למשל: בונה את ה ISO (אם אנו מפיצים את המערכת על DVD – פחחח) או Docker Image – שניתן להטמיע בפרודקשיין (SaaS או On-Premises).
• Continuous Deployment (בקיצור גם CD, לצורך הפוסט אשתמש בקיצור CDD) – כמו Continuous Delivery, אבל ההחלטה לשלוח ל Production היא אוטומטית. כל קוד שנכנס למערכת – מגיע ל Production. לכאורה, תוספת קטנה לתהליך.

נכון, אך פשטני משהו… מקור: notafactoryanymore.com

מוטיבציה – אז למה לנו CD עכשיו…?

CD אמור לשפר כמה מדדים במערכת, הנה העיקריים:

• צמצום אי-ודאות – היכולת לשחרר קוד מהר יותר, מספקת לנו פידבק מהיר ותדיר יותר מהשטח. ״לפגוע בקרקע בתדירות גבוהה יותר״. (רלוונטי בעיקר ל Continuous Deployment)
• פישוט תהליכי ה Integration / Deploy – ארגונים רבים נאבקים לסיים גרסאות בזמן, ובאיכות טובה. CD היא דרך לשפר את התהליכים, בכמה צורות.
• יציבות, או Uptime של המערכת בפרודקשיין.

יציבות

לאחר מעבר מוצלח ל CD/CDD, המערכות נוטות להיות יציבות יותר.
זה לכאורה פרדוקס: שינוי בפרודקשיין הוא סיכון – והנה אנחנו הולכים לעשות הרבה יותר כאלה. במקום שינוי בחודש, אולי כמה שינויים כל יום!
מצד שני, כשהשינויים הם מאוד קטנים – הסיכון מאוד קטן, יכולת האיתור של תקלות משתפר פלאים, וכמו שאומרים: Practice Makes Perfect. הרבה אימון בתהליך מאפשר להשתפר בצורה מהירה יותר.

מודל היציבות של CD הוא MTTR (קרי: Mean Time To Resolve) על פני מודל של MTBF (כלומר: Mean Time between Failures). יהיו לנו יותר תקלות במספר – אך הן יתוקנו מהר, וסה״כ ה downtime שלנו יהיה נמוך יותר.שאלה מפורסמת ב Lean היא: “כמה עבודה עליכם לעשות בכדי לבצע Deploy של שורת קוד בודדת במערכת?” (כלומר: נזניח את תוכן השינוי, ואז – מהי התקורה על כל deploy של גרסה?). התרגיל הזה ידוע גם כ Single Line of Code DevOps Kata.

בארגונים ללא CD, מדובר בד”כ על כמה ישיבות, עבודה ידנית של ביצוע רגרסיות ומעבר על התוכן, ואף כמה פעולות ידניות של איש Operations שמלווה את ה deploy. כמה שעות עבודה, וכמה דקות של פחד (במקרה הטוב).

אם אתם רוצים לעשות deploy כל יום, זה נראה כחוסר-יעילות, ולכן ה”Best Practice” שהיה מקובל במשך שנים הוא להפחית את מספר ה releases, או לפחות למתן אותו – נאמר, פעם או פעמיים בחודש, ולא יותר.

לא שעות העבודה שמושקעות ב deployment הן המחסום העיקרי – אלא הפחד מתקלות: תקלת Deploy עלולה לגרום להפסדים כספיים (“פגיעה בביזנס”), לעלות עשרות שעות עבודה של מפתחים ,ולגרום לפגיעה במוניטין החברה.

הגישה של CD נקראת: Bring the Pain forward (כמו באג’ייל).
אם זה כואב, עשו את זה בתכיפות רבה יותר – עד שתשתפרו וזה כבר לא יכאב.

בפועל, באימוץ CD אתם הולכים “לשבור דברים” כ”כ הרבה פעמים – כך שתוך כדי אתם צפויים לפתח יכולות Recovery טובות במיוחד ולשפר מאוד את ה MTTR. כמובן שחשוב מאוד לשבור דברים קטנים, ולהיות עם יכולת recovery כמעט מיידית, למשל: לסגור את ה feature flag או לחזור ל deployment הקודם תוך שניות (ע”י blue/green deployment – פרטים בהמשך).

המערכת לא תהיה יציבה יותר כי היא “תשבר פחות”.
אם תציבו לארגון ה R&D מדד פנימי של “מינימום תקלות” – קרוב לוודאי שתהרגו את תהליך ה CD.

המדד צריך להיות: תוך כמה זמן אנו מתקלים תקלה, end-to-end: זיהוי התקלה עד אימות התיקון.

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

Continuous Integration (בקיצור: CI)

זהו הרעיון שקוד המערכת יהיה כל הזמן במצב תקין (“working state”).

בניגוד למיתוס מקובל, המשמעות איננה שעליכם להתקין ולהגדיר מערכת של Jenkins או Cruise Control.
זכרו: הכלי – הוא החלק השולי. התהליך – הוא העיקר.

העיקרון הוא שאינטגרציה של קוד (“merge”) הוא הכלי האולטימטיבי לזהות שבירות במערכת – ולכן עליכם לבצע אינטגרציה כל הזמן.

כפי שאמרו זאת מייסדי ה Extreme Programming (שהיו הראשונים לאמץ את הפרקטיקה בצורה רחבה):
“אם אינטגרציה של קוד היא טובה – עשו אינטגרציה של קוד כל הזמן.”

המדד המקובל ליישום CI הוא:
כל מפתח, מבצע בכל יום עבודה – לפחות פעם אחת merge של הקוד שלו ל branch המרכזי. (ועדיף: חמש פעמים)

(רמז: Jenkins לא גורם לזה לקרות.)

שימו לב: זה לא שכל מפתח מושך את ה branch המרכזי (נקרא לו לצורך הפוסט: master) ועושה merge לתוך ה feature branch. זה פחות מועיל / מלמד על שברים. העניין הוא לבצע merge לתוך ה master בכל יום.

Feature Branches? לא כ”כ מומלצים, אלא אם אתם מקפידים לבצע merge ל master.
זה מחייב את המפתחים לחשוב ביחידות קטנות, לפרק את הפיצ’ר לשלבים קטנים (שזה טוב – בפני עצמו), ולדאוג כל הזמן שהקוד הנכתב – לא שובר את המערכת.

מה קורה עם קוד שמשנה חלק גדול במערכת? איך אפשר לעשות merge כאשר הקוד לא “מוכן”? – פשוט הכניסו feature flag, ואל תדליקו אותו עד שהקוד מוכן. תחשבו איזה יופי יהיה להדליק את הפיצ’ר רק עבור המשתמש שלכם בפרודקשיין – ולבדוק איך הפיצ’ר עובד בלייב עם traffic/data אמיתי!

העיקרון החשוב השני של CI הוא:
כאשר ה Build נשבר – לתקן אותו זו עדיפות עליונה של הארגון. לפני כל דבר אחר.

יעד מקובל הוא תיקון תוך 10 דקות – לרוב ע”י rollback.
אפילו יותר טוב: בדקו את ה merge בצד, ורק לאחר שהצליח – בצעו את ה merge בפועל. השיטה הזו עובדת יותר טוב כאשר יש code bases קטנים (למשל: microservices) ואין race condition על merges.

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

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

עם CI אולי תכניסו קצת פחות פיצ’רים – אבל תוכלו לסיים את הספרינט בזמן, ובאיכות שהחלטתם.

בדיקות יחידה (Unit-Tests) או אינטגרציה (Integration-Tests) הגיעו לתהליך ה CI מאוחר יותר – והפכו לחזות עיקר התהליך. אין ספק: הן חשובות מאוד, ומועילות מאוד. מה היה קודם לכן? קומפליציה + בדיקת המערכת end-to-end (שאורכת זמן רב, ותופסת רק חלק מסוים מהבעיות).

האם בדיקות אוטומטיות טובות מספיקות, ויכולות לייתר את הצורך ב merges תכופים?
אם אתם רואים שאצלכם זה עובד – אדרבא.

בד”כ השבירות בקוד (גם אם הן נתפסות ע”י Unit tests) מגיעות אחרי merges של קוד – ואתם לא רוצים “לחטוף אותן” בסוף הספרינט – חשוב לבצע אינטגרציה כל הזמן.

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

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

האם שווה לעשות CI ע”י merges תכופים, אך ללא בדיקות יחידה מקיפות?
– גם על זה לא הייתי ממליץ. זה כנראה עדיף במעט על בדיקות ללא merges תכופים – אך זה לא ייתן את האפקט המלא.

CI הוא האב הרוחני של CD, ולרוב מגיע איתו ביחד.
האם חובה ליישם CI לפני שמתחילים לעבוד על CD? – נדבר על זה בהמשך…

סיכום

בפוסט זה ניסיתי להסביר מה הציפיות הסבירות מ CI/CD/CDD – תהליך חשוב שלאט הולך ומוטמע באמת בעוד ועוד חברות. אימוץ תהליכים אלו הם לרוב מאמץ ארגוני אינטנסיבי של חודשים – אבל גם השיפור עשוי להיות משמעותי למדי.

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

שיהיה בהצלחה!