זה עתה חזרתי מ-3 ימי כנס ";GOTO" שהתרחש בברלין.
כחלק מתהליך התייעלות בסאפ, שולחים פחות אנשים לכנסים תוך התחייבות להעביר אח"כ את הידע (בלוג פנימי, הרצאות) בתוך החברה.
מה יותר טבעי עבורי מלהעביר סיכום גם כאן בבלוג? (בוריאציה מעט שונה, לקהל מעט שונה).
כנסי ;GOTO הם סדרה של כנסים שרצים ברחבי ארה"ב ואירופה (שיקאגו, ברלין, אמסטרדם, אורהוס, וקונפהגן) ומתמקדים ב Software Craftsmanship, ארכיטקטורה, אג'ייל, DevOps, וטכנולוגיות "חמות".
הרבה מרצים מפורסמים מגיעים לשם כ"דרך קבע": Martin Fowler, Kent Beck, רוד ג'ונסון, בכירים באמזון, עובדי ThoughtWorks השונים, ועוד. כמעט לא תמצאו שם אנשים מגוגל או מסטראט-אפים אלמונים, אלא יותר מרצים שהם מחברי ספרים (איני יודע אם זו דרישה מפורשת), מובילים של קהילות (למשל מובילת קהילת הפייטון באנגליה), או לקוחות של ThoughtWorks (למשל: חברות ביטוח ובנקים) ושל אמאזון (למשל: נטפליקס).
נדמה לי שהשנה הייתי הישראלי היחידי בכנס.
חוץ מכך שהייתי ב QCON London 2008 (סדרת כנסים "אחות" של ;GOTO) - אני עוקב כמעט כל שנה אחרי תוכן כנס GOTO בכדי להתעדכן בטרנדים העכשוויים.
מגמה אחת שאני מזהה בתכנים, היא נוכחות גוברת של נושאי UX בכנס. לפחות ע"פ מתכנני הכנס - נראה אנשי תוכנה הולכים ומתעניינים יותר ב UX כחלק אינטגרלי מהפיתוח - וכחלק שמעניין את אנשי הפיתוח. מי יודע? אולי עוד שנתיים נשמע על UX Culture (כמו DevOps culture) ועל כך שיש לשלב את איש ה UX כחלק אינטגרלי מצוות הפיתוח?
ז'רגון
כמה ביטויים ששמעתי בכנס שוב ושוב, ושאני לא נוהג לשמוע כ"כ ביום-יום:
מרטין, בכריזמה מיוחדת, התנצל על כך שהוא ממחזר keynotes בין כנסים. הוא החליט לתת שני keynotes בזה אחר זה - בכדי לצמצם את האפשרות שהצופים מכירים את מה שהוא הולך לדבר עליו.
ההרצאה הראשונה הייתה מבוססת בעיקרה על הפוסט של מרטין ממרץ השנה על micro-services, וכללה מעט הסברים חדשים. בקיצור, מרטין מתאר שם 9 תכונות מקובלות של מיקרו-שירותים:
נושא המיקרו-שירותים שווה פוסט בפני עצמו. האמת שיש לי כבר פוסט כזה בעבודה, נקווה שאגיע ל delivery...
עוד 2 עניינים שעלו, כקריאה לפעולה מהמפתחים הם:
עוד לפני הכנס עצמו, היה יום שלם של סדנאות לימוד בקבוצות קטנות. מאוד התעניינתי ב System Thinking של מייקל נייגארד, אבל בחרתי בסוף בפרקטי - והלכתי לסדנאת Continuous Delivery של Jez Humble.
ג'ז (קיצור של Jessie שזה קיצור של Jayson, אני מניח) הוא הבחור שכתב את הספר המפורסם "Continuous Delivery" וגם העביר בהמשך הכנס הרצאה בהשראת הספר החדש שלו: "The Lean Enterprise" (שנראה לי שבעקבותיה ארכוש אותו).
ג'ז היה מגניב למדי. שמח, משעשע, משוחרר (קרא "Shitty" לכל דבר שחשב שהוא לא מוצלח), וסיפק תובנות טובות.
אני לא הולך לכתוב פה פוסט שלם על Continuous Delivery, אלא רק להזכיר את התובנות העיקריות שעלו:
דבר ראשון הוא ההבחנה שההבדל בין Continuous Delivery ל Continuous Deployment הוא לא בשלבים שונים של אותו התהליך, אלא ביכולת לספק כל אחד בהקשר הנתון. ג'ז קיטלג מערכות תוכנה לשלוש קטגוריות:
קצת מבלבל ששני המונחים מתקצרים לצירוף CD, בדיעבד - אולי זה כבר לא משנה.
הוא עבר על use-case כיצד HP העבירו את תהליך פיתוח ה Firmware שלהם למדפסות שלהם - ל CD. רוב העיסוק היה באופן בו נבנה והתפתח ה deployment pipeline שלהם.
המעבר "עלה" בשנתיים של כמעט-השבתה של התהליכים השוטפים, אבל ההישגים - היו משמעותיים. כמות פיתוח הקוד החדש (Innovation) - עלתה פי 8!
בצד ימין, סה"כ התשומות לא מתחברת ל 100%. 23% נמצאים בתחזוקת האוטומציה (בדיקות בעיקר) - מה שעשוי להראות ב waste - עד הרגע בו משווים כמה זמן נותן סה"כ ל innovation - שזהו בעצם יצירת הערך היחידה בכל התהליך.
ה Use-Case הזה מתואר במפורט בספר בשם Large-Scale Agile Development.
עוד תובנות ספורדיות:
שיהיה בהצלחה,
ליאור
------
[א] בסשן אחר שאל המציג את הקהל: "כמה מכם יכולים לדחוף מ production פיצ'ר לאחר שה VP Marketing אמר שזה רעיון רע?" (כמו בסיפור של אמזון).
באופן מפתיע למדי, כעשרים אחוז מהקהל הרים יד. אולי בגלל שהיו הרבה סטארט-אפיסטים (?!) אולי גם האווירה הליברלית של ברלין.
כחלק מתהליך התייעלות בסאפ, שולחים פחות אנשים לכנסים תוך התחייבות להעביר אח"כ את הידע (בלוג פנימי, הרצאות) בתוך החברה.
מה יותר טבעי עבורי מלהעביר סיכום גם כאן בבלוג? (בוריאציה מעט שונה, לקהל מעט שונה).
 |
