変更範囲を先に固定する
最初にGitの状態を確認し、今回触るファイルと既存の変更を分けます。静的サイトでは一見小さなリンク変更でも、複数ページやサイトマップに影響するため、差分全体を見ることが重要です。
ローカルで「遷移」まで確認する
HTMLの見た目だけでなく、内部リンクが実在するか、スマートフォンで横にはみ出さないか、JavaScriptのエラーがないかを確認します。サイトマップや構造化データも、この段階で機械的に検査します。
GitHub Actionsの完了を待つ
コミットをpushした後は、対象ワークフローが成功したかを確認します。pushできたことと、サーバーへ公開できたことは別の事実です。
デプロイ完了は中間地点です。利用者がアクセスする本番URLで新しい内容が返るまでを、リリース確認に含めます。
本番URLを直接検証する
主要ページのHTTPステータス、タイトル、CSSや画像、内部リンクを本番環境から確認します。CDNを使う場合はクエリ文字列を付けた確認も行い、古いキャッシュを見ていないか切り分けます。
小さく戻せる単位で出す
一つのリリースに無関係な変更を混ぜないことで、問題が起きたときの原因特定と修正が速くなります。自動化は作業を省く仕組みであると同時に、確認点を明確にする仕組みでもあります。