בפוסט הקודם בסדרה דיברנו על Continuous Delivery (בקיצור CD), על ה Deployment Pipeline, ופרקטיקות נוספות.
בפוסט הזה אני רוצה להתמקד ולהשלים את הסקירה של Continuous Deployment (לצורך הפוסט: CDD), ולדבר על הטמעה של הפרקטיקות הללו - בארגון שעדיין לא נמצא שם.
Continuous Deployment הוא הרעיון שהפער בין קוד המערכת לסביבת הפרדוקשיין יהיה מינימלי - דקות עד שעות ספורות לכל היותר.
שאלה בוודאי שאתם שואלים את עצמם, לאחר הבנת התהליכים של CD - היא מהו הפער ליישום CDD?
הנה תיאור ה Deployment pipeline שהשתמשנו בו בפוסט הקודם:
בסביבת האינטגרציה יש הזדמנות למפתחים ו/או אנשי ה QA לבצע בדיקות ידניות על קוד - לפני שהוא הולך לפרודקשיין. לאחר שיש לנו אוטומציה מספיק טובה, האם לא טבעי שנפסיק עם התהליך הידני - ופשוט "נפתח את הברז" כך שכל שינוי יזרום ישר לפרודקשיין (לאחר שעבר את כל הבדיקות האוטומטיות)?
יש לכך כמה קשיים עיקריים:
המעבר מביטחון של 95% באוטומציה לביטחון של 100% באוטומציה - אינו קטן!
שמעתי הרצאה של קבוצה בגוגל שלאורך 18 חודשים (שנה וחצי) ניסתה לעבור מ CD ל CDD - ועדיין לא הצליחה. עדיין כ 1% מה commits היו בעייתיים למרות שעברו את הבדיקות, ותהליך השחרור אצלם נותר ידני. כלומר: מפתח מבצע החלטה בכדי להעביר commit לפרודקשיין.
כותרת ההרצאה הייתה אודות "Continuous Deployment" - למרות שלא עמדו בתנאי הרשמי הזה (בסדר מבחינתי!). קצת הופתעתי שהדבר הטריד אותם ונראה שהיה חשוב להצהיר שתוך כמה חודשים הם חושבים שכבר יוכלו לעשות שחרור אוטומטי לחלוטין.
המחשבה המקובלת היא: "נו טוב, המתכנת יגיד איזה פוש ילך לפרודקשיין, ומעט השינויים המסוכנים ילכו עדיין לבדיקה ידנית. זה מספיק CDD". זו חשיבה הגיונית, אין "חובה" להיות קנאיים.
עם הזמן מספר ה commit ילך ויגדל
אולי כי הארגון גדל, ואולי כי המפתחים באמת השתפרו בתהליך ה CI?
כמות ה commits בשעה תלך ותגדל: 1 בשעה, 2 בשעה, אח"כ 5 בשעה, וכו'.
כבר באזור שלושה-ארבעה ה commits בשעה - תהיה בעיה: תהליך ה deploy אורך כ 30 דקות.
מה עושים? נותנים לתור ה commits להצטבר? להיכנס לשעות העומס של המערכת או שעות הלילה? אולי לגלוש למחר?
אולי פשוט נאחד כמה commits ונעשה להם deploy ביחד?
אולי נשקיע מאמץ במיקבול טוב יותר של תהליכי ה deploy?
הבעיה הזו כנראה לא הולכת להיעלם, במיוחד אם אתם ארגון בצמיחה. גם אם תמקבלו את התהליך, את שלב ה deploy עצמו (blue/green או rolling) ואז צפייה בשינויים בסביבה בעקבות ה deploy - תהליך שאורך 10 דקות לפחות, כנראה ולא תוכלו ממש למקבל.
הפתרון המקובל הוא אימוץ של Microservices Architectures. הרבה repositories שונים של קוד, שעוברים deploy לשרתים שונים - מאפשרים מקביליות. כאשר יותר שורות קוד --> יותר שירותים (תנאי של Microservices Architecture) - המקבילות היא, תיאורטית, אינסופית.
Database migration
אם אתם עובדים עם RDBMS אזי המיגרציות:
כאשר יש מיקרו-שירותים, המיגרציה כבר לא כ"כ מפריעה: שירות אחד יכול להיות "תקוע"* על מיגרציה למשך 4 שעות - שאר המערכת ממשיכה להתעדכן כרגיל, וללא הפרעה.
* "תקוע" הכוונה שהשירות עובד - פשוט אי אפשר לבצע עוד deploys בזמן הזה.
(אני קצת חוזר על הנאמר בפוסט הראשון)
הרעיון של Continuous Deployment קיבל תנופה גדולה מתנועת ה Lean Startup, שם צמצום מחזורי הלמידה והפידבק הם ערך מרכזי. הדרישה ל CDD, ע״פ המתודולוגיה, אמורה להגיע כיעד עסקי מה CEO - זה לא עניין ״פנימי״ של ה R&D...
במקום להיות ״נביאים״, או ״יודעי-כל״, תהליך ה CDD מאפשר לנו לנסות בשטח.
הפיצ'ר של אמזון של "אנשים שקנו את X קנו גם את Y", נדחה ע"י אנשי המוצר כ"מטופש" - ובארגון אחר היה נקבר לעד.
התרבות הארגונית של אמזון, שגובתה בעזרת יכולות CDD, אפשרה למפתח שמאוד מאמין במשהו לבצע A/B test (על אוכלוסיה קטנה) - ולנסות להוכיח את צדקתו. כל אחד כמעט - יכול להציע ולהתניע ניסוי.
הניסוי הנ״ל הראה גידול של כ 3% במכירות (נתון מרשים מאוד!) - מה שהסיר מייד כל התנגדות, והפך אותו בן רגע לפיצ׳ר רצוי ע"י הפרודקט.
אם כולם מאמינים במערכת ובנתונים שהיא מייצרת, אזי נתונים מהשטח הם ״מחסלי ויכוחים ארגוניים״.
CDD, אם כן, בשילוב A/B Tests ותרבות ארגונית מתאימה - מספקת Empowerment לעובדים, ויכולה להביא רעיונות חכמים שלהם - לידי יישום.
ישנן עדויות ליתרונות נוספים הנובעים מאימוץ CDD:
לצורך הדיון, אתעלם לרגע האם מדובר ב CD או CDD - זה פחות מהותי.
כמו כן, כמובן שכל ארגון הוא עולם בפני עצמו. אני לא מנסה לתת מתכון אחיד לכל בעיה, אלא להציג כמה גישות חשובות ומהותיות.
נתחיל בגישות העיקריות, הנוגעות לארגונים שרק מתחילים בתהליך האימוץ:
גישה: AquaSlump
בגישה זו אנחנו עובדים קודם כל על הכנת האוטומציה, הבדיקות האוטומטיות ותהליך ה Build - לפני שאנחנו מתחילים לעשות deploy תכוף יותר.
בעצם יש פה פרויקט שצריך להריץ:
מה זה אומר? שהם חוראניים (קרי: רשלניים)? לא מקצועיים? חסרי עתיד ללא ניהול צמוד? ממזרים חסרי כבוד?
זו כנראה גישה שלא הייתה מחזיקה לאורך זמן וצוות גדול יותר (היו להם פחות מ 10 מפתחים).
זו גישה מסוכנת שדורשת הרבה אחריות אישית, וכנראה לא מאפשרת סביבת production נקייה מאוד מבאגים.
אבל זה יותר CD/CDD ממה שארגונים מגיעים אליהם אחרי חודשים של עבודה קשה, בגישת ה AquaSlump.
ג'ז האמבל (המחבר של ספר ה CD המפורסם) מציע ששני המדדים העיקריים לאימוץ של CD יהיו:
בגישת הגרילה מתמקדים במדדים הללו - עד הסוף.
קודם הולכים ומתחילים לעשות Deploys תכופים לפרודקשיין - ואז מתחילים לשפר את התהליך.
המגע המהיר והתכוף עם פרודקשיין הוא בעיקר מלמד: דבר ראשון לומדים שזה לא כ"כ נורא. ושאפשר להוציא כמה וכמה עדכונים לפרודקשיין - בלי להרוס אותו. שתקלות - אפשר לתקן לעתים רבות בזריזות. למשל: הלמידה שהפחד משינויים בפרודקשיין הוא קצת מוגזם (זה בד"כ המצב) - היא כבר למידה חשובה!
בשלב הבא מתחילים להבין:
הסכנה העיקרית בגישה הזו - היא "להיתקע" באמצע הדרך עם מצב בינוני של CD, שהתרגלתם אליו אבל הוא עדיין לא כ"כ יעיל.
אני לא מחשיב את הגישה הזו כמסוכנת יותר לפרודקשיין, מגישת ה AquaSlump. גם בגישה ההיא אפשר לעשות נזקים רבים - ואז, כשהמנגנון גדול וסבוך - דווקא יותר קשה לשפר ולהתאים אותו למציאות שמתגלה.
היתרון של גישת הגרילה - היא שזו הדרך המהירה ובעלת הסיכויים הגדולים יותר להגיע לתוצאות משמעותיות כלשהן במהלך, נאמר, שנה.
חוויתי כמה וכמה מאמצים אדירים בגישת ה AquaSlump - שלא הגיעו לתוצאות משמעותיות (אולי החבר'ה שם עדיין מנסים...?!) וחוויתי פעם אחת את הגישה הרזה - שסיפקה תוצאות יפות בזמן קצר. דעתי בנושא - התגבשה.
"פקקים" ב Deployment Pipeline
במהלך השעה האחרונה נכנסו לי סדרה של ארבעה commits לשירות מסוים: A, B, C, ו D.
commit A - עבר deployment בהצלחה.
commit B - נכשל.
האם אפשר לקחת את commits C +D לפקודקשיין בצורה אוטומטית? חבל לבזבז זמן!
איך יודעים האם הם תלויים ב commit B או לא?
הבעיה איננה בעיה לוגית כ"כ גדולה: בד"כ אפשר לבצע merge אוטומטי של commit C על גבי commit A וללא commit B - ואז להעביר את השינוי ב pipeline. מה שנקרא "commit selection" או "מי הבא בתור?". אבל זה עדיין תהליך, הדורש עבודה וליטוש.
זיהוי בעיות ב UI
בעוד בדיקות אוטומציה הן טובות מאוד לקוד לוגי - קשה הרבה יותר לבדוק UI בצורה אוטומטית ומלאה.
יש סיפור של גוגל איך מתכנת הוסיף לאחד המוצרים אנימציה של unicorn מרקד כאינדיקציה לכך שאיזה Feature Flag, של פיצ'ר שעליו הם עבדו - הוא מודלק.
תהליך ה deploy עבר בהצלחה. המתכנת נכנס לפרודקשיין עם החשבון שלו - וראה את ה unicorn מרקד והכל נראה בסדר!
הוא שכח לבדוק, מה קורה עם משתמש שאינו ברשימת ה beta users של הפיצ'ר. מסתבר שכל משתמשי המוצר (מיליונים!) ראו את ה unicorn המרקד הזה - גם אם הפיצ'ר לא הופעל עבורם.
כיצד מאתרים בעיות מסוג זה? אולי כפתור שזז למקום מוזר? או טקסט שהפך לקטן? - כשהשינויים קטנים, "יקר" לבצע בדיקה ידנית של ה UI על כל deploy (שזה בעצם: commit קטן).
במוצר הספציפי הוסיפו ל pipeline שכבה של בדיקות אוטומציה שעונות "באיזה מסכים היה שינוי בUI, לכלל המשתמשים, בעקבות ה commit". הבדיקות היו מבוססות בעיקר על צילום והשוואת screenshots של המוצר. אם היה שינוי שכזה (שמתגלה ב staging), המפתח צריך לאשר שהשינוי תקין, בכדי שהקוד יגיע לפרודקשיין.
שוב - אין פה rocket science, אך יש פה צורך ספציפי למוצר - שניתן להבין וללמוד אותו רק בעקבות "התנסות בשטח".
תלויות בין מיקרו-שירותים
נניח שיש לי פיצ'ר בשירות X שדורש API מתאים בשירות Y?
זה נשמע אתגר קטן: נגדיר את התלויות. סגור!
בפועל: מצב ה pipeline של כל שירות הוא דינאמי - ולכן קשה לתכנון. בכל רגע נתון יכולים להיות לפני ה commit שלי מספר commits שמחכים להרצה ב pipeline. כיצד אם מוודאים שהשינוי ב API (שירות Y) יהיה זמן בפרודקשיין, לפני שהקוד בשירות X "נוחת" בפרודקשיין בעצמו? אם יש שלושה commits בתור בשירות Y, אך אין תור כלל בשירות X?
שוב - אין פה מדע טילים, אך יש בעיה מציאותית שצריך לפתור, כאשר לא כל פתרון מתאים באותה מידה לכל מוצר / מערכת.
בקיצור: ניסיתי בקטע זה לשלב כמה תובנות של CDD, תוך כדי המחשה מדוע חשוב להתנסות בתהליך הספציפי - לפני שרצים לבנות הרים של אוטומציה.
רעיונות אחרונים בנושא שארצה להוסיף לגבי יישום של CD/CDD:
CD ו CDD מרגישים ממש קרובים - אבל הם לא.
אם ב CD שיגרנו חללית לחלל, מיד גילינו שיש לנו עוד עבודה לגרום לה להשתחרר מהכבידה של כדור הארץ (להלן CDD). לא מאמץ קטן!
אני רוצה להתוודות שכאשר התחלתי את הפוסט... עוד דיקלמתי לעצמי: "אם יש לכם מוצר SaaS - חבל לעצור ב CD. לכו על CDD!"
במהלך כתיבת הפוסט, נוכחתי בעצמי שוב - עד כמה זה לא-פשוט!
ולכן אתקן: אני ממליץ לכל מוצר SaaS להגיע ל 90% CDD. שיהיו הרבה deploys ביום / ביחד למספר המתכנתים. יותר deploys ביום ממפתחים - לפחות.
אם יש מוצר SaaS ואתם משחררים לפרודקשיין רק פעם בשבוע או שבועיים - זה מרגיש פספוס.
אם תבחרו בגישת הגרילה - זה גם לא יהיה כ"כ קשה. מפתיע כמה זה קל!
שיהיה בהצלחה!
נ.ב. - יש!! סיימתי סדרת-פוסטים!
בפוסט הזה אני רוצה להתמקד ולהשלים את הסקירה של Continuous Deployment (לצורך הפוסט: CDD), ולדבר על הטמעה של הפרקטיקות הללו - בארגון שעדיין לא נמצא שם.
תנו לי CDD - ועכשיו!
Continuous Deployment הוא הרעיון שהפער בין קוד המערכת לסביבת הפרדוקשיין יהיה מינימלי - דקות עד שעות ספורות לכל היותר.
שאלה בוודאי שאתם שואלים את עצמם, לאחר הבנת התהליכים של CD - היא מהו הפער ליישום CDD?
הנה תיאור ה Deployment pipeline שהשתמשנו בו בפוסט הקודם:
בסביבת האינטגרציה יש הזדמנות למפתחים ו/או אנשי ה QA לבצע בדיקות ידניות על קוד - לפני שהוא הולך לפרודקשיין. לאחר שיש לנו אוטומציה מספיק טובה, האם לא טבעי שנפסיק עם התהליך הידני - ופשוט "נפתח את הברז" כך שכל שינוי יזרום ישר לפרודקשיין (לאחר שעבר את כל הבדיקות האוטומטיות)?
יש לכך כמה קשיים עיקריים:
המעבר מביטחון של 95% באוטומציה לביטחון של 100% באוטומציה - אינו קטן!
שמעתי הרצאה של קבוצה בגוגל שלאורך 18 חודשים (שנה וחצי) ניסתה לעבור מ CD ל CDD - ועדיין לא הצליחה. עדיין כ 1% מה commits היו בעייתיים למרות שעברו את הבדיקות, ותהליך השחרור אצלם נותר ידני. כלומר: מפתח מבצע החלטה בכדי להעביר commit לפרודקשיין.
כותרת ההרצאה הייתה אודות "Continuous Deployment" - למרות שלא עמדו בתנאי הרשמי הזה (בסדר מבחינתי!). קצת הופתעתי שהדבר הטריד אותם ונראה שהיה חשוב להצהיר שתוך כמה חודשים הם חושבים שכבר יוכלו לעשות שחרור אוטומטי לחלוטין.
המחשבה המקובלת היא: "נו טוב, המתכנת יגיד איזה פוש ילך לפרודקשיין, ומעט השינויים המסוכנים ילכו עדיין לבדיקה ידנית. זה מספיק CDD". זו חשיבה הגיונית, אין "חובה" להיות קנאיים.
עם הזמן מספר ה commit ילך ויגדל
אולי כי הארגון גדל, ואולי כי המפתחים באמת השתפרו בתהליך ה CI?
כמות ה commits בשעה תלך ותגדל: 1 בשעה, 2 בשעה, אח"כ 5 בשעה, וכו'.
כבר באזור שלושה-ארבעה ה commits בשעה - תהיה בעיה: תהליך ה deploy אורך כ 30 דקות.
מה עושים? נותנים לתור ה commits להצטבר? להיכנס לשעות העומס של המערכת או שעות הלילה? אולי לגלוש למחר?
אולי פשוט נאחד כמה commits ונעשה להם deploy ביחד?
אולי נשקיע מאמץ במיקבול טוב יותר של תהליכי ה deploy?
הבעיה הזו כנראה לא הולכת להיעלם, במיוחד אם אתם ארגון בצמיחה. גם אם תמקבלו את התהליך, את שלב ה deploy עצמו (blue/green או rolling) ואז צפייה בשינויים בסביבה בעקבות ה deploy - תהליך שאורך 10 דקות לפחות, כנראה ולא תוכלו ממש למקבל.
הפתרון המקובל הוא אימוץ של Microservices Architectures. הרבה repositories שונים של קוד, שעוברים deploy לשרתים שונים - מאפשרים מקביליות. כאשר יותר שורות קוד --> יותר שירותים (תנאי של Microservices Architecture) - המקבילות היא, תיאורטית, אינסופית.
Database migration
אם אתם עובדים עם RDBMS אזי המיגרציות:
- יכולות לארוך זמן רב (שעה? שעתיים? - כאשר הטבלאות גדולות), ולא ניתנות למיקבול של ממש.
- יכולות לגרום ל downtime קצר בכל מיגרציה (כאשר נניח משנים או מוחקים עמודה).
- טעויות במיגרציה יכולות להיות הרסניות לפעילות המערכת.
כאשר יש מיקרו-שירותים, המיגרציה כבר לא כ"כ מפריעה: שירות אחד יכול להיות "תקוע"* על מיגרציה למשך 4 שעות - שאר המערכת ממשיכה להתעדכן כרגיל, וללא הפרעה.
* "תקוע" הכוונה שהשירות עובד - פשוט אי אפשר לבצע עוד deploys בזמן הזה.
אז למה באמת ארגונים בוחרים ב CDD?!
(אני קצת חוזר על הנאמר בפוסט הראשון)
הרעיון של Continuous Deployment קיבל תנופה גדולה מתנועת ה Lean Startup, שם צמצום מחזורי הלמידה והפידבק הם ערך מרכזי. הדרישה ל CDD, ע״פ המתודולוגיה, אמורה להגיע כיעד עסקי מה CEO - זה לא עניין ״פנימי״ של ה R&D...
במקום להיות ״נביאים״, או ״יודעי-כל״, תהליך ה CDD מאפשר לנו לנסות בשטח.
הפיצ'ר של אמזון של "אנשים שקנו את X קנו גם את Y", נדחה ע"י אנשי המוצר כ"מטופש" - ובארגון אחר היה נקבר לעד.
התרבות הארגונית של אמזון, שגובתה בעזרת יכולות CDD, אפשרה למפתח שמאוד מאמין במשהו לבצע A/B test (על אוכלוסיה קטנה) - ולנסות להוכיח את צדקתו. כל אחד כמעט - יכול להציע ולהתניע ניסוי.
הניסוי הנ״ל הראה גידול של כ 3% במכירות (נתון מרשים מאוד!) - מה שהסיר מייד כל התנגדות, והפך אותו בן רגע לפיצ׳ר רצוי ע"י הפרודקט.
אם כולם מאמינים במערכת ובנתונים שהיא מייצרת, אזי נתונים מהשטח הם ״מחסלי ויכוחים ארגוניים״.
CDD, אם כן, בשילוב A/B Tests ותרבות ארגונית מתאימה - מספקת Empowerment לעובדים, ויכולה להביא רעיונות חכמים שלהם - לידי יישום.
 |
| מקור: Ash Maurya |
ישנן עדויות ליתרונות נוספים הנובעים מאימוץ CDD:
- ע"פ עדות של אינסטגרם ששמעתי - המעבר ל CDD שיפר את מהירות הפיתוח בכך שצמצם הסתבכויות של מפתחים: פחות ספקולציות ("אולי הקוד לא היה מספיק מהיר וכדאי לייעל פה קצת?") ויותר חיבור למעשיות בשטח.
- בגלל שעושים deploy לכל commit באופן נפרד - קל יותר לזהות commits בעייתיים, לתקן אותם, וכך להגביר את הלמידה של המהנדסים. היתרון ההדרגתי בלמידה - מצטבר ליתרון של מהנדסים טובים יותר.
- שביעת הרצון של המפתחים גבוהה יותר, הן בשל שהם עושים משהו שרבים מנסים - אף רק חלק קטן מהתעשייה הגיע אליו בפועל, ואם בגלל שזו באמת סביבת עבודה מתגמלת יותר (רגשית) עבור המפתחים.
אך איך מיישמים CD/CDD בארגון שעדיין לא שם?
לצורך הדיון, אתעלם לרגע האם מדובר ב CD או CDD - זה פחות מהותי.
כמו כן, כמובן שכל ארגון הוא עולם בפני עצמו. אני לא מנסה לתת מתכון אחיד לכל בעיה, אלא להציג כמה גישות חשובות ומהותיות.
נתחיל בגישות העיקריות, הנוגעות לארגונים שרק מתחילים בתהליך האימוץ:
גישה: AquaSlump
בגישה זו אנחנו עובדים קודם כל על הכנת האוטומציה, הבדיקות האוטומטיות ותהליך ה Build - לפני שאנחנו מתחילים לעשות deploy תכוף יותר.
בעצם יש פה פרויקט שצריך להריץ:
- שלב א' - משקיעים בתשתיות build - חשוב מאוד לוודא שמהכנסה של קוד עד להגעה לפרודקשיין הכל הוא 100% אוטומטי.
- שלב ב' - בונים סביבת staging יציבה לאוטומציה. יש פה עניין של הקמת סביבות בצורה אוטומטית ומהירה - זהה לפרודקשיין, הבאת נתונים אמיתיים מפרודשיין, וכתיבת בדיקות End-to-End שיכסו אותנו בצורה טובה ויספקו אמינות שהקוד שאנחנו משחררים הלאה ב pipeline הוא באמת תקין.
- שלב ג' - מביאים את כל חלקי המערכת לרף הבדיקות שנקבע: למשל 85% Code Coverage.
- שלב ד' - מתחילים לאפשר לצוותים לשחרר קוד לפרודקשיין, אזור אחר אזור.
למי שלא הבין עדיין, ה AquaSlump היא מילה נרדפת ל WaterFall - יש עוד מאמינים גדולים בעקרונות ה Waterfall (בעיקר בארגונים גדולים), אך נראה שכולם הפסיקו להשתמש במונח ה"מביך" הזה.
אם תתקלו ב Waterfall ב CD (או בכלל) - סביר יותר שתתקלו בו עוטה שם אחר. אל תתנו לשם השונה לבלבל אתכם!
אם תתקלו ב Waterfall ב CD (או בכלל) - סביר יותר שתתקלו בו עוטה שם אחר. אל תתנו לשם השונה לבלבל אתכם!
"משהו כמו CI/CD אי אפשר לעשות בלי תכנון מסודר ומרכזי" - הוא טיעון ששמעתי לא פעם...
בכל זאת, אם ייקח חצי שנה לפי התוכנית (ואולי שנה+ בפועל?) לראות Deploy מתרחש מקצה לקצה וללמוד מה עובד, מה לא עובד, ואיפה הכאבים הספציפיים של הארגון שלנו - אז זה פשוט לא אג'ילי ולא יעיל.
הסתייגות קלה: אם עשיתם פעולה בהצלחה כבר כמה פעמים, למשל: מעבר ל CI/CD - אז ייתכן ובאמת יעיל לקחת גישה יותר Waterfall-ית שמתמקדת ב Efficiency ולא בלמידה. אתם כבר יודעים כנראה לא מעט. אני מדבר ידע מוכח (ולא משהו כמו ContinuousIntegrationCertification)
 |
| CI/CD/CDD Maturity Model - מודל אידאלי ואוניברסילי ליישום השיטה. תורת הצורות/האידאות של אפלטון בהתגלמותה! מקור |
גישה: Guerilla Transformation
חבר שעבד בסטארט-אפ ישראלי קטן סיפר לי שהם עשו בזמנו 5 וגם 10 deploys ביום. בלי בדיקות יחידה, בלי אוטומציה, בלי "מערכת CI". פשוט קימפלו - וזרקו לפרודקשיין. שהיו בעיות - תיקנו בזריזות.
ע"פ מודל ה Maturity למעלה, או רבים אחרים דומים - התנהלות שכזו לא נמצאת בכלל על הסקאלה!
בכל הפרמטרים החבר'ה האלה היו מתחת לשלב הבסיס הראשוני (קרי: 1-). בתכונה אחת, שלא מוגדרת ברוב המודלים הללו כיישות עצמאית: "כמות ה deploys ביום לפרודקשיין / ביחס למספר המפתחים" - הם היו בדרגה הגבוהה ביותר (קרי: 5).חבר שעבד בסטארט-אפ ישראלי קטן סיפר לי שהם עשו בזמנו 5 וגם 10 deploys ביום. בלי בדיקות יחידה, בלי אוטומציה, בלי "מערכת CI". פשוט קימפלו - וזרקו לפרודקשיין. שהיו בעיות - תיקנו בזריזות.
ע"פ מודל ה Maturity למעלה, או רבים אחרים דומים - התנהלות שכזו לא נמצאת בכלל על הסקאלה!
מה זה אומר? שהם חוראניים (קרי: רשלניים)? לא מקצועיים? חסרי עתיד ללא ניהול צמוד? ממזרים חסרי כבוד?
זו כנראה גישה שלא הייתה מחזיקה לאורך זמן וצוות גדול יותר (היו להם פחות מ 10 מפתחים).
זו גישה מסוכנת שדורשת הרבה אחריות אישית, וכנראה לא מאפשרת סביבת production נקייה מאוד מבאגים.
אבל זה יותר CD/CDD ממה שארגונים מגיעים אליהם אחרי חודשים של עבודה קשה, בגישת ה AquaSlump.
ג'ז האמבל (המחבר של ספר ה CD המפורסם) מציע ששני המדדים העיקריים לאימוץ של CD יהיו:
- כמה commits ל master ביום / ביחס למספר המפתחים.
- כמה זמן אורך מרגע שיש רעיון - ועד שהוא מגיע לפרודקשיין (קרי: lead time).
בגישת הגרילה מתמקדים במדדים הללו - עד הסוף.
קודם הולכים ומתחילים לעשות Deploys תכופים לפרודקשיין - ואז מתחילים לשפר את התהליך.
המגע המהיר והתכוף עם פרודקשיין הוא בעיקר מלמד: דבר ראשון לומדים שזה לא כ"כ נורא. ושאפשר להוציא כמה וכמה עדכונים לפרודקשיין - בלי להרוס אותו. שתקלות - אפשר לתקן לעתים רבות בזריזות. למשל: הלמידה שהפחד משינויים בפרודקשיין הוא קצת מוגזם (זה בד"כ המצב) - היא כבר למידה חשובה!
בשלב הבא מתחילים להבין:
- מה הסיבות הכי נפוצות לשבירה של הפרודקשיין? - ומתחילים להתגונן מהן.
- מה מאט ומקשה על יציאה לפרודקשיין? - ומתחילים להסיר חסמים ולהפוך את התהליך לקל יותר.
כמובן שאפשר ומומלץ להתחיל באיזור מסויים במערכת, שהוא פשוט ו/או חדש.
בשלב הבא, כשמעט מתבגרים - אלו כנראה הדברים שתרצו להתמקד בהם:
בשלב הבא, כשמעט מתבגרים - אלו כנראה הדברים שתרצו להתמקד בהם:
- בדיקות אוטומטיות מהירות, עם כיסוי סביר.
- תהליך של canary release.
- בדיקות post-deployment ויכולת ל rollback מהירה.
- יצירת אווירה שבה טוב ונוח למפתחים לעשות הרבה deploys ביום.
הסכנה העיקרית בגישה הזו - היא "להיתקע" באמצע הדרך עם מצב בינוני של CD, שהתרגלתם אליו אבל הוא עדיין לא כ"כ יעיל.
אני לא מחשיב את הגישה הזו כמסוכנת יותר לפרודקשיין, מגישת ה AquaSlump. גם בגישה ההיא אפשר לעשות נזקים רבים - ואז, כשהמנגנון גדול וסבוך - דווקא יותר קשה לשפר ולהתאים אותו למציאות שמתגלה.
היתרון של גישת הגרילה - היא שזו הדרך המהירה ובעלת הסיכויים הגדולים יותר להגיע לתוצאות משמעותיות כלשהן במהלך, נאמר, שנה.
חוויתי כמה וכמה מאמצים אדירים בגישת ה AquaSlump - שלא הגיעו לתוצאות משמעותיות (אולי החבר'ה שם עדיין מנסים...?!) וחוויתי פעם אחת את הגישה הרזה - שסיפקה תוצאות יפות בזמן קצר. דעתי בנושא - התגבשה.
כמה בעיות של CDD שאולי לא חשבתם עליהן בתוכנית ה AquaSlump שלכם...
"פקקים" ב Deployment Pipeline
במהלך השעה האחרונה נכנסו לי סדרה של ארבעה commits לשירות מסוים: A, B, C, ו D.
commit A - עבר deployment בהצלחה.
commit B - נכשל.
האם אפשר לקחת את commits C +D לפקודקשיין בצורה אוטומטית? חבל לבזבז זמן!
איך יודעים האם הם תלויים ב commit B או לא?
הבעיה איננה בעיה לוגית כ"כ גדולה: בד"כ אפשר לבצע merge אוטומטי של commit C על גבי commit A וללא commit B - ואז להעביר את השינוי ב pipeline. מה שנקרא "commit selection" או "מי הבא בתור?". אבל זה עדיין תהליך, הדורש עבודה וליטוש.
זיהוי בעיות ב UI
בעוד בדיקות אוטומציה הן טובות מאוד לקוד לוגי - קשה הרבה יותר לבדוק UI בצורה אוטומטית ומלאה.
יש סיפור של גוגל איך מתכנת הוסיף לאחד המוצרים אנימציה של unicorn מרקד כאינדיקציה לכך שאיזה Feature Flag, של פיצ'ר שעליו הם עבדו - הוא מודלק.
תהליך ה deploy עבר בהצלחה. המתכנת נכנס לפרודקשיין עם החשבון שלו - וראה את ה unicorn מרקד והכל נראה בסדר!
הוא שכח לבדוק, מה קורה עם משתמש שאינו ברשימת ה beta users של הפיצ'ר. מסתבר שכל משתמשי המוצר (מיליונים!) ראו את ה unicorn המרקד הזה - גם אם הפיצ'ר לא הופעל עבורם.
כיצד מאתרים בעיות מסוג זה? אולי כפתור שזז למקום מוזר? או טקסט שהפך לקטן? - כשהשינויים קטנים, "יקר" לבצע בדיקה ידנית של ה UI על כל deploy (שזה בעצם: commit קטן).
במוצר הספציפי הוסיפו ל pipeline שכבה של בדיקות אוטומציה שעונות "באיזה מסכים היה שינוי בUI, לכלל המשתמשים, בעקבות ה commit". הבדיקות היו מבוססות בעיקר על צילום והשוואת screenshots של המוצר. אם היה שינוי שכזה (שמתגלה ב staging), המפתח צריך לאשר שהשינוי תקין, בכדי שהקוד יגיע לפרודקשיין.
שוב - אין פה rocket science, אך יש פה צורך ספציפי למוצר - שניתן להבין וללמוד אותו רק בעקבות "התנסות בשטח".
תלויות בין מיקרו-שירותים
נניח שיש לי פיצ'ר בשירות X שדורש API מתאים בשירות Y?
זה נשמע אתגר קטן: נגדיר את התלויות. סגור!
בפועל: מצב ה pipeline של כל שירות הוא דינאמי - ולכן קשה לתכנון. בכל רגע נתון יכולים להיות לפני ה commit שלי מספר commits שמחכים להרצה ב pipeline. כיצד אם מוודאים שהשינוי ב API (שירות Y) יהיה זמן בפרודקשיין, לפני שהקוד בשירות X "נוחת" בפרודקשיין בעצמו? אם יש שלושה commits בתור בשירות Y, אך אין תור כלל בשירות X?
שוב - אין פה מדע טילים, אך יש בעיה מציאותית שצריך לפתור, כאשר לא כל פתרון מתאים באותה מידה לכל מוצר / מערכת.
בקיצור: ניסיתי בקטע זה לשלב כמה תובנות של CDD, תוך כדי המחשה מדוע חשוב להתנסות בתהליך הספציפי - לפני שרצים לבנות הרים של אוטומציה.
קצרים
רעיונות אחרונים בנושא שארצה להוסיף לגבי יישום של CD/CDD:
- פגישת Slow Deployment Retrospective - לא משנה השם, אבל אם לא תדאגו לשפר כל הזמן את תהליך ה deploy שלכם - הוא הולך להיות אטי ומסורבל עם הזמן. במיוחד כאשר המוצר והחברה בשלבי גדילה.
- ב Lean Startup (ממנו הגיע ה CDD) ה Definition of Done של פיצר הוא "הפיצ'ר ייצר את האימפקט המצופה בפרודקשיין". לא סוגרים "טיקט" עד שלא מגיעים לשם, כלומר: עושים עוד ועוד איטרציות על הפיצ'ר עד שהאיפקט מושג. לסירוגין: אפשר להחליט שהפיצ'ר פשוט לא שווה את ההשקעה המסתמנת.
- ב CDD מן הראוי, לא לסגור טיקט של פיצ'ר לפחות עד שלא רואים אותו בפרודקשיין. שינוי קטן ב Jira - ושינוי קצת יותר גדול ב mindset.
- תזכורת: כמו ב CD - בעיות פרודקשיין ובעיות ב Deployment pipeline מטפלות בדחיפות הגבוהה ביותר בארגון! הזנחה של הכלל הזה - היא דרך מצוינת להכשיל יישום CD/CDD.
- Hello Prod (על משקל "Hello World") - כאשר מפתחים שירות חדש, דבר ראשון שלחו את ה template של שירות חדש (להלן "Hello Prod") לפרודקשיין - ועליו תתחילו לפתח. בפרודקשיין. אל תחכו שבוע או שבועיים עם קוד בצד לפני שראיתם פרודקשיין. מייד!
- זה תרגיל מצויין כדי להתחיל לתרגל CDD, גם אם אתם ממש בתחילת התהליך.
- שאיפה של מוצר CDD הוא שעם הזמן (וגדילת מספר העובדים), קצב השחרורים לפרודשיין /יחסית למספר המפתחים - רק יגדל!
סיכום
CD ו CDD מרגישים ממש קרובים - אבל הם לא.
אם ב CD שיגרנו חללית לחלל, מיד גילינו שיש לנו עוד עבודה לגרום לה להשתחרר מהכבידה של כדור הארץ (להלן CDD). לא מאמץ קטן!
אני רוצה להתוודות שכאשר התחלתי את הפוסט... עוד דיקלמתי לעצמי: "אם יש לכם מוצר SaaS - חבל לעצור ב CD. לכו על CDD!"
במהלך כתיבת הפוסט, נוכחתי בעצמי שוב - עד כמה זה לא-פשוט!
ולכן אתקן: אני ממליץ לכל מוצר SaaS להגיע ל 90% CDD. שיהיו הרבה deploys ביום / ביחד למספר המתכנתים. יותר deploys ביום ממפתחים - לפחות.
אם יש מוצר SaaS ואתם משחררים לפרודקשיין רק פעם בשבוע או שבועיים - זה מרגיש פספוס.
אם תבחרו בגישת הגרילה - זה גם לא יהיה כ"כ קשה. מפתיע כמה זה קל!
שיהיה בהצלחה!
נ.ב. - יש!! סיימתי סדרת-פוסטים!
