האתר של Lowe'הוא בין אתרי המסחר האלקטרוני שמניבים את הביצועים הטובים ביותר

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

Abhimanyu Raibahadur

Ashish Choudhury

Dhilip venkatesh Uvarajan

Dinakar Chandolu

Garima Mimani

Safwan Samla

הערה: פוסט זה נכתב על ידי אשיש צ'אודהורי, דינאקאר צ'נדולו, אבימאניו רייבהדור וDhilipvenkatsh Uvarajan מ-Lowe's.

Lowe's היא קמעונאית בשווי של כמעט 90 מיליארד דולר. החברה מפעילה כ-2,200 חנויות ומעסיקה יותר מ-300,000 עובדים. באמצעות פיתוח מערכת אוטומטית לבדיקה ולמעקב שמונעת פריסה של ביצועים מרגרסיה של ביצועים בסביבת ייצור, צוות Site Speed של Lowe הצליח לשפר את ביצועי האתר וקיבל דירוג בין אתרי הקמעונאות המובילים.

בעיה

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

פתרון

הצוות של מהירות האתר השתמש בכלים בקוד פתוח כדי לבנות מערכת אוטומטית לבדיקת ביצועים ולמעקב אחרי סביבות טרום-ייצור. המערכת מודדת את הביצועים של כל בקשת משיכה (PR) ומגבילה את תעריף ה-PR מהמשלוח לייצור אם היא לא עומדת בתקציב הביצועים ובקריטריונים למדדים של הצוות של מהירות האתר. המערכת גם מודדת את התאימות של SEO ו-ADA.

השפעה

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

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

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

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

הטמעה

הלב של האפליקציה לניהול מהירות אתרים (SSG) הוא Lighthouse CI. אפליקציית SSG משתמשת ב-Lighthouse כדי לאמת ולבדוק את ביצועי הדף של כל בקשת משיכה.

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

זרימת תהליך של ניהול מהירות אוטומטי (ASG)

Spinnaker

נקודת התחלה. המפַתח ממזג את הקוד שלו לסביבת קדם-ייצור.

1. פריסה של סביבת קדם-ייצור עם נכסי CDN.
2. בודקים אם הפריסה הצליחה.
3. מריצים קונטיינר של Docker כדי להתחיל לפתח את אפליקציית ASG, או לשלוח התראה (במקרה של כשל בפריסה).

ג'נקינס והמגדלור

1. בנו את אפליקציית ASG באמצעות Jenkins.
2. מריצים קונטיינר Docker בהתאמה אישית שמותקן בו Chrome ו-Lighthouse. מושכים lighthouserc.json מאפליקציית SSG ומריצים את lhci autorun --collect-url=https://example.com.

אפליקציית Jenkins ו-SSG

1. צריך לחלץ את assertion-results.json מ-Hulci ומשווים אותו לתקציבים שהוגדרו מראש ב-budgets.json. שומרים את הפלט כקובץ טקסט ומעלים אותו ל-Nexus לצורך השוואות בעתיד.
2. משווים בין assertion-results.json הנוכחי ל-build האחרון שהורד מ-Nexus ושומרים אותו כקובץ טקסט.
3. צור אימייל HTML עם מידע על הצלחה או כישלון.
4. שולחים את האימייל לרשימות התפוצה הרלוונטיות באמצעות Jenkins.