𝟯 בדיקות פוסט-פריסה שאני מריץ אחרי כל Build ב-Cloudflare Pages
ביליתי שבועיים בפתרון באגים בסביבת הפרודקשן.
שגיאה אחת הייתה כלל sitemap שחסם את ה-sitemap index שלי. שגיאה אחרת הייתה עיכוב בהעלאת תמונות. הבעיות הללו הופיעו רק לאחר הפריסה.
אני לא משתמש בערכות בדיקות end-to-end מלאות. במקום זאת, אני משתמש בשלוש בדיקות ספציפיות כדי לתפוס כשלים נפוצים. אני מריץ אותן על שלושה אתרים שנבנו עם Astro 5.
- אימות Sitemap
אני בודק אם sitemap-index.xml מחזיר קוד סטטוס 200 בכל הדומיינים. אני משתמש ב-curl כדי לאמת זאת.
אני בודק גם את ה-sub-sitemap, sitemap-0.xml. אני מוודא שיש בו מספר מינימלי של URLs. אם הספירה יורדת, סביר להניח שצינור הנתונים (data pipeline) שלי נכשל.
למדתי זאת בדרך הקשה. כלל הפניה (redirect rule) שבר פעם אחת את ה-sitemap שלי למשך חמישה ימים. זה עבד בדפדפן אבל נכשל מול סורקי רשת (web crawlers).
- שליחה ל-IndexNow
לאחר בדיקת ה-sitemap, אני מריץ node script. הסקריפט הזה אוסף URLs ושולח אותם ל-endpoint של IndexNow עבור Bing, Yandex, Naver, ו-Seznam.
אני מריץ זאת ידנית לאחר פריסה. זה מבטיח שאני שולח URLs שהם בשידור חי (live).
אם IndexNow מחזיר שגיאת 403, קובץ אימות המפתח שלי חסר או שכלל הפניה שבור. זיהוי מוקדם של זה מונע עיכובים באינדוקס של מנועי החיפוש.
- ניטור מגמות Lighthouse
אני מריץ את הבדיקה הזו על סדר יום קבוע בכל יום שני. אני משתמש ב-lighthouse-ci כדי לבדוק ביצועים, יציבות פריסה (layout stability) ונגישות.
אני מנטר שלושה אתים, כשבכל אחד דף בית אחד ודף פנימי (deep page) אחד.
אני לא משתמש בציונים הללו כדי לחסום פריסות. אני משתמש בהם כדי לעקוב אחר מגמות. אם הציונים יורדים, אני יודע ששינוי אחרון ב-CSS או ברכיבים (components) גרם לשינוי בפריסה (layout shift).
הבדיקות הללו מכסות את נקודות הכשל האמיתיות שלי. מכיוון שהאתרים שלי סטטיים, אני לא זקוק לניטור uptime או לבדיקות API. אני מתמקד רק במה שיכול להישבר בפריסת CDN סטטית.
מקור: https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-4704