3 การตรวจสอบหลังการ Deploy ที่ผมทำทุกครั้งหลังการ Build บน Cloudflare Pages

ผมเสียเวลาไปสองสัปดาห์เต็มๆ ในการแก้บั๊กที่ปรากฏขึ้นเฉพาะใน Production เท่านั้น

กฎ _redirects ข้อหนึ่งไปบล็อก sitemap ของผม และปัญหา race condition ระหว่างการอัปโหลดรูปภาพกับการ deploy บน Cloudflare ก็ทำให้เกิดปัญหาอีกอย่างหนึ่ง

ตอนนี้ ผมจึงทำการตรวจสอบเฉพาะเจาะจง 3 อย่างหลังการ deploy ทุกครั้ง นี่ไม่ใช่การทดสอบแบบเต็มรูปแบบ (full tests) แต่มันช่วยแก้ปัญหาที่ผมเจอจริงๆ กับเว็บไซต์ที่เป็น Astro 5 SSG ของผม

การตรวจสอบที่ 1: ความพร้อมใช้งานของ Sitemap

ผมตรวจสอบว่า sitemap-index.xml ส่งสถานะ 200 กลับมาในทุกโดเมน

ผมยังตรวจสอบ sitemap-0.xml ด้วย ซึ่งไฟล์นี้จะบรรจุ URL จริงๆ เอาไว้ ผมจะเช็กว่าจำนวน URL ยังคงสูงกว่าตัวเลขที่กำหนดไว้ สำหรับเว็บไซต์หนึ่ง ถ้าจำนวนลดลงต่ำกว่า 1,000 ผมจะรู้ทันทีว่า data pipeline ของผมมีปัญหา

ผมใช้ curl ในการตรวจสอบ โดยไม่ทำตาม redirect (do not follow redirects) วิธีนี้ช่วยให้ผมตรวจพบกฎการ redirect ที่ผิดพลาด ซึ่งอาจจะดูปกติเมื่อเปิดในเบราว์เซอร์ แต่กลับบล็อกพวก crawler

การตรวจสอบที่ 2: การส่งข้อมูลไปยัง IndexNow

หลังจากตรวจสอบ sitemap แล้ว ผมจะรันสคริปต์เพื่อส่ง URL ไปยัง IndexNow เพื่อแจ้งให้ Bing, Yandex, Naver และ Seznam ทราบเกี่ยวกับเนื้อหาใหม่

หาก IndexNow ส่งข้อผิดพลาด 403 กลับมา แสดงว่าไฟล์ตรวจสอบคีย์ (key verification file) ของผม deploy ไม่สำเร็จ การตรวจพบปัญหานี้ทันทีจะช่วยป้องกันความล่าช้าในการทำ indexing ของ search engine

ผมรันขั้นตอนนี้ด้วยตัวเอง (manually) หลังการ deploy เพื่อให้แน่ใจว่าผมจะส่งเฉพาะ URL ที่ใช้งานได้จริงและมีความเสถียรแล้วเท่านั้น

การตรวจสอบที่ 3: แนวโน้มของ Lighthouse

ผมรันการตรวจสอบ Lighthouse ตามตารางเวลาที่กำหนด ไม่ใช่ทำหลังการ deploy ทุกครั้ง

ผมติดตาม 3 ตัวชี้วัด (metrics):

  • Performance (ผมจะดูถ้าคะแนนต่ำกว่า 80)
  • CLS (ผมจะดูถ้าคะแนนสูงกว่า 0.1)
  • คะแนน Accessibility

เนื่องจากเว็บไซต์ของผมใช้ static HTML และ CSS คะแนนเหล่านี้ควรจะคงที่ หากคะแนนลดลง เป็นไปได้ว่าการเปลี่ยนแปลงใน Tailwind config หรือ component บางอย่างทำให้ layout พัง

ผมไม่ได้ใช้คะแนนเหล่านี้เพื่อบล็อกการ deploy แต่ใช้เพื่อติดตามแนวโน้ม (trends)

ทำไมต้องเป็น 3 อย่างนี้?

ผมไม่ได้ใช้ uptime monitors หรือการทดสอบผู้ใช้งานแบบ end-to-end เพราะเว็บไซต์ของผมเป็นการ deploy แบบ static บน CDN และมีการ query ฐานข้อมูลเฉพาะในช่วง build time เท่านั้น

การตรวจสอบทั้ง 3 อย่างนี้ครอบคลุมความเสี่ยงที่แท้จริงเพียงอย่างเดียวที่ผมต้องเจอจากการตั้งค่าแบบนี้

ที่มา: https://dev.to/mor