operations-deployment-checklist

operations-deployment-checklist

リリースや設定変更をクラスターに反映する前に、デプロイのチェックリストを徹底的に実行します。すべての環境変数、シークレット、設定値、インフラストラクチャの前提条件が網羅されていることを確認します。

使用するタイミング

以下の場合にこのスキルを使用します。

• サービスの新しいバージョンを任意の環境（ステージング、本番環境）にデプロイする
• Helm の値、Kubernetes マニフェスト、またはデプロイ設定を更新する
• アプリケーションコードに新しい環境変数、シークレット、または ConfigMap エントリを追加する
• インフラストラクチャリソース（レプリカ数、リソース制限、イングレスルール）を変更する
• デプロイをロールバックする

手順

ステップ 1：設定変更を検出する

1. 差分をスキャンします。 現在の変更をデプロイ済みの状態と比較します。新規または変更された次の項目を特定します。

   • 環境変数（コード、.env ファイル、Helm の値、ConfigMap、コンテナー仕様内）
   • シークレット参照
   • ConfigMap エントリ
   • フィーチャーフラグ
   • サービスエンドポイントまたは URL
   • リソース制限（CPU、メモリ）
   • ボリュームマウントまたは永続ストレージ

2. アプリケーションコードと照合します。 アプリケーションコードに新しい process.env.X、$_ENV['X']、os.environ['X']、または同等のものが追加されている場合、デプロイマニフェストに対応するエントリがあることを確認します。

3. 検出結果を報告します。 検出した設定の追加または変更をすべて列挙します。それぞれについて、次の項目を示します。

   • 変数／シークレット／設定の名前
   • 使用箇所（ファイルと行番号）
   • 定義すべき場所（Helm の値、ConfigMap、Secret など）
   • コードにデフォルト値／フォールバックがあるかどうか

ステップ 2：ユーザーに値の確認を求める

新規または変更された設定値ごとに、ユーザーに明示的に確認します。

1. 「<VARIABLE_NAME> は対象環境に設定されていますか？」

   • シークレットの場合：「クラスターのシークレットストアにシークレットが作成／更新されていますか？」
   • デフォルト値がない場合：「この変数にはフォールバックがありません。設定されていないとアプリケーションは失敗します。設定済みであることを確認してください。」

2. 「この環境に適した値ですか？」（例：ステージング URL と本番環境 URL）

3. 「この値は環境によって異なりますか？」 異なる場合は、各環境に正しい値が設定されていることを確認します。

ユーザーがすべての設定値が用意されていることを確認するまで、先に進まないでください。

ステップ 3：Helm／Kubernetes の準備状況を確認する

1. Helm の値がそろっているか。 values.yaml（または環境固有のオーバーライド）にある必須の値がすべて入力されていることを確認します。空欄、コメントアウト、または TODO、CHANGEME、<replace> などのプレースホルダー値が設定されている項目を指摘します。

2. イメージタグ。 コンテナーイメージのタグが、意図したリリースバージョンと一致することを確認します。本番環境で latest が指定されている場合は指摘します。

3. リソース制限。 CPU とメモリのリクエスト／制限が設定されていることを確認します。リソース制限のないコンテナーを指摘します。

4. レプリカ数。 対象環境に適したレプリカ数であることを確認します。正当な理由がない本番環境の単一レプリカデプロイを指摘します。

5. ヘルスチェック。 ライブネスプローブとレディネスプローブが定義されていることを確認します。プローブがないコンテナーを指摘します。

6. イングレス／ネットワーク。 ルートが変更された場合、次の点を確認します。

   • DNS レコードが存在する、または作成予定である
   • TLS 証明書がプロビジョニングされている
   • ネットワークポリシーで必要なトラフィックが許可されている

7. 永続ストレージ。 ボリュームを追加またはサイズ変更した場合、ストレージクラスが存在し、容量が十分であることを確認します。

ステップ 4：依存関係と実行順序を確認する

1. データベースのマイグレーション。 デプロイでスキーマの変更が必要な場合：

   • 「マイグレーションは実行済みですか（または起動時に自動実行されますか）？」
   • 「マイグレーションは現在稼働中のバージョンとの後方互換性がありますか？」（ダウンタイムなしのデプロイの場合）

2. 依存するサービス。 デプロイで別のサービスを先に更新する必要がある場合：

   • 「必要な変更を含む <dependency> はすでにデプロイされていますか？」
   • 「サービス間の API コントラクトに互換性はありますか？」

3. 機能フラグ。 新機能がフラグで制御されている場合：

   • 「対象環境でフラグは設定されていますか？」
   • 「デプロイ時に有効化しますか、それとも無効化しますか？」

ステップ 5：ロールバックの準備状況を確認する

1. 「このデプロイは安全にロールバックできますか？」 次の点を確認します：

   • 元に戻せないマイグレーション
   • 上流／下流サービスとの後方互換性のないコントラクト変更
   • 一方向のデータ変換

2. 「前のイメージ／バージョンはまだ利用できますか？」 レジストリに以前のバージョンのタグが存在することを確認します。

3. 「ロールバック用のランブックまたは既知の手順はありますか？」 なければ、リスクとして提示します。

ステップ 6：最終チェックリストの確認

概要チェックリストを提示し、ユーザーから明示的な承認を得ます：

## Deployment Checklist — <service> → <environment>

### Configuration
- [ ] All new environment variables are set in the target environment
- [ ] All secrets are created/updated in the secret store
- [ ] Values are correct for this specific environment (not copied from another)

### Kubernetes/Helm
- [ ] Image tag points to the correct release version
- [ ] Resource requests and limits are defined
- [ ] Health checks (liveness + readiness) are configured
- [ ] Replica count is appropriate for the environment
- [ ] Ingress/DNS/TLS are configured (if applicable)

### Dependencies
- [ ] Database migrations are applied or will auto-run
- [ ] Dependent services are deployed and compatible
- [ ] Feature flags are configured

### Rollback
- [ ] Deployment can be rolled back without data loss
- [ ] Previous version is available in the registry

### Sign-off
- [ ] Engineer confirms: ready to deploy

該当するすべての項目にチェックが付くか、理由を添えて該当なしと明示されるまで、デプロイを進めないでください。

ステップ 7：デプロイ後の確認

デプロイを適用した後：

1. Pod の状態を監視します。 すべての Pod が Running 状態になり、レディネスチェックに合格することを確認します。
2. ログを確認します。 最初の 2～5 分間にエラーレベルのログがないか確認します。
3. スモークテストを実施します。 ヘルスエンドポイントまたは基本機能の確認手段がある場合は、実行します。
4. 異常があればユーザーに警告します。 Pod が技術的には稼働している場合でも同様です。

原則

• 設定が正しいと思い込まないでください。 常に明示的に確認します。
• デプロイを止める側に判断を傾けてください。 デプロイの遅延は、デプロイが壊れるより望ましいものです。
• 見えないものを見えるようにします。 暗黙の依存関係や前提をすべて明らかにします。
• 一度に 1 つの環境だけを対象にします。 明示的な確認なしに、複数の環境へ同時にデプロイしないでください。