deployment

デプロイ

概要

コードから本番環境までの流れを自動化する CI/CD パイプラインとデプロイ設定を構成します。このスキルでは、デプロイ先を検出し、パイプライン設定を生成し、デプロイ前後のチェックリストを作成して、監視を設定します。これにより、ロールバックに対応した完全自動化のデプロイパイプラインを構築します。

開始時に次のように伝えてください：「デプロイパイプラインを設定するため、デプロイスキルを使用します。」

フェーズ 1：デプロイ先の検出

このフェーズの後で停止し、次に進む前に検出結果をユーザーに提示して確認を得てください。

デプロイの全体像を特定するため、次の質問をします。

プラットフォームの検出：

• どこにデプロイしますか？（Vercel、AWS、GCP、Azure、DigitalOcean、セルフホスト）
• コンテナベースですか？（Docker、Kubernetes）
• サーバーレスですか？（Lambda、Cloud Functions、Edge Functions）

CI/CD の検出：

• どの CI システムを使いますか？（GitHub Actions、GitLab CI、CircleCI、Jenkins）
• デプロイのトリガーは何ですか？（main へのプッシュ、タグ、手動）
• 複数の環境を使いますか？（開発、ステージング、本番）

インフラストラクチャの検出：

• データベースのマイグレーションは必要ですか？
• 環境変数はどのように管理しますか？（シークレットマネージャー、.env）
• CDN／キャッシュは使いますか？アセットパイプラインはありますか？
• 監視／アラートは使いますか？（Datadog、Sentry、New Relic）

プラットフォーム選択の判断表

プロジェクトの種類	推奨プラットフォーム	CI/CD	理由
静的サイト／SPA	Vercel、Netlify、Cloudflare Pages	組み込み	設定不要、エッジ CDN
Node.js API	AWS ECS、Cloud Run、Railway	GitHub Actions	コンテナ対応、自動スケーリング
モノレポ（フロントエンド＋バックエンド）	Vercel + AWS / Railway	GitHub Actions	関心事を分離し、個別にスケーリング
エンタープライズ／コンプライアンス要件が厳しい場合	AWS EKS、GKE	GitLab CI、Jenkins	完全な制御、監査証跡
趣味／個人プロジェクト	Railway、Fly.io、Render	組み込み、または GitHub Actions	シンプルで低コスト
ML／データパイプライン	AWS SageMaker、GCP Vertex	GitHub Actions + Airflow	GPU 対応、パイプラインのオーケストレーション

フェーズ 2：パイプラインの設計

このフェーズの後で停止し、設定を生成する前にパイプラインの設計をユーザーに提示して承認を得てください。

標準的なパイプラインのステージ

┌─────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
│  Build   │──▶│   Test   │──▶│  Lint/   │──▶│  Deploy  │──▶│  Verify  │
│          │   │          │   │  Check   │   │          │   │          │
└─────────┘   └──────────┘   └──────────┘   └──────────┘   └──────────┘

**ビルド：**依存関係のインストール、コンパイル、バンドル **テスト：**ユニットテスト、統合テスト、カバレッジの確認 **Lint／チェック：**Lint、型チェック、セキュリティ監査 **デプロイ：**対象環境へプッシュ **検証：**ヘルスチェック、スモークテスト、監視

ブランチ戦略の判断表

