Cloudflare Pages ബിൽഡിന് ശേഷം ചെയ്യേണ്ട 3 പോസ്റ്റ്-ഡിപ്ലോയ്മെന്റ് പരിശോധനകൾ

പ്രൊഡക്ഷൻ പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ ഞാൻ രണ്ടാഴ്ച ചിലവഴിച്ചു.

ഒരു പിശക് സൈറ്റ്മാപ്പ് റീഡയറക്ട് റൂളിനെ (sitemap redirect rule) സംബന്ധിച്ചതായിരുന്നു. അത് എന്റെ സൈറ്റ്മാപ്പ് ഫയലിനെ തടഞ്ഞു. മറ്റൊരു പിശക് ഇമേജ് അപ്‌ലോഡ് വൈകുന്നത് (image upload lag) മൂലമായിരുന്നു.

ഞാൻ പൂർണ്ണമായ എൻഡ്-ടു-എൻഡ് ടെസ്റ്റ് സ്യൂട്ടുകൾ (end-to-end test suites) ഉപയോഗിക്കാറില്ല. പകരം, മൂന്ന് പ്രത്യേക പരിശോധനകളാണ് ഞാൻ ഉപയോഗിക്കുന്നത്. എന്റെ സൈറ്റുകൾ പരാജയപ്പെടാൻ സാധ്യതയുള്ള കൃത്യമായ കാരണങ്ങളെയാണ് ഈ പരിശോധനകൾ ലക്ഷ്യം വെക്കുന്നത്.

ഞാൻ ഇവ മൂന്ന് Astro 5 SSG സൈറ്റുകളിൽ പരീക്ഷിക്കുന്നു: aiappdex.com, findindiegame.com, പിന്നെ ossfind.com എന്നിവയാണ് അവ.

  1. Sitemap Validation

sitemap-index.xml ഒരു 200 സ്റ്റാറ്റസ് കോഡ് നൽകുന്നുണ്ടെന്ന് ഞാൻ ഉറപ്പുവരുത്തുന്നു. ഞാൻ റീഡയറക്റ്റുകൾ (redirects) പിന്തുടരാറില്ല. ഒരു തെറ്റായ റീഡയറക്ട് റൂൾ ബ്രൗസറുകളിൽ നിന്ന് പിശകുകളെ മറച്ചുവെക്കുകയും എന്നാൽ ക്രോളറുകൾക്ക് (crawlers) അവ കാണിച്ചുകൊടുക്കുകയും ചെയ്തേക്കാം എന്നതുകൊണ്ട് ഇത് പ്രധാനമാണ്.

ഞാൻ sitemap-0.xml-ഉം പരിശോധിക്കുന്നു. അതിൽ കുറഞ്ഞത് നിശ്ചിത എണ്ണം URL-കൾ ഉണ്ടെന്ന് ഞാൻ ഉറപ്പാക്കുന്നു. URL എണ്ണത്തിൽ കുറവുണ്ടെങ്കിൽ, എന്റെ ഡാറ്റാ പൈപ്പ്‌ലൈൻ (data pipeline) പരാജയപ്പെട്ടതാകാം.

  1. IndexNow Submission

സൈറ്റ്മാപ്പ് പരിശോധനയ്ക്ക് ശേഷം, URL-കൾ IndexNow-ലേക്ക് സമർപ്പിക്കുന്നതിനായി ഞാൻ ഒരു സ്ക്രിപ്റ്റ് പ്രവർത്തിപ്പിക്കുന്നു. ഇത് Bing, Yandex, Naver, Seznam എന്നിവയെ പുതിയ ഉള്ളടക്കത്തെക്കുറിച്ച് അറിയിക്കുന്നു.

IndexNow ഒരു 403 എറർ കാണിച്ചാൽ, എന്റെ കീ വെരിഫിക്കേഷൻ ഫയൽ (key verification file) കാണാനില്ലെന്നോ അല്ലെങ്കിൽ ഒരു റീഡയറക്ട് റൂൾ പാത്ത് (path) തടസ്സപ്പെടുത്തുന്നു എന്നോ ആണ് അർത്ഥം. ഇത് ഉടൻ പരിശോധിക്കുന്നത് ഇൻഡെക്സിംഗ് വൈകുന്നത് ഒഴിവാക്കാൻ സഹായിക്കുന്നു.

ഡിപ്ലോയ്മെന്റിന് ശേഷം ഞാൻ ഇത് നേരിട്ട് (manually) ചെയ്യുന്നു. ഡിപ്ലോയ്മെന്റ് പ്രക്രിയയിലുള്ള URL-കൾക്ക് പകരം ലൈവ് ആയ URL-കൾ സമർപ്പിക്കുന്നുണ്ടെന്ന് ഇത് ഉറപ്പാക്കുന്നു.

  1. Lighthouse Trend Monitoring

എല്ലാ തിങ്കളാഴ്ചയും നിശ്ചിത സമയക്രമത്തിൽ ഞാൻ ഒരു Lighthouse ചെക്ക് നടത്താറുണ്ട്. ഓരോ സൈറ്റിലും ഒരു ഹോംപേജും ഒരു ഡീപ്പ് പേജും (deep page) ഞാൻ പരിശോധിക്കുന്നു.

ഞാൻ ഇവ ശ്രദ്ധിക്കുന്നു:

  • 80-ൽ താഴെയുള്ള പെർഫോമൻസ് സ്കോറുകൾ (Performance scores)
  • 0.1-ന് മുകളിലുള്ള CLS
  • Accessibility സംബന്ധമായ പിശകുകൾ (Accessibility regressions)

ഈ സ്കോറുകൾ കുറഞ്ഞാൽ ഞാൻ ഡിപ്ലോയ്മെന്റുകൾ തടയാറില്ല. ട്രെൻഡുകൾ നിരീക്ഷിക്കാനാണ് ഞാൻ ഈ സ്കോറുകൾ ഉപയോഗിക്കുന്നത്. സ്കോറിലെ കുറവ് എന്റെ CSS-ലോ കമ്പോണന്റുകളിലോ (components) വന്ന ലേഔട്ട് മാറ്റത്തെ സൂചിപ്പിച്ചേക്കാം.

എന്തുകൊണ്ട് ഈ മൂന്ന് പരിശോധനകൾ?

എനിക്ക് Cloudflare-ൽ വിശ്വാസമുള്ളതുകൊണ്ട് ഞാൻ അപ്‌ടൈം മോണിറ്ററിംഗ് (uptime monitoring) ഉപയോഗിക്കാറില്ല. എന്റെ സൈറ്റുകൾ സ്റ്റാറ്റിക് ആയതുകൊണ്ട് ഞാൻ API ചെക്കുകൾ ഉപയോഗിക്കാറില്ല. ഒരു സ്റ്റാറ്റിക് CDN ഡിപ്ലോയ്മെന്റിന്, ഈ മൂന്ന് പരിശോധനകൾ എന്റെ യഥാർത്ഥ റിസ്കുകൾ പരിഹരിക്കാൻ മതിയാകും.

ഉറവിടം: https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-f12