با ساختن یک سیستم تست عملکرد و نظارت خودکار، تیم سرعت سایت Lowe درخواست‌ها را در مقابل بودجه‌های عملکردی آزمایش می‌کند و از رگرسیون عملکرد به تولید جلوگیری می‌کند.
Lowe's یک خرده‌فروش تقریباً 90 میلیارد دلاری لوازم خانگی است که حدود 2200 فروشگاه را اداره می‌کند و بیش از 300000 کارمند دارد. با ساخت یک سیستم تست و نظارت خودکار که از گسترش رگرسیون عملکرد به تولید جلوگیری می کند، تیم سرعت سایت Lowe توانست عملکرد وب سایت خود را بهبود بخشد و در بین سایت های خرده فروشی برتر قرار گیرد.
مسئله
هدف تیم سرعت سایت این است که سایت Lowe را به یکی از سریع ترین سایت های تجارت الکترونیک از نظر عملکرد بارگذاری صفحه تبدیل کند. توسعه دهندگان وب سایت Lowe قبل از اینکه سیستم تست و نظارت خودکار خود را بسازند، قادر به اندازه گیری عملکرد خودکار در محیط های پیش تولید نبودند. ابزارهای موجود فقط آزمایشاتی را در محیط تولید انجام دادند. در نتیجه، ساخت‌های ضعیف وارد تولید شدند و تجربه کاربری ضعیفی ایجاد کردند. این ساخت‌های ضعیف تا زمانی که توسط تیم سرعت سایت شناسایی و توسط نویسنده بازگردانده نشود، در حال تولید باقی می‌مانند.
راه حل
تیم سرعت سایت از ابزارهای منبع باز برای ساختن یک سیستم تست عملکرد و نظارت خودکار برای محیط های پیش تولید استفاده کرد. این سیستم عملکرد هر درخواست کششی (PR) را اندازه گیری می کند و در صورتی که با بودجه عملکرد و معیارهای متریک تیم سرعت سایت مطابقت نداشته باشد، روابط عمومی را از حمل و نقل به تولید می بندد. این سیستم همچنین انطباق SEO و ADA را اندازه گیری می کند.
تأثیر
از یک نمونه 1 تیمی در طول 16 هفته که 102 ساخت را به کار بردند، سیستم تست عملکرد و نظارت خودکار مانع از تولید 32 ساخت با عملکرد پایین تر شد.
زمانی که تیم سرعت سایت سه تا پنج روز طول می‌کشید تا به توسعه‌دهندگان اطلاع دهد که رگرسیون‌های عملکرد را به تولید ارسال کرده‌اند، این سیستم اکنون به‌طور خودکار توسعه‌دهندگان را از مشکلات عملکرد پنج دقیقه پس از ارسال درخواست کشش در یک محیط پیش‌تولید مطلع می‌کند.
کیفیت کد در طول زمان در حال بهبود است، همانطور که با این واقعیت اندازه گیری می شود که درخواست های کششی کمتری برای رگرسیون عملکرد علامت گذاری می شود. تیم سرعت سایت همچنین به تدریج بودجه های حاکمیتی را برای بهبود مستمر کیفیت سایت سخت تر می کند.
به طور کلی، داشتن مالکیت واضح بر کد مشکل ساز، فرهنگ مهندسی را تغییر داده است. به جای ابهام از اصلاحات واکنشی، زیرا هرگز مشخص نبود که واقعاً چه کسی مشکلات را معرفی کرده است، تیم می‌تواند بهینه‌سازی‌های پیشگیرانه را با مالکیت کدهای مشکل‌ساز که به طور عینی قابل انتساب است، انجام دهد.
پیاده سازی
قلب برنامه Site Speed Governance (SSG) Lighthouse CI است. برنامه SSG از Lighthouse برای تأیید و بررسی عملکرد صفحه هر درخواست کششی استفاده می کند.
اگر به بودجه عملکرد و اهداف متریک تعریف شده تیم سرعت سایت نرسیده باشد، برنامه SSG باعث می شود که یک ساخت با شکست مواجه شود. این نه تنها عملکرد بارگذاری بلکه SEO، PWA و دسترسی را نیز اعمال می کند. می تواند وضعیت را بلافاصله به نویسندگان، بازبینان و تیم های SRE گزارش دهد. همچنین می‌توان آن را به گونه‌ای پیکربندی کرد که در صورت نیاز به استثنا، بررسی‌ها را دور بزند.
جریان فرآیند مدیریت سرعت خودکار (ASG).
نخ ریسی
نقطه شروع یک توسعه دهنده کد خود را در یک محیط پیش تولید ادغام می کند.
- محیط پیش تولید را با دارایی های CDN مستقر کنید.
- استقرار موفقیت آمیز را بررسی کنید.
- برای شروع ساخت برنامه ASG یا ارسال اعلان (در صورت عدم موفقیت در استقرار) یک کانتینر Docker را اجرا کنید.
جنکینز و فانوس دریایی
- برنامه ASG را با جنکینز بسازید.
- یک کانتینر سفارشی Docker را اجرا کنید که Chrome و Lighthouse را نصب کرده است.
lighthouserc.jsonاز برنامه SSG بکشید وlhci autorun --collect-url=https://example.comرا اجرا کنید.
برنامه جنکینز و SSG
-
assertion-results.jsonاز lhci استخراج کنید و آن را با بودجه های از پیش تعریف شده درbudgets.jsonمقایسه کنید. خروجی را به عنوان یک فایل متنی ذخیره کنید و برای مقایسه های بعدی در Nexus آپلود کنید. -
assertion-results.jsonفعلی را با آخرین ساخت موفق (دانلود شده از Nexus) مقایسه کنید و آن را به عنوان یک فایل متنی ذخیره کنید. - یک ایمیل HTML با اطلاعات موفقیت یا شکست بسازید.
- ایمیل را به لیست های توزیع مربوطه با جنکینز ارسال کنید.