| Martin Fowler מגיע למתחם Kosmos - לתת את ה Keynote הראשי. חבר הסביר לי שהמבנה נבנה בתקופה הסובייטית - ושיש עוד רבים ממש כמותו. |
הרבה מרצים מפורסמים מגיעים לשם כ"דרך קבע": Martin Fowler, Kent Beck, רוד ג'ונסון, בכירים באמזון, עובדי ThoughtWorks השונים, ועוד. כמעט לא תמצאו שם אנשים מגוגל או מסטראט-אפים אלמונים, אלא יותר מרצים שהם מחברי ספרים (איני יודע אם זו דרישה מפורשת), מובילים של קהילות (למשל מובילת קהילת הפייטון באנגליה), או לקוחות של ThoughtWorks (למשל: חברות ביטוח ובנקים) ושל אמאזון (למשל: נטפליקס).
נדמה לי שהשנה הייתי הישראלי היחידי בכנס.
מה נשתנה?
חוץ מכך שהייתי ב QCON London 2008 (סדרת כנסים "אחות" של ;GOTO) - אני עוקב כמעט כל שנה אחרי תוכן כנס GOTO בכדי להתעדכן בטרנדים העכשוויים.
מגמה אחת שאני מזהה בתכנים, היא נוכחות גוברת של נושאי UX בכנס. לפחות ע"פ מתכנני הכנס - נראה אנשי תוכנה הולכים ומתעניינים יותר ב UX כחלק אינטגרלי מהפיתוח - וכחלק שמעניין את אנשי הפיתוח. מי יודע? אולי עוד שנתיים נשמע על UX Culture (כמו DevOps culture) ועל כך שיש לשלב את איש ה UX כחלק אינטגרלי מצוות הפיתוח?
ז'רגון
כמה ביטויים ששמעתי בכנס שוב ושוב, ושאני לא נוהג לשמוע כ"כ ביום-יום:
- a Unicorn - כינוי לחברות שהן thought Leaders בנושאי טכנולוגיה, כמו פייסבוק, נטפליקס, או Etsy, בניגוד ל Horse - חברות "רגילות".
"ההבדל היחידי בין unicorns לסוסים - הוא PR" - מיהר אחד המרצים לנסות ולאזן את ההייפ. כן, גם אצל ה unicorns הקוד נרקב ("code rots"). - Shaving Yaks - פעולה ארוכה ומתישה, שבסופה אף אחד לא זוכר כיצד ומדוע היא התחילה:
"?!Why the hell, were we shaving this Yak" - Bounded Context - רעיון מעולם ה DDD, שמציע פתרון ל business logic מורכב מדי לתחזוקה.
הרעיון הוא להגדיר "הקשרים מוגבלים" (bounded context) במודל,
לדוגמה: יש לנו מערכת לניהול לקוחות. במקום ליצור מודל אחד שמטפל גם במכירות וגם בתמיכה (support), אנו יוצרים שני מודלים, בלתי תלויים, של העולם (לקוח, מוצר, עסקה) שכל אחד מתמחה בהקשר המוגבל שלו: מכירות או תמיכה.
הרעיון הועלה כמה פעמים בכנס - כדרך לפרק מערכת מונוליטית גדולה למיקרו-שירותים. - Two-pizzas Team - ביטוי שצמח באמזון, ואומץ ע"י SCRUM לבטא צוותים של "בערך" 8 אנשים (או 16 בחורות ממש רזות :) ) - מה שניתן להאכיל בעזרת 2 פיצות אמריקאיות גדולות.
- T-Shaped Person - תיאור המבטא איש מקצוע רצוי, בעל רוחב (קו אופקי), וגם עומק מקצועי (קו אנכי). הרוחב מתבטא בהכרות עם נושאים שונים והיכולת לתקשר היטב עם אנשים מתחומים שונים.
באחת המצגות המציג הציג שארכיטקט אמור להיות π-Shaped Person, כאשר לו רגל של הבנה טכנית עמוקה, ורגל שנייה של הבנה עסקית עמוקה.
רעיונות שחזרו על עצמם שוב ושוב בהרצאות
- Micro-Services היו כנראה ה-Highlight של הכנס, ומדברים עליהם כבר כארכיטקטורת "ברירת-המחדל" למערכות ווב בענן.
- Breaking Down Silos (למשל עם DevOps או עם ה Business) - בכדי להשיג אג'ייל אפקטיבי.
- אג'ייל (וסקראם בפרט) דורשים תיקונים. סקראם הוא מעט נוקשה, ולא כ"כ פתוח לשינויים.
- התלהבות גדולה מ Docker - ככלי ל Continuous Deployment מהיר יותר.
- התלהבות מה Netflix Chaos Monkey (סיפרו עליו ב 3 הרצאות שהייתי, כולל ה keynote) - תהליך שתפקידו להרוג שירותים אמיתיים ב production בכדי לאתגר את מנגנוני ההתאוששות של המערכת.
- שימוש ב Strangler Pattern על מנת לבצע מעבר הדרגתי בארכיטקטורה. בעיקר מ Layered Architecture ל Micro-Services Architecture.
ה Keynote הפותח (מרטין פאוולר)
מרטין, בכריזמה מיוחדת, התנצל על כך שהוא ממחזר keynotes בין כנסים. הוא החליט לתת שני keynotes בזה אחר זה - בכדי לצמצם את האפשרות שהצופים מכירים את מה שהוא הולך לדבר עליו.
- Software Development in the 21st Century - שבעצם עסק ב Micro-Services והחיבור הטוב שלהם לענן ול Continuous Deployment.
- מצגת ללא כותרת - מכיוון שהוא התקשה למצוא לה כותרת. אולי הקהל יוכל לעזור לו.
ההרצאה הראשונה הייתה מבוססת בעיקרה על הפוסט של מרטין ממרץ השנה על micro-services, וכללה מעט הסברים חדשים. בקיצור, מרטין מתאר שם 9 תכונות מקובלות של מיקרו-שירותים:
- Componentization via Services
- Organized around Business Capabilities
- Products not Projects
- Smart endpoints and dumb pipes
- Decentralized Governance
- Decentralized Data Management
- Infrastructure Automation
- Design for failure
- Evolutionary Design
נושא המיקרו-שירותים שווה פוסט בפני עצמו. האמת שיש לי כבר פוסט כזה בעבודה, נקווה שאגיע ל delivery...
ההרצאה השנייה היתה אוסף של רעיונות שונים, ולכאורה לא קשורים:
הרצון לבצע כמה תיקונים ועדכונים ל SCRUM - לאור הניסיון שנצבר
התלונה העיקרית הייתה בכך שה PO הוא ה"מוח" היחידי בכל הנוגע להגדרת המוצר - והמפתחים הם רק מבצעים.
מרטין סיפר על מקרה שקרה באמזון - בו מתכנת באמזון הציע פי'צר חדש: "לקוחות שקנו מוצר X קנו גם מוצר Y, עם קישור למוצר Y". הרעיון עלה ל VP Marketing שביטל אותו במקום: "לא צריך להפריע ללקוחות בזמן תהליך הקנייה, שהם כבר שם - לא מפריעים להם!". המתכנת בכל זאת הלך ו"דחף" ל production את הפי'צר - שהראה מיידית (בעזרת A/B testing) עליה של 3% ברווחים. ה VP התעצבן על המהלך - אך לא יכל ללכת נגד צמיחה של 3% ברווחים בהשקעה כ"כ קטנה[א].
מלבד כך ש AB Testing היא לא פרקטיקה של סקראם (אלא Lean Startup) - הרעיון העיקרי הוא שלמתכנתים יש יתרון בהבנת ה feasibility של פיצ'רים - והם יכולים לתרום הרבה. "השתקה" שלהם, מפאת קולו היחיד של ה PO - נראית כמו טעות היסטורית גדולה.
מרטין המליץ שבמוצר יהיה Conversational Stories - שנוצרים במשותף ע"י POs ולא-POs. בכל זאת, עדיין ההמלצה היא לתת משקל רב יותר ל POs (למשל: לקבוע priorities, בהנחה שזה לא כלי לייבש כל מה שלא הגיע מה PO).
עוד אלמנט היה האחריות של המפתחים לדאוג למשתמשי ולקוחות המערכת (ולא רק לרזומה שלהם עצמם - באימוץ טכנולוגיות חדשות). למשל: בהגנה על פרטיות ואבטחה על המשתמשים - אפילו אם ה PO לא דוחף לשם ביזמתו.
Dark Patterns
Dark Patterns הם דפוסים של מערכת, שנוהגת בהטעיה / חוסר צדק כלפי המשתמש. לדוגמה: חנות אונליין שמוסיפה בעת הרכישה של מוצר מסוים, ביטוח או אחריות בתשלום - שהלקוח בכלל לא ביקש. הניסיון הוא שהלקוח לא ישים לב וירכוש בנוסף מוצר שלא התכוון לרכוש - מה שאנו מכירים בלבנט היטב כ "שיטת מצליח" (קרה לי פעם - זה באמת מעצבן!).
בשלב זה מרטין נכנס למצב תוכחה וממש גער במפתחים "אם המנהל שלכם אמר לכם להכניס כזה פיצ'ר למוצר - זה לא פוטר אתכם!".
"...אל תגידו 'רק מילאתי פקודה'. אתם שותפים באחריות!".
לא היה ברור לי אם מרטין הבין את משמעות המשפט הזה לקהל הגרמני, ועוד בכמעט-צעקה. אני בלעתי את הרוק כשהוא קרא את הקריאה הזו.
"...אל תגידו 'רק מילאתי פקודה'. אתם שותפים באחריות!".
לא היה ברור לי אם מרטין הבין את משמעות המשפט הזה לקהל הגרמני, ועוד בכמעט-צעקה. אני בלעתי את הרוק כשהוא קרא את הקריאה הזו.
בסופו של דבר הוא דווקא יצא מזה יפה: הוא לא קרא לאנשים להתפטר (מה שלא סביר לדרוש) - הוא אמר להם כך: "עשיתם משהו רע, וזה באחריותכם. עכשיו יהיה עליכם למצוא משהו טוב לעשות - על מנת לאזן את זה". הנה דרישה שאנשים יכולים לחיות איתה.
קריאה לפעולה
עוד 2 עניינים שעלו, כקריאה לפעולה מהמפתחים הם:
- להשפיע ולתרום למאבק בפרטיות ברשת האינטרנט. הייתה לו הרצאה נוספת שלמה בנושא, בניסיון להסביר ש: "לא עשיתי כלום רע" היא לא סיבה שלא יעקבו אחריכם. ברגע שעקבו כבר אחריכם - יש מידע שניתן לנצל כנגדכם. לדוגמה: היה לי משבר בחיים שאני לא מתבייש בו, אבל פרסום מגמתי שלו בשלב מאוחר יותר בחיים - יכול לפגוע בי.
- להימנע מ Alienating Atmosphere (אווירה גיקית עמוקה) בתעשיית התוכנה, שמרחיקה "אנשים חברתיים" ונשים מהתחום.
למה לדאוג? כי באופן הזה התעשייה מאבדת הרבה כישרון. הנה מאמר שהוא הזכיר - כיצד אחוז הנשים בהייטק שבארה"ב פחת משמעותית לאורך השנים, אולי בעקבות "מתקפת הגיקים" על התעשייה.
בסוף המצגת עלה למרטין "לפתע" רעיון לשם למצגת, ואז השם הופיע בשקף האחרון: "Professionals, not just code monkeys".
סדנה: Continuous Delivery
עוד לפני הכנס עצמו, היה יום שלם של סדנאות לימוד בקבוצות קטנות. מאוד התעניינתי ב System Thinking של מייקל נייגארד, אבל בחרתי בסוף בפרקטי - והלכתי לסדנאת Continuous Delivery של Jez Humble.
ג'ז (קיצור של Jessie שזה קיצור של Jayson, אני מניח) הוא הבחור שכתב את הספר המפורסם "Continuous Delivery" וגם העביר בהמשך הכנס הרצאה בהשראת הספר החדש שלו: "The Lean Enterprise" (שנראה לי שבעקבותיה ארכוש אותו).
ג'ז היה מגניב למדי. שמח, משעשע, משוחרר (קרא "Shitty" לכל דבר שחשב שהוא לא מוצלח), וסיפק תובנות טובות.
אני לא הולך לכתוב פה פוסט שלם על Continuous Delivery, אלא רק להזכיר את התובנות העיקריות שעלו:
דבר ראשון הוא ההבחנה שההבדל בין Continuous Delivery ל Continuous Deployment הוא לא בשלבים שונים של אותו התהליך, אלא ביכולת לספק כל אחד בהקשר הנתון. ג'ז קיטלג מערכות תוכנה לשלוש קטגוריות:
- מערכות ווב - שם אין טעם לעשות Continuous Delivery, אם ניתן לעשות Continuous Deployment.
- מערכות Packaged (למשל SQL Server), ומערכות Embedded - שם לא ניתן לעשות Continuous Deployment, אך עדיין יש ערך רב ב feedback התמידי, ולכן עושים Continuous Delivery.
קצת מבלבל ששני המונחים מתקצרים לצירוף CD, בדיעבד - אולי זה כבר לא משנה.
הוא עבר על use-case כיצד HP העבירו את תהליך פיתוח ה Firmware שלהם למדפסות שלהם - ל CD. רוב העיסוק היה באופן בו נבנה והתפתח ה deployment pipeline שלהם.
המעבר "עלה" בשנתיים של כמעט-השבתה של התהליכים השוטפים, אבל ההישגים - היו משמעותיים. כמות פיתוח הקוד החדש (Innovation) - עלתה פי 8!
בצד ימין, סה"כ התשומות לא מתחברת ל 100%. 23% נמצאים בתחזוקת האוטומציה (בדיקות בעיקר) - מה שעשוי להראות ב waste - עד הרגע בו משווים כמה זמן נותן סה"כ ל innovation - שזהו בעצם יצירת הערך היחידה בכל התהליך.
ה Use-Case הזה מתואר במפורט בספר בשם Large-Scale Agile Development.
 |
