deployment-procedures について
本番リリースを判断する開発者や運用担当者向けのスキルです。事前確認、デプロイ後の検証、ロールバック、緊急対応を扱い、コピー用スクリプトではなく、環境やリスクに応じた手順選択を案内します。
主な機能
- 01プラットフォーム選定の指針
- 02デプロイ前チェックリスト
- 03段階的なデプロイ手順
- 04デプロイ後の検証と監視
- 05ロールバックと緊急対応
- 06ゼロダウンタイム戦略の選択
活用シーン
- 01本番リリースの準備
- 02環境に適した手順の選択
- 03デプロイ後のサービス状態確認
- 04障害時のロールバック判断
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/deployment-proceduresを入力して読み込まれたか確認します。
詳細
デプロイ手順
本番環境への安全なリリースに関するデプロイの原則と意思決定です。 スクリプトを暗記するのではなく、考え方を学びましょう。
⚠️ このスキルの使い方
このスキルでは、コピーして使う bash スクリプトではなく、デプロイの原則を学びます。
- デプロイのたびに状況は異なります
- 各手順の背後にある理由を理解します
- 利用するプラットフォームに合わせて手順を調整します
1. プラットフォームの選択
判断フローチャート
What are you deploying?
│
├── Static site / JAMstack
│ └── Vercel, Netlify, Cloudflare Pages
│
├── Simple web app
│ ├── Managed → Railway, Render, Fly.io
│ └── Control → VPS + PM2/Docker
│
├── Microservices
│ └── Container orchestration
│
└── Serverless
└── Edge functions, Lambda
プラットフォームごとに手順は異なります
| プラットフォーム | デプロイ方法 |
|---|---|
| Vercel/Netlify | Git push、自動デプロイ |
| Railway/Render | Git push または CLI |
| VPS + PM2 | SSH + 手動の手順 |
| Docker | イメージの push + オーケストレーション |
| Kubernetes | kubectl apply |
2. デプロイ前の原則
4 つの検証カテゴリ
| カテゴリ | 確認事項 |
|---|---|
| コード品質 | テスト合格、lint エラーなし、レビュー済み |
| ビルド | 本番ビルドが動作し、警告がない |
| 環境 | 環境変数が設定済み、シークレットが最新 |
| 安全性 | バックアップ済み、ロールバック計画を準備済み |
デプロイ前チェックリスト
- すべてのテストに合格
- コードのレビューと承認が完了
- 本番ビルドが成功
- 環境変数を確認済み
- データベースのマイグレーションを準備済み（該当する場合）
- ロールバック計画を文書化済み
- チームに通知済み
- モニタリングを準備済み
3. デプロイワークフローの原則
5 段階のプロセス
1. PREPARE
└── Verify code, build, env vars
2. BACKUP
└── Save current state before changing
3. DEPLOY
└── Execute with monitoring open
4. VERIFY
└── Health check, logs, key flows
5. CONFIRM or ROLLBACK
└── All good? Confirm. Issues? Rollback.
各段階の原則
| 段階 | 原則 |
|---|---|
| 準備 | テストしていないコードは決してデプロイしない |
| バックアップ | バックアップなしではロールバックできません |
| デプロイ | デプロイの様子を見守り、放置しない |
| 検証 | 信頼しつつも、必ず確認する |
| 確認 | ロールバックのトリガーをすぐ使える状態にしておく |
4. デプロイ後の検証
検証項目
| 確認項目 | 理由 |
|---|---|
| ヘルスエンドポイント | サービスが稼働している |
| エラーログ | 新たなエラーがない |
| 主要なユーザーフロー | 重要な機能が動作する |
| パフォーマンス | 応答時間が許容範囲内 |
検証期間
- 最初の 5 分間：継続的にモニタリング
- 15 分後：安定していることを確認
- 1 時間後：最終確認
- 翌日：メトリクスを確認
5. ロールバックの原則
ロールバックするタイミング
| 症状 | 対応 |
|---|---|
| サービス停止 | 直ちにロールバック |
| 重大なエラー | ロールバック |
| パフォーマンスが 50% 超低下 | ロールバックを検討 |
| 軽微な問題 | すぐに修正できる場合は、そのまま修正 |
プラットフォーム別のロールバック戦略
| プラットフォーム | ロールバック方法 |
|---|---|
| Vercel/Netlify | 前のコミットを再デプロイ |
| Railway/Render | ダッシュボードからロールバック |
| VPS + PM2 | バックアップを復元して再起動 |
| Docker | 検証済みの以前の不変イメージダイジェスト |
| K8s | kubectl rollout undo |
ロールバックの原則
- 完璧さよりも速さ：まずロールバックし、デバッグは後で行う
- エラーを重ねない：複数回変更するのではなく、ロールバックは 1 回にする
- 情報を共有する：何が起きたかをチームに伝える
- 事後検証：安定してから原因を理解する
6. ダウンタイムゼロのデプロイ
戦略
| 戦略 | 仕組み |
|---|---|
| ローリング | インスタンスを 1 つずつ置き換える |
| ブルーグリーン | 環境間でトラフィックを切り替える |
| カナリア | トラフィックを段階的に移行する |
選択の原則
| シナリオ | 戦略 |
|---|---|
| 標準リリース | ローリング |
| リスクの高い変更 | ブルーグリーン（ロールバックが容易） |
| 検証が必要 | カナリア（実際のトラフィックでテスト） |
7. 緊急時の手順
サービス停止時の優先順位
- 状況を評価：どのような症状が出ていますか？
- 安定化：ログを保全し、影響を特定します。承認済みのインシデント手順で認められている場合に限り、再起動します
- ロールバック：ロールバックのトリガーに該当した場合は、互換性を検証済みのアーティファクトとデータマイグレーション計画を使用します
- 調査：安定してから行います
調査の順序
| 確認項目 | よくある問題 |
|---|---|
| ログ | エラー、例外 |
| リソース | ディスク容量不足、メモリ不足 |
| ネットワーク | DNS、ファイアウォール |
| 依存関係 | データベース、API |
8. アンチパターン
| ❌ してはいけないこと | ✅ すること |
|---|---|
| 金曜日にデプロイする | 週の早い段階でデプロイする |
| デプロイを急ぐ | 手順に従う |
| ステージングを省略する | 必ず事前にテストする |
| バックアップなしでデプロイする | デプロイ前にバックアップする |
| デプロイ後にその場を離れる | 15分以上監視する |
| 一度に複数の変更を行う | 一度に1つの変更を行う |
9. 判断チェックリスト
デプロイする前に：
- プラットフォームに適した手順になっていますか？
- バックアップ戦略は準備できていますか？
- ロールバック計画は文書化されていますか？
- 監視は設定されていますか？
- チームに通知しましたか？
- デプロイ後に監視する時間を確保していますか？
10. ベストプラクティス
- 大規模リリースよりも、小規模で頻繁なデプロイ
- リスクの高い変更にはフィーチャーフラグ
- 繰り返しの手順を自動化
- すべてのデプロイを文書化
- 問題が発生した後に、何がうまくいかなかったかを振り返る
- 必要になる前にロールバックをテスト
覚えておいてください： デプロイには常にリスクが伴います。スピードではなく、準備によってリスクを最小限に抑えましょう。
使用する場面
このスキルは、概要で説明されているワークフローやアクションを実行する場合に適用できます。
制限事項
- このスキルは、タスクが上記で説明されている範囲に明確に当てはまる場合にのみ使用してください。
- 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりとして扱わないでください。
- 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中断して確認を求めてください。
コメント
Markdown 対応