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

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

重要なポイント

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