| מקור: Jez Humble |
עוד תובנות ספורדיות:
- חשוב מאוד להחזיק את ה App Configuration במערכת ניהול הקוד - על מנת שיהיו גרסאות מדויקות.
- רעיון של Immutable Servers.
- מייבן הוא כלי מחורבן לביצוע CD. ה build life-cycle שלו הוגדר בעולם פרה-CD-י. Gradle הוא לא יותר טוב. הוא ציין לטובה רק את Rake (של רובי).
ה mitigation העיקרי למייבן הוא להפסיק להשתמש ב snapshots - כדי שיהיה אפשר לשחזר במדויק build שכשל - ולאבחן מה הייתה התקלה. - התייחס לפוסט Google Platforms Rant לגבי מדיניות micro-services עבור CD והאופן לנהל גרסאות של APIs.
- בדיון על גרסאות קוד, בחור גרמני עצר את הדיון וקרא: "אבל versioning על REST API נחשב כ bad practice...".
ג'ז לא חיכה: "אתה צריך להחליט: אתה רוצה CD או לא? אם כן - אל תתן לאיזה כלל של REST להפריע לך."
"אתה יודע מה? אני אדבר מחר עם ג'ים וובר (מחבר של ספר מפורסם בנושא) - אני בטוח שהוא יהיה בסדר עם זה... כן לג'ים לא תהיה בעיה...".
הוא אמר את זה בצורה מצחיקה למדי, ונראה לי שהצליח גם לא לפגוע בבחור שהעלה את זה.
אהבתי את הגישה: באמת לפעמים עקרונות לא לגמרי מסתדרים זה עם זה - וחשוב להבחין מה חשוב לנו יותר. - עברנו על מספר פתרונות לתצורות CD, ובעיקר:
- Canary Release
- Blue-Green Deployment.
- יש הבדל מהותי בין deployment ל release, וגם בסביבה מאוטמטת - הם לא חייבים להתרחש ביחד.
- Dark Launching
- אי אפשר להוכיח Releasability, רק להפריך אותה (בעזרת בדיקות ואוטומציה).
- כאשר build נשבר (ברמת ה CI) - יש לחזור מהר מאוד (דקות) למצב תקין ע"י revert של השינויים האחרונים. את הניטור עושים offline. באופן דומה מאוד - עושים זאת ב production.
- הוא לא מתלהב מגיט עבור CD / CI - וממליץ כ mitigation לעבוד על trunk (או master) בלבד.
בגוגל, 10,000 מהנדסים עובדים רק על trunk גלובלי שכולל כמעט את כל הקוד של גוגל (מלבד אנדרואיד ו chromeOS, מסיבות היסטוריות). - מדד שהוא ממליץ לעשות לו אופטימיזציה הוא Time To Restore Service.
- עקרון: deploy the same way to every environment.
- היה לו סיפור על נטפליקס שבדקו קוד על MRI (ה VM הרגיל של רובי) - כי קל לדבג, אבל ב production עבדו עם JRuby (שהוא מהיר בהרבה, ואמור להיות זהה). כצפוי: באג בלתי-צפוי ב JRuby גרם להם להשבתת פעילות מאוד לא נעימה.
- עקרון משנה: only build packages once. מצד אחד שיקול ביצועים (לא לעשות אותה העבודה פעמיים), מצד שני - ייתכן שבנייה מאוחרת יותר (בעיקר בסביבת CD) תיצור image מעט שונה.
- עיקר האתגר ב CD הוא לא הכלים ו/או הטכניקות, אלא בעיקר ליצור DevOps Culture. בחלק זה היה לו סיפור מדליק על נומי (NUMMI) - שיתוף הפעולה בין טויוטה וGM, שיצר הצלחה מדהימה - ש GM לא הצליחו לשחזר. אלו סיפורי שחר ההיסטוריה של Lean שהם תמיד מעניינים...
- הוא המליץ על הספר Toyota Kata
- בלי, ועם קשר, המליץ על הספר The Phoenix Project כתחליף מודרני ומכוון IT לספר "המטרה" (ספר שנכתב ע"י בחור ישראלי, והיה דיי מהפכן בכל העניין של ניהול תהליכים ע"פ אילוצים)
- המלצה נוספת - The Corporate Culture Survival Guide. אין מה לומר, הבחור אוהב ספרים.
- לראשונה שמעתי מישהו קורא ל Router (רכיב רשת) - "רוטר". דיי הגיוני, אני יודע שבארה"ב קוראים ל Route (למשל Route 66) לסירוגין כ ראוט 66, או רוט 66.
חלק גדול מהסדנה (כמעט חצי) - עסק בביצוע בדיקות. החלק הזה היה קצת יותר משעמם עבורי - כי זה נושא שכבר טחנתי רבות לאורך הקריירה.
 |
