הניסיון שלי באוטומציה במערכות גדולות

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

איך בונים אוטומציה למערכות גדולות כאלה?

השאלה הראשונה הינה באיזו אוטומציה מדובר - בדיקות יחידה (Unit tests)? בדיקות קומפוננטה? בדיקות קצה לקצה (E2E)?

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

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

האסטרטגיה

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

אמינות

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

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

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

דוחות

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

דיבגביליות

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

קלות ההרצה

האוטומציה יכולה לרוץ ע"י scheduler של windows, ידנית בקלות, טאסק של ג'נקינס. אפשר להחליט אילו טסטים ירוצו, אפשר להריץ במקביל.

יעילות

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

מהירות

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

רובסטיות של הקוד

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

הדבר החשוב ביותר באסטרטגיה

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

עוד כמה פרטים:

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

סיכום

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