צוות Site Speed של Lowe's פיתח מערכת אוטומטית למעקב ולבדיקת ביצועים, שמאפשרת לבדוק בקשות משיכה (pull requests) מול תקציבי ביצועים ולמנוע נסיגה בביצועים לפני שהם עוברים לייצור.
Lowe's היא רשת קמעונאות לשדרוג הבית עם מחזור של כ-90 מיליארד דולר, שמפעילה כ-2,200 חנויות ומעסיקה יותר מ-300,000 עובדים. צוות מהירות האתר של Lowe's יצר מערכת אוטומטית לבדיקות ולמעקב, שמונעת נסיגה בביצועים בזמן הפריסה בסביבת הייצור. כך הצוות הצליח לשפר את ביצועי האתר, והוא נמצא עכשיו בדירוג של אתרי הקמעונאות המובילים.
בעיה
המטרה של צוות מהירות האתר היא להפוך את האתר של Lowe's לאחד מאתרי המסחר האלקטרוני המהירים ביותר מבחינת ביצועי טעינת הדפים. לפני שהם יצרו את מערכת הבדיקות והמעקב האוטומטיות, מפתחי האתרים של Lowe לא יכלו למדוד את הביצועים באופן אוטומטי בסביבות שלפני הייצור. בכלים הקיימים בוצעו בדיקות רק בסביבת הייצור. כתוצאה מכך, גרסאות build פחות טובות הגיעו לסביבת הייצור, וגרמו לחוויית משתמש גרועה. גרסאות build פחות טובות כאלה יישארו בסביבת הייצור עד שהצוות של Site Speed יזהה אותן והמחבר יחזור לגרסה הקודמת.
פתרון
צוות Site Speed השתמש בכלים של קוד פתוח כדי ליצור מערכת אוטומטית לבדיקת ביצועים ולמעקב אחריהם בסביבות של טרום-ייצור. המערכת מודדת את הביצועים של כל בקשת משיכה (PR) ומונעת את השליחה של ה-PR לסביבת הייצור אם הוא לא עומד בתקציב הביצועים ובקריטריונים למדדים של צוות Site Speed. המערכת גם מודדת את תאימות האתרים לשיפור האופטימיזציה למנועי חיפוש ול-ADA.
השפעה
במדגם של צוות אחד שהפעיל 102 גרסאות build במשך 16 שבועות, מערכת הבקרה והבדיקות האוטומטיות של הביצועים מנעה את ההעברה של 32 גרסאות build עם ביצועים נמוכים יחסית לסביבת הייצור.
בעבר, לצוות Site Speed היו נדרשים שלושה עד חמישה ימים כדי להודיע למפתחים שהם שלחו חזרה לאחור (regression) בביצועים בסביבת הייצור. עכשיו, המערכת מעדכנת את המפתחים באופן אוטומטי על בעיות בביצועים חמישה דקות אחרי שליחת בקשת משיכה בסביבה שלפני הייצור.
איכות הקוד משתפרת עם הזמן, כפי שאפשר לראות לפי העובדה שמספר הבקשות ל-pull שמסומנות כבעלות נסיגה בביצועים הולך ופוחת. צוות מהירות האתרים גם מקטין בהדרגה את התקציבים לניהול כדי לשפר את איכות האתרים באופן שוטף.
באופן כללי, הבעלות הברורה על קוד בעייתי שינתה את תרבות ההנדסה. במקום לבצע תיקונים יזומים בלית ברירה כי אף פעם לא ברור מי גרם לבעיות, הצוות יכול לבצע אופטימיזציות יזום, כשהבעלות על הקוד הבעייתי ניתנת לזיהוי באופן אובייקטיבי.
הטמעה
הלב של אפליקציית Site Speed Governance (SSG) הוא Lighthouse CI. אפליקציית SSG משתמשת ב-Lighthouse כדי לאמת ולבדוק את ביצועי הדף של כל בקשת משיכה.
אפליקציית ה-SSG גורמת ל-build להיכשל אם לא מתקיימים תקציב הביצועים ויעדי המדדים שהוגדרו על ידי צוות מהירות האתר. הוא אוכף לא רק את ביצועי הטעינה, אלא גם את האופטימיזציה למנועי חיפוש, את האפליקציות לנייד (PWA) ואת הנגישות. הוא יכול לדווח על הסטטוס באופן מיידי לכותבים, לבודקים ולצוותי ה-SRE. אפשר גם להגדיר אותו כך שיתעלם מהבדיקות במקרים שבהם יש צורך בחריגות.
תהליך ניהול מהירות אוטומטי (ASG)
Spinnaker
נקודת ההתחלה. מפתח ממזג את הקוד שלו בסביבה שלפני הייצור.
- פריסת סביבת טרום-ייצור עם נכסי CDN.
- בודקים אם הפריסה בוצעה בהצלחה.
- מריצים קונטיינר של Docker כדי להתחיל לבנות את אפליקציית ASG או לשלוח התראה (במקרה של כשל בפריסה).
Jenkins ו-Lighthouse
- פיתוח אפליקציית ASG באמצעות Jenkins.
- הפעלת קונטיינר Docker בהתאמה אישית שבו מותקנים Chrome ו-Lighthouse.
שולפים את
lighthouserc.jsonמאפליקציית SSG ומריצים אתlhci autorun --collect-url=https://example.com.
אפליקציית Jenkins ו-SSG
- חילוץ של
assertion-results.jsonמ-lhci והשוואה שלו לתקציבים מוגדרים מראש ב-budgets.json. שומרים את הפלט כקובץ טקסט ומעלים אותו ל-Nexus לצורך השוואות עתידיות. - משווים את
assertion-results.jsonהנוכחי ל-build האחרון שהצליח (שהורדתם מ-Nexus) ושומרים אותו כקובץ טקסט. - יוצרים הודעת אימייל בפורמט HTML עם פרטי ההצלחה או הכישלון.
- שולחים את האימייל לרשימות התפוצה הרלוונטיות באמצעות Jenkins.