𝟯 การตรวจสอบหลังการ Deploy ที่ผมทำทุกครั้งหลังการ Build บน Cloudflare Pages
ผมใช้เวลาสองสัปดาห์ในการแก้ปัญหา (debug) บนระบบ production
กฎของ sitemap บล็อกไฟล์ XML ของผม และปัญหา race condition ก็ทำให้การอัปโหลดรูปภาพล้มเหลว ผมจึงเลิกใช้วิธีการเดาสุ่ม และเพิ่มการตรวจสอบเฉพาะเจาะจง 3 อย่างเข้าไปใน workflow ของผม
ผมใช้การตรวจสอบเหล่านี้กับเว็บไซต์ Astro 5 SSG สามแห่ง ได้แก่ aiappdex.com, findindiegame.com และ ossfind.com
การตรวจสอบเหล่านี้มุ่งเป้าไปที่รูปแบบความล้มเหลวที่เกิดขึ้นจริงกับผม
- การตรวจสอบ Sitemap (Sitemap Verification)
ผมตรวจสอบว่า sitemap-index.xml ส่งคืน status code 200 ในทุกโดเมนหรือไม่ โดยผมใช้ curl แบบไม่ตาม redirect (without redirect following) วิธีนี้จะช่วยตรวจจับกฎที่เขียน URL ใหม่ (rewrite) อย่างไม่ถูกต้อง
ผมยังตรวจสอบ sub-sitemaps ด้วย โดยยืนยันว่ามีจำนวน URL ขั้นต่ำตามที่กำหนด ตัวอย่างเช่น หาก aiappdex.com มี URL ต่ำกว่า 1,000 รายการ แสดงว่า data pipeline ของผมล้มเหลว
- การส่งข้อมูลผ่าน IndexNow (IndexNow Submission)
หลังจากผ่านการตรวจสอบ sitemap แล้ว ผมจะรันสคริปต์เพื่อส่ง URL ไปยัง IndexNow เพื่อแจ้งให้ Bing, Yandex, Naver และ Seznam ทราบเกี่ยวกับเนื้อหาใหม่
ผมคอยเฝ้าระวังข้อผิดพลาด 403 ซึ่งโดยปกติแล้ว 403 หมายถึงไฟล์ตรวจสอบคีย์ (key verification file) ไม่ได้ถูก deploy หรือกฎการ redirect ทำให้เส้นทาง (path) เสียหาย การตรวจพบสิ่งนี้ตั้งแต่เนิ่นๆ จะช่วยป้องกันความล่าช้าในการทำ indexing
ผมรันขั้นตอนนี้ด้วยตัวเอง (manually) หลังการ deploy เพื่อให้แน่ใจว่าผมส่ง URL ที่ใช้งานได้จริงบน CDN แล้ว
- การตรวจสอบด้วย Lighthouse แบบตั้งเวลา (Scheduled Lighthouse Audits)
ผมรันการตรวจสอบ Lighthouse ผ่าน cron job ทุกวันจันทร์ โดยจะตรวจสอบหน้าแรกหนึ่งหน้า และหน้าเชิงลึก (deep page) หนึ่งหน้าต่อหนึ่งเว็บไซต์
ผมติดตามตัวชี้วัดเหล่านี้:
- Performance (เป้าหมายคือมากกว่า 80)
- CLS (เป้าหมายคือต่ำกว่า 0.1)
- คะแนน Accessibility
ผมใช้ Lighthouse เป็นเครื่องมือติดตามแนวโน้ม (trend monitor) ผมจะไม่ระงับการ deploy หากคะแนนลดลงเพียงเล็กน้อย แต่ผมจะใช้ข้อมูลนี้เพื่อตรวจหาความผิดปกติ (regressions) ใน Tailwind config หรือการจัดวางเลย์เอาต์ของ component
ทำไมต้องเป็นสามอย่างนี้?
ผมไม่ได้ใช้การตรวจสอบ uptime หรือการทดสอบผู้ใช้แบบ end-to-end เนื่องจากเว็บไซต์ของผมเป็นการ deploy แบบ static SSG ซึ่ง runtime ทั้งหมดคือ HTML และ CSS ที่ถูกสร้างไว้ล่วงหน้าแล้ว
พื้นที่ที่อาจเกิดความล้มเหลว (failure surface) นั้นมีขนาดเล็ก การตรวจสอบทั้งสามอย่างนี้จึงครอบคลุมวิธีที่มีโอกาสมากที่สุดที่สภาพแวดล้อม production ของผมจะพัง
ที่มา: https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-3j14