۳ بررسی پس از استقرار که من پس از هر Build در Cloudflare Pages انجام می‌دهم

من دو هفته را صرف عیب‌یابی مشکلات محیط عملیاتی (production) کردم.

یک قانون تغییر مسیر (redirect) در نقشه سایت، فایل‌های sitemap من را مسدود کرد. آپلود یک تصویر به دلیل تأخیر در استقرار (deployment lag) با شکست مواجه شد. این اشتباهات باعث هدر رفتن زمان شدند.

حالا، بعد از هر بار استقرار در Cloudflare Pages، از سه بررسی مشخص استفاده می‌کنم. من از یک مجموعه تست کامل استفاده نمی‌کنم؛ بلکه از این سه بررسی سریع برای شناسایی خطاهایی که واقعاً با آن‌ها مواجه می‌شوم، استفاده می‌کنم.

من این بررسی‌ها را روی سه سایت که با Astro 5 SSG ساخته شده‌اند، اجرا می‌کنم.

۱. تأیید نقشه سایت (Sitemap Verification)

من بررسی می‌کنم که آیا sitemap-index.xml در تمام دامنه‌ها کد وضعیت ۲۰۰ را برمی‌گرداند یا خیر. همچنین sitemap-0.xml را نیز چک می‌کنم.

من تأیید می‌کنم که تعداد URLها به حداقل حد نصاب برسد. برای مثال، aiappdex.com باید حداقل ۱,۰۰۰ URL داشته باشد. اگر تعداد کاهش یابد، یعنی خط لوله داده (data pipeline) من با شکست مواجه شده است.

من از curl بدون دنبال کردن تغییر مسیرها (redirects) استفاده می‌کنم. این کار به من کمک می‌کند تا قوانین تغییر مسیر معیوب را که خطاها را از مرورگرها پنهان می‌کنند، شناسایی کنم.

۲. ارسال به IndexNow

پس از بررسی نقشه سایت، اسکریپتی را برای ارسال URLها به IndexNow جهت موتورهای جستجوی Bing، Yandex، Naver و Seznam اجرا می‌کنم.

این اسکریپت نقشه سایت زنده را می‌خواند و URLها را ارسال می‌کند. اگر IndexNow خطای ۴۰۳ برگرداند، به این معنی است که فایل تأیید کلید من وجود ندارد یا یک قانون تغییر مسیر خراب است.

من این کار را به صورت دستی بعد از استقرار انجام می‌دهم. این کار تضمین می‌کند که URLهایی را ارسال می‌کنم که زنده و پایدار هستند.

۳. پایش عملکرد با Lighthouse

من این بررسی را به جای هر بار استقرار، از طریق یک cron job هفتگی اجرا می‌کنم. این کار روند عملکرد را دنبال می‌کند.

من موارد زیر را زیر نظر می‌گیرم:

  • امتیازهای عملکرد (Performance scores) زیر ۸۰
  • CLS بالای ۰.۱
  • پسرفت‌های دسترسی‌پذیری (Accessibility regressions)

از آنجایی که سایت‌های من از Astro SSG بدون JS سمت کلاینت استفاده می‌کنند، این امتیازها باید ثابت بمانند. اگر کاهش یابند، احتمالاً یک تغییر در CSS چیدمان (layout) را خراب کرده است. من با این امتیازها به عنوان یک مانیتور روند برخورد می‌کنم، نه روشی برای مسدود کردن استقرارها.

خلاصه

من از پایش بالا بودن سرویس (uptime monitoring) یا تست‌های کاربر سرتاسری (end-to-end) استفاده نمی‌کنم. برای یک استقرار استاتیک روی CDN، این سه بررسی ریسک‌های اصلی من را پوشش می‌دهند. آن‌ها بدون اضافه کردن پیچیدگی‌های غیرضروری، از SEO و یکپارچگی چیدمان من محافظت می‌کنند.

منبع: https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-48b4