mcpField
D
deployment-procedures

deployment-procedures

github.com/vudovnクラウド・DevOps8.2k197 回インストール9 週間前に更新
リポジトリ

deployment-procedures について

deployment-procedures は、開発者や運用担当者向けの本番リリースガイドです。プラットフォームに応じた準備、監視、検証、ロールバック、緊急対応の原則をまとめています。

主な機能

  1. 01プラットフォーム選択の指針
  2. 02デプロイ前チェックリスト
  3. 03段階的なリリース手順
  4. 04リリース後の稼働確認
  5. 05ロールバックと緊急対応の原則
  6. 06ゼロダウンタイム方式の選択

活用シーン

  1. 01ホスティング環境に応じた手順の選択
  2. 02リリース前のビルド、環境、バックアップ確認
  3. 03デプロイ後の監視と主要フローの検証
  4. 04障害発生時のロールバック判断

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/vudovn/ag-kit --skill deployment-procedures

インストール後、Claude Code で/deployment-proceduresを入力して読み込まれたか確認します。

詳細

デプロイ手順

安全な本番リリースのためのデプロイ原則と意思決定。 スクリプトを暗記するのではなく、考えることを学びましょう。

⚠️ このスキルの使い方

このスキルが教えるのは、コピーするための bash スクリプトではなく、デプロイの原則です。

  • すべてのデプロイは固有です
  • 各ステップの背後にある WHY を理解しましょう
  • 手順をお使いのプラットフォームに合わせて適応させましょう

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/NetlifyGit push、自動デプロイ
Railway/RenderGit push または CLI
VPS + PM2SSH + 手動ステップ
Dockerイメージ push + オーケストレーション
Kuberneteskubectl apply

2. デプロイ前の原則

4 つの検証カテゴリ
カテゴリ確認する内容
コード品質テストが通っている、リンティングがクリーン、レビュー済み
ビルド本番ビルドが動作する、警告がない
環境環境変数が設定済み、シークレットが最新
安全性バックアップ済み、ロールバック計画が準備済み
デプロイ前チェックリスト
  • すべてのテストが通っている
  • コードがレビューされ承認済み
  • 本番ビルドが成功
  • 環境変数を確認済み
  • データベースマイグレーションの準備完了（該当する場合）
  • ロールバック計画を文書化済み
  • チームに通知済み
  • モニタリングの準備完了

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以前のイメージタグ
K8skubectl rollout undo
ロールバックの原則
  1. 完璧さよりもスピード: まずロールバックし、デバッグは後で
  2. エラーを重ねない: ロールバックは 1 回、複数の変更をしない
  3. コミュニケーション: 何が起きたかをチームに伝える
  4. ポストモーテム: 安定した後に原因を理解する

6. ゼロダウンタイムデプロイ

戦略
戦略仕組み
ローリングインスタンスを 1 つずつ置き換える
ブルーグリーン環境間でトラフィックを切り替える
カナリアトラフィックを段階的に移行する
選択の原則
シナリオ戦略
標準的なリリースローリング
高リスクの変更ブルーグリーン（ロールバックが容易）
検証が必要カナリア（実際のトラフィックでテスト）

7. 緊急時の手順

サービスダウン時の優先順位
  1. 評価: 症状は何か？
  2. 迅速な修正: 不明な場合は再起動
  3. ロールバック: 再起動で解決しない場合
  4. 調査: 安定した後に
調査の順序
チェックよくある問題
ログエラー、例外
リソースディスク満杯、メモリ
ネットワークDNS、ファイアウォール
依存関係データベース、API

8. アンチパターン

❌ やらないこと✅ 推奨
金曜日にデプロイする週の早い段階でデプロイする
デプロイを急ぐプロセスに従う
ステージング環境を省略する必ず先にテストする
バックアップなしでデプロイするデプロイ前にバックアップを取る
デプロイ後に放置する15分以上監視する
複数の変更を同時に行う一度に1つの変更を行う

9. 決定チェックリスト

デプロイ前に確認してください。

  • プラットフォームに適した手順になっているか？
  • バックアップ戦略は準備できているか？
  • ロールバック計画は文書化されているか？
  • 監視は設定されているか？
  • チームに通知したか？
  • デプロイ後に監視する時間を確保できているか？

10. ベストプラクティス

  1. 大規模なリリースよりも、小さく頻繁なデプロイを行う
  2. リスクの高い変更にはフィーチャーフラグを使う
  3. 繰り返し行う手順は自動化する
  4. すべてのデプロイを文書化する
  5. 問題が起きた後は、何が問題だったかを振り返る
  6. ロールバックが必要になる前にロールバックをテストしておく

覚えておいてください: すべてのデプロイにはリスクが伴います。スピードではなく、準備によってリスクを最小化してください。

コメント

Markdown 対応