| במקום פירמידה - הוא הציג את סוגי הבדיקות השונים במטריצה. |
- גם הוא התלונן על חוסר הבהירות במינוח של בדיקות פונקציונליות / קבלה / אינטגרציה (נושא שעלה אצלנו לדיון לאחרונה בעבודה).
- בזמן הכנס, פחות או יותר, מרטין פאוולר פרסם עדכון לפוסט ישן על בדיקות יחידה, שמכיל דיון על Solitary Tests ו Sociable Tests. כמה נוח - אנו מנהלים בדיוק דיון מקביל בעבודה, ואין כמו גורו בינלאומי, בכדי לתמוך ולתת הרגשה שאנו בכיוון הנכון.
- קריאה מומלצת Google Testing Culture
- ציין את PageObject כדפוס מוצלח לבדיקות Acceptance.
- עודד למחוק מהקוד בדיקות שכבר לא תורמות / לא רלוונטיות (בגלל שינויים בדרישות).
- הבחין בין Acceptance Tests ("מקטע בודד של פעילות") ל Journey Tests (המכסים flow גדול של acceptance), ושוחח קצת על הבחירה ביניהן (כמובן שגם וגם - אבל כמה ומתי כל אחד).
- "בדיקות לא-יציבות הן יותר גרועות מבדיקות חסרות-תועלת" (כי אז אנשים מפסיקים לסמוך על בדיקות).
נושא גדול אחרון היה ההתמודדות עם בסיסי נתונים בסביבת CD:
- DB Versioning - רעיון שלכל שורה בבסיס הנתונים יש גרסה (בדומה ל multi-tenancy), וכך ניתן להריץ בדיקות של בסיס הנתונים במקביל / לעשות deploy הדרגתי.
- טכניקה נוספת לבדיקות: לעשות טרנזקציה ו rollback בכל בדיקה.
- שימוש של In-Memory DB (למשל: H2) לבדיקות בלבד - בכדי להשיג מהירות גבוהה. מחיר בעייתי נדרש: שוני מסביבת ה production.
- יכולת Fork DB של Heroku - שיכול לעזור מאוד לבדיקות. אולי ניתן לעשות זאת עם backup/restore גם בצורה מקומית.
- טכניקות שונות ל nZDM (קיצור של near Zero Downtime for Maintenance) בכדי להחליף "גרסה" של בסיס נתונים ב production (או לבצע migration ל schema) - תוך כדי צמצום ההשפעה על הלקוח הסופי. הכוונה היא להשאיר את המערכת חיה, אך למשך זמן קצר (דקות) - לא לאפשר למשתמשים לבצע כתיבות לבסיס הנתונים (או לאגור אותם בצד בנוסח CQRS - ולעדכן אח"כ).
- noSQL - כדרך לעקוף רבות מהבעיות. מה לעשות: noSQL, micro-services ו CD מתאימים זה לזה - ובמקום הזה בסיסי-נתונים רלציוניים משתלבים פחות טוב.
 |
| מקור: Jez Humble |
סיכום
טוב, היה כנס מרשים ומחדש - ולא קל לסכם את הכל בפוסט אחד. בשאיפה, ארכז עוד תובנות מעניינות בפוסט המשך.
בעוד הביקור ב QCON 2008 היה עבורי OVERWHELMING, הפעם הכנס היה עדיין מעניין מאוד - אבל לא הפך לי את כל דפוסי החשיבה. אני מניח שאני פשוט מעודכן הרבה יותר היום במתרחש בחזית התעשייה - ממה שהייתי אז.
ליאור
[א] בסשן אחר שאל המציג את הקהל: "כמה מכם יכולים לדחוף מ production פיצ'ר לאחר שה VP Marketing אמר שזה רעיון רע?" (כמו בסיפור של אמזון).
באופן מפתיע למדי, כעשרים אחוז מהקהל הרים יד. אולי בגלל שהיו הרבה סטארט-אפיסטים (?!) אולי גם האווירה הליברלית של ברלין.
אין תגובות:
הוסף רשומת תגובה