Cloudflare Pagesのビルド後、私が必ず実行する3つのポストデプロイ・チェック
本番環境でしか発生しない問題のデバッグに、2週間も費やしたことがあります。
ある時はサイトマップのルールがサイトマップインデックスをブロックし、またある時は画像のアップロード遅延が発生しました。
私はフルセットのE2Eテストスイートは使用していません。その代わりに、実際に直面するエラーを捉えるために、3つの特定のチェックを行っています。
これらは、Cloudflare Pages上でAstro 5 SSGを使用して構築した3つのサイトで実行しています。
- Sitemap Verification
すべてのドメインで sitemap-index.xml がステータスコード200を返すか確認します。
また、sitemap-0.xml も確認します。そこに含まれるURLの数が最小数に達しているかを保証するためです。あるサイトでは、その数は1,000です。もし数が減少していれば、データパイプラインが失敗したことを意味します。
これは手痛い経験から学んだことです。かつてリダイレクトルールによって、5日間もサイトマップが壊れてしまったことがありました。ブラウザでは正常に見えましたが、クローラーにとっては失敗していました。curl を使うことで、このエラーを即座に見つけることができました。
- IndexNow Submission
サイトマップのチェックを通過した後、スクリプトを実行してURLをIndexNowに送信します。これにより、Bing、Yandex、Naver、SeznamにURLが送信されます。
もしIndexNowが403エラーを返した場合、キー検証ファイルが不足しているか、リダイレクトルールが壊れています。デプロイ直後にこれをキャッチすることで、インデックス登録の遅延を防ぐことができます。
これはGitHub Actions内ではなく、デプロイ後に手動で実行しています。これにより、ライブ状態で安定しているURLのみを送信できるようにしています。
- Weekly Lighthouse Audits
毎週月曜日の04:30 UTCにLighthouseのチェックを実行しています。
パフォーマンス、レイアウトシフト、アクセシビリティのスコアを監視しています。これらのサイトはクライアントサイドのJSを使用しないAstro SSGを利用しているため、スコアは安定しているはずです。スコアが低下した場合は、CSSやコンポーネントの変更によってレイアウトが崩れたことを示しています。
これらのスコアをデプロイをブロックするために使うことはありません。傾向を監視するために使用しています。
Why these three?
私はアップタイム監視やAPIチェックは行っていません。私のサイトは静的です。インフラストラクチャはCloudflareが管理しています。データベースへのクエリはビルド時にのみ実行されます。
静的なCDNデプロイメントにおいて、これら3つのチェックは実際の的なリスクをカバーしています。
Source: https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-2862