על היוגי והקומיסר

דמיינו ישיבה: כמה ראשי-צוותים, כמה ארכיטקטים, כמה מובילים טכניים.

"כבר עשינו עבודת הכנה מקיפה לגבי המעבר ל MDA (קרי: Model-Driven Architecture):", פתח הארכיטקט הבכיר (להלן א׳, שמו שמור במערכת). "הגדרנו Meta-Model לכל המערכת שלנו, וביססנו אותו על Meta-Meta Model (או super model). יש לנו רשימה של נקודות שצריך עוד לסגור - אבל אנחנו כבר יכולים להתחיל. הצוות של יוסי החל ליישם Repository למודלים, ועוד חודשיים נוכל כבר לתת לכל שאר הצוותים בארגון להמיר את הקוד שלהם למבנה ה MDA."

כמה מאיתנו פשוט נעמדנו. היה קשה לנו לשבת. ידענו שא׳ הוא ״בקטע״ של MDA - אבל לא ציפינו למשהו כזה.
"אתה מציע שנשכתב את הארכיטקטורה של כל המוצר שלנו? זה מה שאתה אומר??".
"כן, בוודאי. יש כבר הסכמה של ההנהלה בנושא" - ענה א׳ ברוגע מעורר ביטחון.

"אבל מה היתרון בלעבור ל MDA??" - הזעיף פנים ראש צוות אחד, בחור קצת מחומם.

"זו פרקטיקה בצמיחה, יש כבר 'body of knowledge' שהולך ונבנה בתחום, ויש גם כמה יישומים מוצלחים (במיוחד בעולם ה Databases)" - ענה א׳ בלי למצמץ, בלי לשדר אי-נוחות, בלי בושה.

"אבל מה היתרון בשבילנו, למוצר שלנו??" - נשאל שוב. "עכשיו אני אמור להשקיע חצי שנה עם הצוות בשינוי ארכיטקטורה - בשביל מה??"

"אה... אתה צודק מאוד." - נראה שלא׳ נפל סוף-סוף האסימון.
"אנחנו נכתוב רשימה של היתרונות של MDA ונראה אילו הכי משמעותיים עבורנו, נתמקד במה ששימושי עבורנו, כמובן. נקודה טובה!".


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

- כך זה לפעמים נראה מהשטח.
אני זוכר שכעסתי אינספור פעמים על החלטות שנראו לי מנותקות ומעווותות. כעסתי או שהייתי מתוסכל.

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

מה קורה פה בעצם?

(בעקבות שאלה: לא, זה לא אירוע שקרה בגטט... אלא שנים רבות לפני כן)

מקור: https://vidyow.com/video/the-main-differences-between-t/vcbaDoo8guL

ציר טראמפ-אובמה

למזלנו, ההיסטוריה העכשווית מספקת לנו מטאפורה רלוונטית שקל להתייחס אליה*.

* אני לא מתכוון לעשות ניתוח פוליטי מעמיק או אפילו שטחי, אלא להתייחס ל״תפיסה המקובלת״ לגבי האישים. מקובלת - כפי שאני מכיר וחווה אותה בסביבתי.

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

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


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

האם ייתכן שאובמה לא הצליח לעשות הרבה ב-2 הכהונות שלו?
האם ייתכן שטראמפ לא יחריב את ארצות הברית, ואולי יעשה כמה דברים טובים?

על טראמפ קל לצחוק. אני אישית נהנה - אני מודה!

הוא מספק לי בידור לפחות פעמיים בשבוע. תיאור המעשים שלו בעיתונות (/ טוויטר) - גורם לי להרגיש נבון יותר!

הנה סיפור נוסף לדוגמה מעולם הטכנולוגיה. איזו חוסר הבנה!....:

מקור: הפוסט http://getindata.com/blog/post/lean-big-data-how-to-avoid-wasting-money-with-big-data-technologies-and-get-some-roi

כשנתקלתי לראשונה בתיאור הזה החוויה שלי הייתה: הנאה. איזה סיפור מצוין. ("כל-כך נכון!")
שמרתי את התמונה בצד - ואמרתי לעצמי שאכלול אותה באיזה פוסט. לא חשבתי שזה יהיה הפוסט.

יש משהו ציני וקוטבי בתיאור המקרה הזה (ובדומים לו):

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

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

מה הסיפור שלכם?

חשבו. האם יש סיפור דומה שאתם נתקלתם בו?

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

כמה נקודות למחשבה:

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

It's all about tradeoffs

בסופו של דבר אפשר לומר שיש סקאלה של שני סגנונות הפוכים:

• בקצה אחד: היוגי ("אובמה") - אדם שכלתן, שקול, בקיא בפרטים  אבל גם  מתקשה לקבל החלטות ולפעול בסביבה של אי-וודאות.
• בקצה השני: הקומיסר ("טראמפ") - אדם עם דרייב, המוכן לקחת סיכונים, להוביל  אבל גם  חסר סבלנות לדקויות

כל אחת מהקיצוניות - איננה יעילה במיינסטרים (אולי ברגעי משבר או רגעים קיצוניים):

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

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

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

סיכום

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

