post-deployment checkとは? 稼働中リリースの検証

著者 Daniel Zoghalchali·Latchkey

post-deployment checkは、デプロイしたばかりのリリースが稼働環境で実際に正常であることを検証し、ユーザーより先に不正なデプロイを捕捉します。

デプロイjobが成功で終わっても、それはデプロイコマンドが実行されたことを意味するだけで、アプリケーションが動作していることを意味しません。post-deployment checkはそのギャップを埋めます。リリースが稼働開始した後、稼働中のシステムをプローブして正常であることを確認します。checkが失敗すれば、pipelineはデプロイが不正だったと分かり、自動的にロールバックを起動できます。

何を検証するか

• サービスが稼働し、応答している。
• 主要なエンドポイントが期待どおりの結果を返す (smoke test)。
• health probeとreadiness probeが通過する。
• エラー率とレイテンシが正常に見える。

なぜ「デプロイ成功」では不十分か

デプロイはきれいに適用されても、壊れたアプリを残すことがあります。不正なconfig、失敗したmigration、欠けたsecretなどです。稼働中のシステムを実際に動かして初めて、リリースが本当に動くか分かります。post-deployment checkがその実演です。

簡単な例

デプロイ後、checkは GET /health といくつかの重要なエンドポイントにアクセスし、200応答を確認し、2分間エラー率を監視します。何かおかしければ失敗し、ロールバックを合図します。

ロールバックの駆動

post-deployment checkの真の力は自動化です。checkの失敗は、人が介在せずにロールバックjobを起動でき、不正なリリースが稼働している時間を数分から数秒へと縮めます。

checkと信頼性

信頼できるpost-deployment checkがあれば、すべてのリリースが自動的に検証されるため、チームはより頻繁にデプロイできます。「デプロイして祈る」を「デプロイして確認する」に変えます。これが安全な継続的デリバリーの土台です。

Applying this to your pipeline

• Measure before changing. Most CI optimisation targets the wrong step because the slow one is assumed rather than timed.
• Cache what is expensive to produce and cheap to validate, and key the cache to the exact tool version.
• Fail fast: run the cheapest checks that can reject a change first, so an expensive job never starts on code that cannot pass.
• Prefer determinism over speed when they conflict. A fast pipeline nobody trusts gets re-run, which is slower than a slow one that is believed.

重要なポイント

• post-deployment checkは、リリースが稼働開始した後に正常であることを検証します。
• 「デプロイ成功」は「アプリが動く」と同じではありません。
• checkの失敗は、サービスを復旧するためロールバックを自動的に起動できます。

よくある質問

関連ガイド