٣ فحوصات ما بعد النشر أقوم بها بعد كل عملية بناء في Cloudflare Pages
قضيت أسبوعين في تصحيح أخطاء لم تظهر إلا في بيئة الإنتاج.
تسببت إحدى قواعد خريطة الموقع (sitemap) في حظر فهرس خريطة الموقع الخاص بي. وتعلقت مشكلة أخرى بتأخيرات في رفع الصور.
أنا لا أستخدم مجموعة اختبارات شاملة (end-to-end test suite). بدلاً من ذلك، أستخدم ثلاثة فحوصات محددة لاكتشاف الأخطاء التي أواجهها بالفعل.
أقوم بتشغيل هذه الفحوصات على ثلاثة مواقع تم بناؤها باستخدام Astro 5 SSG على Cloudflare Pages.
- التحقق من خريطة الموقع (Sitemap Verification)
أتحقق مما إذا كان sitemap-index.xml يعيد رمز الحالة 200 في جميع النطاقات.
أتحقق أيضاً من sitemap-0.xml. وأتأكد من أنه يحتوي على الحد الأدنى من الروابط (URLs). بالنسبة لأحد المواقع، هذا الرقم هو ١,٠٠٠. إذا انخفض العدد، فهذا يعني أن مسار البيانات (data pipeline) الخاص بي قد فشل.
لقد تعلمت هذا بالطريقة الصعبة. فقد تسببت قاعدة إعادة توجيه (redirect rule) ذات مرة في تعطل خريطة الموقع الخاصة بي لمدة خمسة أيام. كانت تبدو سليمة في المتصفح ولكنها فشلت بالنسبة لمحركات الزحف (crawlers). وقد ساعدني استخدام curl في اكتشاف هذا الخطأ على الفور.
- الإرسال عبر IndexNow
بعد اجتياز فحوصات خريطة الموقع، أقوم بتشغيل سكربت لإرسال الروابط إلى IndexNow. هذا يرسل روابطي إلى Bing وYandex وNaver وSeznam.
إذا أعاد IndexNow خطأ 403، فهذا يعني أن ملف التحقق من المفتاح مفقود أو أن قاعدة إعادة التوجيه معطلة. اكتشاف هذا مباشرة بعد النشر يمنع تأخير الفهرسة.
أقوم بتشغيل هذا يدوياً بعد كل عملية نشر بدلاً من تشغيله داخل GitHub Actions. يضمن ذلك أنني أرسل روابط تعمل ومستقرة.
- عمليات تدقيق Lighthouse الأسبوعية
أقوم بإجراء فحص Lighthouse كل يوم اثنين في تمام الساعة 04:30 UTC.
أقوم بمراقبة الأداء، وتغيرات التخطيط (layout shifts)، ودرجات إمكانية الوصول (accessibility scores). وبما أن هذه المواقع تستخدم Astro SSG بدون JavaScript من جهة العميل (client-side JS)، فيجب أن تظل الدرجات مستقرة. أي انخفاض يخبرني بأن تغييراً في CSS أو في أحد المكونات (components) قد أدى إلى تعطل التخطيط.
أنا لا أستخدم هذه الدرجات لمنع عمليات النشر، بل أستخدمها لمراقبة الاتجاهات (trends).
لماذا هذه الفحوصات الثلاثة؟
أنا لا أستخدم مراقبة وقت التشغيل (uptime monitoring) أو فحوصات API. مواقعي ثابتة (static). تتولى Cloudflare إدارة البنية التحتية، ويتم الاستعلام من قاعدة البيانات فقط في وقت البناء (build time).
بالنسبة لعمليات النشر عبر CDN الثابتة، تغطي هذه الفحوصات الثلاثة المخاطر الفعلية التي أواجهها.
المصدر: https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-2862