אני בהחלט יותר יוגי מקומיסר. זה כנראה משתקף בפוסט, אך הנחתי שגם רוב הקוראים של הבלוג הם כאלו.

הייתי מנסה לנסח את נקודות המחשבה הבאות (ניסוח ראשוני):

• אם אתם פוגשים בקומיסר/יוגי מרתיע, חשבו: האם יש לכם שותפות בכוונות / יעדים? אם כן - כנראה שהמצב לא כ"כ רע!
• גם אם דרכו של הקומיסר / יוגי משונה לכם ("אידיוט!"☺) - נסו להבין מה עומד מאחוריה. כנראה שיש שם תובנה שקשה לאדם השני לתאר בצורה פשוטה. בכל זאת, יש סיכוי טוב שיש בה ערך. אם תיקחו את הרעיון ותפתחו אותו - אולי תמצאו משהו חשוב - שפספסתם!
• חשבו על הצוות שלכם: 
• האם הבחור ההוא שנראה קצת מטופש הוא Executor טוב, חסר מורא? אולי תוכלו להעריך אותו ולהיעזר בו כקומיסר.
• האם הבחור השני, שמתקשה לקחת החלטות, ונתקע בפרטים הוא בעצם אדם נבון עם תובנות עמוקות? אולי תוכלו להעריך אותו ולהיעזר בו כיוגי.

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

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

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


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

אז... אתם רוצים Continuous Deployment? (חלק ג')

בפוסט הקודם בסדרה דיברנו על Continuous Delivery (בקיצור CD), על ה Deployment Pipeline, ופרקטיקות נוספות.

בפוסט הזה אני רוצה להתמקד ולהשלים את הסקירה של 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 קצר בכל מיגרציה (כאשר נניח משנים או מוחקים עמודה).
• טעויות במיגרציה יכולות להיות הרסניות לפעילות המערכת.

הפתרונות המקובלים הוא לעבור לפתרונות בהם כמעט ולא צריך מיגרציה: Document Databases על פני Relational Databases, או Databases שבהם המיגרציה היא נוחה יותר (למשל PostgreSQL על פני MySQL).

כאשר יש מיקרו-שירותים, המיגרציה כבר לא כ"כ מפריעה: שירות אחד יכול להיות "תקוע"* על מיגרציה למשך 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 בעייתיים, לתקן אותם, וכך להגביר את הלמידה של המהנדסים. היתרון ההדרגתי בלמידה - מצטבר ליתרון של מהנדסים טובים יותר.
• שביעת הרצון של המפתחים גבוהה יותר, הן בשל שהם עושים משהו שרבים מנסים - אף רק חלק קטן מהתעשייה הגיע אליו בפועל, ואם בגלל שזו באמת סביבת עבודה מתגמלת יותר (רגשית) עבור המפתחים.

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

אך איך מיישמים CD/CDD בארגון שעדיין לא שם?

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

נתחיל בגישות העיקריות, הנוגעות לארגונים שרק מתחילים בתהליך האימוץ:

גישה: AquaSlump

בגישה זו אנחנו עובדים קודם כל על הכנת האוטומציה, הבדיקות האוטומטיות ותהליך ה Build - לפני שאנחנו מתחילים לעשות deploy תכוף יותר.

בעצם יש פה פרויקט שצריך להריץ:

• שלב א' - משקיעים בתשתיות build - חשוב מאוד לוודא שמהכנסה של קוד עד להגעה לפרודקשיין הכל הוא 100% אוטומטי.
• שלב ב' - בונים סביבת staging יציבה לאוטומציה. יש פה עניין של הקמת סביבות בצורה אוטומטית ומהירה - זהה לפרודקשיין, הבאת נתונים אמיתיים מפרודשיין, וכתיבת בדיקות End-to-End שיכסו אותנו בצורה טובה ויספקו אמינות שהקוד שאנחנו משחררים הלאה ב pipeline הוא באמת תקין.
• שלב ג' - מביאים את כל חלקי המערכת לרף הבדיקות שנקבע: למשל 85% Code Coverage.
• שלב ד' - מתחילים לאפשר לצוותים לשחרר קוד לפרודקשיין, אזור אחר אזור.

למי שלא הבין עדיין, ה AquaSlump היא מילה נרדפת ל WaterFall - יש עוד מאמינים גדולים בעקרונות ה Waterfall (בעיקר בארגונים גדולים), אך נראה שכולם הפסיקו להשתמש במונח ה"מביך" הזה.
אם תתקלו ב 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).

מה זה אומר? שהם חוראניים (קרי: רשלניים)? לא מקצועיים? חסרי עתיד ללא ניהול צמוד? ממזרים חסרי כבוד?
זו כנראה גישה שלא הייתה מחזיקה לאורך זמן וצוות גדול יותר (היו להם פחות מ 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 ואתם משחררים לפרודקשיין רק פעם בשבוע או שבועיים - זה מרגיש פספוס.

אם תבחרו בגישת הגרילה - זה גם לא יהיה כ"כ קשה. מפתיע כמה זה קל!

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


נ.ב. - יש!! סיימתי סדרת-פוסטים!