デプロイフローとロールバック手順

デプロイフローとロールバック手順

適切なデプロイフローとロールバック手順を定義することで、安全にデプロイし、問題が発生した際に迅速にロールバックできます。

なぜデプロイフローとロールバック手順が重要なのか

問題のあるデプロイ

問題のある状況:

- デプロイ手順が明確でない
- ロールバック手順が不明確
- デプロイ前の確認が不十分
- デプロイ後の確認が不十分
- ロールバックに時間がかかる

影響:

• デプロイ時のエラーが増える
• 本番環境への影響が拡大する
• ロールバックに時間がかかる
• ユーザーへの影響が拡大する

デプロイフロー

1. デプロイ前の確認

チェックリスト:

• すべてのテストが成功している
• コードレビューが完了している
• マージが完了している
• デプロイ計画が共有されている
• ロールバック手順が確認されている
• デプロイ後の確認項目が明確になっている

確認項目:

# デプロイ前チェックリスト

## コード品質
- [ ] すべてのユニットテストが成功
- [ ] すべての統合テストが成功
- [ ] すべてのE2Eテストが成功
- [ ] コードレビューが完了（最低2名の承認）
- [ ] リントエラーがない
- [ ] セキュリティスキャンが完了

## デプロイ準備
- [ ] デプロイ計画が共有されている
- [ ] デプロイ時間が適切（平日の10:00-17:00）
- [ ] ロールバック手順が確認されている
- [ ] デプロイ後の確認項目が明確になっている
- [ ] 関係者に通知されている

## 環境確認
- [ ] ステージング環境で動作確認済み
- [ ] データベースマイグレーションが確認済み
- [ ] 環境変数が適切に設定されている
- [ ] 依存関係が更新されている

2. デプロイの実行

デプロイ手順:

# 1. 最新のコードを取得
git checkout main
git pull origin main

# 2. ビルド
npm run build

# 3. テストの実行
npm test

# 4. ステージング環境へのデプロイ
npm run deploy:staging

# 5. ステージング環境での動作確認
# - 主要な機能が正常に動作するか確認
# - エラーログに異常がないか確認
# - パフォーマンスに問題がないか確認

# 6. 本番環境へのデプロイ
npm run deploy:production

# 7. 本番環境での動作確認
# - 主要な機能が正常に動作するか確認
# - エラーログに異常がないか確認
# - パフォーマンスに問題がないか確認

デプロイツール:

• GitHub Actions: CI/CDパイプライン
• GitLab CI/CD: CI/CDパイプライン
• Jenkins: CI/CDパイプライン
• AWS CodePipeline: AWSのCI/CDサービス

3. デプロイ後の確認

確認項目:

• アプリケーションの起動: アプリケーションが正常に起動しているか
• 主要な機能: 主要な機能が正常に動作しているか
• エラーログ: エラーログに異常がないか
• パフォーマンス: パフォーマンスに問題がないか
• メトリクス: CPU、メモリ、リクエスト数などが正常か

確認手順:

# デプロイ後確認チェックリスト

## アプリケーションの起動
- [ ] アプリケーションが正常に起動している
- [ ] ヘルスチェックエンドポイントが200を返す
- [ ] ログにエラーがない

## 主要な機能
- [ ] ログイン機能が正常に動作する
- [ ] 主要なAPIが正常に動作する
- [ ] データベースへの接続が正常

## エラーログ
- [ ] エラーログに異常がない
- [ ] 例外が発生していない
- [ ] 警告が発生していない

## パフォーマンス
- [ ] APIレスポンスタイムが正常
- [ ] データベースクエリが正常
- [ ] CPU、メモリ使用率が正常

## メトリクス
- [ ] リクエスト数が正常
- [ ] エラー率が正常
- [ ] レイテンシが正常

ロールバック手順

1. ロールバックの判断基準

ロールバックが必要な場合:

• P0インシデント: サービスが完全に停止している
• P1インシデント: サービスの主要機能が使用できない
• データの不整合: データの不整合が発生している
• セキュリティ問題: セキュリティ問題が発生している

ロールバックが不要な場合:

• 軽微な問題: 影響範囲が限定的で、すぐに修正できる
• UIの問題: UIの問題で、機能に影響がない
• パフォーマンスの軽微な劣化: パフォーマンスの軽微な劣化

2. ロールバックの実行

ロールバック手順:

# 1. ロールバックの決定
# - インシデントの影響範囲を確認
# - ロールバックの必要性を判断
# - 関係者に通知

# 2. 前のバージョンの確認
git log --oneline -10

# 3. 前のバージョンへのロールバック
git checkout <previous-commit-hash>
git push origin main --force

# 4. デプロイの実行
npm run deploy:production

# 5. ロールバック後の確認
# - アプリケーションが正常に起動しているか確認
# - 主要な機能が正常に動作しているか確認
# - エラーログに異常がないか確認

自動ロールバック:

• ヘルスチェック: ヘルスチェックが失敗した場合に自動ロールバック
• エラー率: エラー率が閾値を超えた場合に自動ロールバック
• レイテンシ: レイテンシが閾値を超えた場合に自動ロールバック

3. ロールバック後の対応

対応内容:

• 原因の特定: ロールバックの原因を特定
• 修正の実施: 問題を修正
• 再デプロイ: 修正後に再デプロイ
• 振り返り: ロールバックの原因を振り返り

デプロイ戦略

1. ブルー・グリーンデプロイ

概要:

• 2つの環境（ブルー、グリーン）を用意
• 1つの環境で本番トラフィックを処理
• もう1つの環境に新バージョンをデプロイ
• 動作確認後、トラフィックを切り替え

メリット:

• ロールバックが容易
• ダウンタイムがない
• 動作確認が可能

デメリット:

• リソースが2倍必要
• 設定が複雑

2. カナリアデプロイ

概要:

• 新バージョンを一部のサーバーにデプロイ
• トラフィックの一部を新バージョンにルーティング
• 動作確認後、すべてのトラフィックを新バージョンにルーティング

メリット:

• リスクが低い
• 段階的にロールアウト可能
• 問題が発生した場合の影響が限定的

デメリット:

• 設定が複雑
• トラフィックの分散が必要

3. ローリングデプロイ

概要:

• サーバーを1台ずつ順番にデプロイ
• 各サーバーで動作確認後、次のサーバーにデプロイ

メリット:

• ダウンタイムがない
• リソース効率が良い

デメリット:

• デプロイに時間がかかる
• 一時的に新旧バージョンが混在

まとめ

デプロイフローとロールバック手順：

• デプロイ前の確認: チェックリスト、確認項目
• デプロイの実行: デプロイ手順、デプロイツール
• デプロイ後の確認: 確認項目、確認手順
• ロールバック手順: 判断基準、実行手順、対応
• デプロイ戦略: ブルー・グリーン、カナリア、ローリング

適切なデプロイフローとロールバック手順により、安全にデプロイし、問題が発生した際に迅速に対応できます。