ഓരോ Cloudflare Pages ബിൽഡിന് ശേഷവും ഞാൻ നടത്തുന്ന 3 പോസ്റ്റ്-ഡിപ്ലോയ്‌മെന്റ് പരിശോധനകൾ

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

ഞാൻ പൂർണ്ണമായ എൻഡ്-ടു-എൻഡ് ടെസ്റ്റ് സ്യൂട്ടുകൾ (end-to-end test suites) ഉപയോഗിക്കാറില്ല. പകരം, മൂന്ന് പ്രത്യേക പരിശോധനകളാണ് ഞാൻ ഉപയോഗിക്കുന്നത്. ഞാൻ നേരിടുന്ന യഥാർത്ഥ പരാജയ രീതികളിൽ (failure modes) ഇവ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു.

ഞാൻ ഇവ മൂന്ന് Astro 5 സൈറ്റുകളിൽ ചെയ്യുന്നു: aiappdex.com, findindiegame.com, ossfind.com.

1. സൈറ്റ്മാപ്പ് വെരിഫിക്കേഷൻ (Sitemap Verification)

എല്ലാ ഡൊമെയ്‌നുകളിലും sitemap-index.xml ഒരു 200 സ്റ്റാറ്റസ് കോഡ് (status code) നൽകുന്നുണ്ടോ എന്ന് ഞാൻ പരിശോധിക്കുന്നു.

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

കഠിനമായ അനുഭവത്തിലൂടെയാണ് ഞാൻ ഇത് പഠിച്ചത്. ഒരിക്കൽ ഒരു റീഡയറക്ട് റൂൾ കാരണം എന്റെ സൈറ്റ്മാപ്പ് അഞ്ച് ദിവസത്തേക്ക് തകരാറിലായി. ബ്രൗസറിൽ നോക്കുമ്പോൾ ഇത് ശരിയാണെന്ന് തോന്നും, എന്നാൽ ക്രോളറുകൾക്ക് (crawlers) ഇത് പരാജയപ്പെടും. curl ഉപയോഗിക്കുന്നത് ഇത് ഉടൻ തന്നെ കണ്ടെത്താൻ സഹായിക്കുന്നു.

2. IndexNow സബ്മിഷൻ (IndexNow Submission)

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

ഒരു സൈറ്റ് 403 എറർ (error) കാണിക്കുന്നുണ്ടെങ്കിൽ, എന്റെ വെരിഫിക്കേഷൻ ഫയൽ കാണാനില്ലെന്നോ അല്ലെങ്കിൽ ഒരു റീഡയറക്ട് റൂൾ തകരാറിലായെന്നോ ആണ് അർത്ഥം. ഇൻഡക്സിംഗ് വൈകുന്നത് ഒഴിവാക്കാൻ ഡിപ്ലോയ്‌മെന്റിന് തൊട്ടുപിന്നാലെ തന്നെ ഞാൻ ഇത് കണ്ടെത്തുന്നു.

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

3. പ്രതിവാര Lighthouse ഓഡിറ്റുകൾ (Weekly Lighthouse Audits)

എല്ലാ തിങ്കളാഴ്ചയും ഞാൻ ഒരു ഷെഡ്യൂൾഡ് ഓഡിറ്റ് നടത്താറുണ്ട്. ഓരോ സൈറ്റിലും ഈ പരിശോധനയ്ക്ക് ഏതാനും മിനിറ്റുകൾ മാത്രമേ എടുക്കൂ.

ഞാൻ മൂന്ന് മെട്രിക്സുകൾ (metrics) നിരീക്ഷിക്കുന്നു:

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

ട്രെൻഡുകൾ നിരീക്ഷിക്കാൻ ഞാൻ ഈ ഫലങ്ങൾ ഉപയോഗിക്കുന്നു. സ്കോർ അല്പം കുറഞ്ഞാൽ മാത്രം ഞാൻ ഡിപ്ലോയ്‌മെന്റുകൾ തടയാറില്ല. ഒരു സ്റ്റാറ്റിക് സൈറ്റിനെ സംബന്ധിച്ചിടത്തോളം, ഈ മൂന്ന് പരിശോധനകൾ എന്റെ പ്രധാന റിസ്കുകൾ പരിഹരിക്കുന്നു.

ഞാൻ അപ്‌ടൈം മോണിറ്ററിംഗോ (uptime monitoring) API ചെക്കുകളോ ഉപയോഗിക്കാറില്ല. എന്റെ സൈറ്റുകൾ സ്റ്റാറ്റിക് ആണ്. എല്ലാം മുൻകൂട്ടി നിർമ്മിച്ചവയാണ് (pre-built). യഥാർത്ഥത്തിൽ മാറ്റം വരുന്ന എന്റെ സ്റ്റാക്കിന്റെ (stack) ഭാഗങ്ങളെയാണ് ഈ പരിശോധനകൾ സംരക്ഷിക്കുന്നത്.

Source: https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-408k