ブランチ	アクション	環境	ゲート
feature/*	ビルド + テスト + Lint	なし	PR チェックに合格
main	ビルド + テスト + Lint + デプロイ	ステージング	すべてのチェックに合格
release/* またはタグ	ビルド + テスト + Lint + デプロイ	本番	手動承認
hotfix/*	ビルド + テスト + デプロイ	本番（迅速対応）	シニアの承認

デプロイ戦略の判断表

戦略	使用する状況	リスクレベル	ロールバック速度
直接デプロイ	個人／趣味のプロジェクト、ステージング	高	遅い（再デプロイ）
ブルーグリーン	ヘルスチェックを備えたアプリ、ダウンタイムを最小限にしたい場合	低	即時（切り替え）
カナリア	トラフィックの多い本番環境、段階的なロールアウト	非常に低	高速（再ルーティング）
ローリング	Kubernetes クラスター、ステートレスサービス	低	中程度
フィーチャーフラグ	デプロイとリリースを切り離す場合	非常に低	即時（切り替え）

フェーズ 3：設定の生成

GitHub Actions の例

name: CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run type-check
      - run: npm test -- --coverage
      - run: npm run build

  deploy-staging:
    needs: build-and-test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v4
      # [platform-specific deploy steps]

  deploy-production:
    needs: build-and-test
    if: startsWith(github.ref, 'refs/tags/v')
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      # [platform-specific deploy steps]

GitLab CI の例

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths: [dist/]

test:
  stage: test
  script:
    - npm run lint
    - npm run type-check
    - npm test -- --coverage

deploy-staging:
  stage: deploy
  environment: staging
  script:
    - # platform-specific deploy
  only:
    - main

deploy-production:
  stage: deploy
  environment: production
  script:
    - # platform-specific deploy
  when: manual
  only:
    - tags

フェーズ 4：デプロイチェックリストの作成

停止して、チェックリストをユーザーに提示してください。使用するスタックに合わせて調整します。

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

## Pre-Deploy Checklist

- [ ] All tests passing on CI
- [ ] Code reviewed and approved
- [ ] No critical/high security vulnerabilities
- [ ] Environment variables configured for target environment
- [ ] Database migrations tested (if applicable)
- [ ] Feature flags configured (if applicable)
- [ ] Rollback plan documented
- [ ] Monitoring/alerts configured
- [ ] Changelog updated
- [ ] Version bumped

デプロイ後の検証

## Post-Deploy Verification

- [ ] Health check endpoint returns 200
- [ ] Smoke tests passing
- [ ] Error rate within normal range
- [ ] Response times within SLA
- [ ] Database migrations applied successfully
- [ ] Feature flags active/inactive as expected
- [ ] Monitoring dashboard showing expected metrics
- [ ] No new errors in error tracking (Sentry, etc.)

フェーズ 5：レビューと最終調整

パイプラインの設定全体をユーザーに提示します。

1. CI/CD 設定ファイルの構文が有効であることを確認します
2. すべての環境変数が文書化されていることを確認します
3. ロールバック計画があることを確認します
4. デプロイ前後のチェックリストが完成していることを確認します
5. パイプラインをローカルでテストできることを確認します（act など）

設定を .github/workflows/ または同等の場所に保存します。

アンチパターン／よくある間違い

アンチパターン	問題となる理由	代わりに行うこと
本番環境への手動デプロイ	エラーが発生しやすく、監査証跡が残りません	CI/CD パイプラインで自動化します
ロールバック計画がない	デプロイで本番環境に問題が発生すると、復旧できなくなります	デプロイの前に必ずロールバック計画を定めます
ステージングを省略する	本番環境でバグが見つかります	必ず最初にステージング環境へデプロイします
コード／設定ファイルにシークレットを記載する	セキュリティ侵害のリスクがあります	シークレットマネージャーまたは環境変数を使用します
本番環境のイメージにlatestタグを使用する	再現可能なデプロイになりません	特定のバージョンタグを固定します
同時実行制御がない	デプロイが競合します	CI に同時実行グループを追加します
ヘルスチェックなしでデプロイする	デプロイの健全性を把握できません	ヘルスエンドポイントとデプロイ後のチェックを追加します
ノイズの多い監視によるアラート疲れ	実際の問題を見落とします	症状に対してアラートを設定し、しきい値を調整します

主要な原則

• すべてを自動化する — 重要な処理経路に手動の手順を残しません
• 迅速なフィードバック — 早期に失敗させ、すぐに失敗させます
• 環境の同等性 — ステージング環境を本番環境と一致させます
• ロールバックに備える — すべてのデプロイにロールバック計画を用意します
• 可観測性を確保する — デプロイ前、実行中、実行後に監視します
• セキュリティを確保する — コードにシークレットを含めず、シークレット管理を使用します
• 冪等性を確保する — 同じバージョンを2回デプロイしても、同じ結果になるようにします

統合ポイント

スキル	統合内容
senior-devops	デプロイ設定で使用する Docker、K8s、IaC のパターンを提供します
git-commit-helper	Conventional Commits によって変更履歴とバージョンの更新を管理します
finishing-a-development-branch	ブランチの完了をきっかけにデプロイパイプラインを開始します
verification-before-completion	デプロイ後の検証ゲートです
security-review	パイプラインのセキュリティスキャン段階です
planning	デプロイ計画は実装計画の一部です

スキルの種類

FLEXIBLE — プロジェクトのクラウドプロバイダー、チームの規模、運用成熟度に応じて、パイプラインの設計、プラットフォームの選定、ツールを調整してください。原則（自動化、ロールバック、可観測性）は変わりませんが、具体的なツールは入れ替え可能です。