LESSON 30分

ストーリー

田
田中VPoE
アーティファクトができた後、それをどの環境にどう昇格させるか。これが「プロモーション戦略」だ
あなた
dev → staging → production という流れは理解していますが、組織全体で考えると何が違うんですか？
あ
田
田中VPoE
20チームが共有する環境管理だからこそ、問題が複雑になる。ステージング環境の取り合い、環境設定のドリフト、本番とステージングの乖離 — チーム単位では起きない課題が山ほどある
あなた
環境の「取り合い」は他のチームからも聞いたことがあります…
あ
田
田中VPoE
そう。環境管理は技術的な課題であると同時に、組織的な課題でもある。両面から設計する必要がある

環境構成の標準

標準環境モデル

組織全体で統一する環境の構成を定義します。

環境目的ライフサイクルアクセス
Development個人/チームの開発一時的（PR単位）開発者
Integrationサービス間統合テスト常時稼働開発チーム
Staging本番相当のテスト常時稼働開発チーム + QA
Production本番サービス常時稼働制限付き

環境のプロビジョニング

# 環境をIaCで管理する（Terraform Module）
module "environment" {
  source = "org/environment-template/aws"

  environment_name = "staging"
  team            = "alpha"

  # 本番と同じインフラ構成（スケールのみ異なる）
  instance_type   = "t3.medium"  # 本番: m5.xlarge
  min_instances   = 1             # 本番: 3
  max_instances   = 3             # 本番: 10
}

プロモーション戦略

アーティファクトの昇格フロー

同一のアーティファクトを環境間で昇格させるフローを定義します。

                   ┌──────────────┐
              ┌───→│ Development  │
              │    │ (PR環境)     │
              │    └──────┬───────┘
              │           ↓ PR Merge
              │    ┌──────────────┐
   コードPush →    │ Integration  │
              │    └──────┬───────┘
              │           ↓ 自動テストパス
              │    ┌──────────────┐
              │    │ Staging      │
              │    └──────┬───────┘
              │           ↓ 承認ゲート
              │    ┌──────────────┐
              └───→│ Production   │
                   └──────────────┘

各昇格の条件

昇格条件自動/手動
Dev → IntegrationPRマージ自動
Integration → Staging統合テスト全パス + セキュリティスキャンパス自動
Staging → ProductionE2Eテストパス + QA承認 + セキュリティレビュー手動承認

環境パリティ（Environment Parity）

本番との差異を最小化する

ステージングと本番の差異が大きいと、「ステージングでは動いたのに本番で壊れた」という事態が発生します。

要素ステージング本番パリティ
OS/ランタイム同一同一完全一致
ネットワーク構成同一（VPC構成）同一完全一致
データベースエンジン同一（バージョンも）同一完全一致
インスタンスサイズ縮小版フルスケール許容
データ量サンプルデータ実データ許容（匿名化データ推奨）
外部サービスサンドボックス本番許容

環境設定の管理

環境差分は設定（Configuration）で吸収し、コードは同一にします。

# 環境ごとの設定例（Helm values）
# values-staging.yaml
replicas: 2
resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
database:
  host: "staging-db.internal"
featureFlags:
  newCheckout: true

# values-production.yaml
replicas: 5
resources:
  requests:
    cpu: "2000m"
    memory: "2Gi"
database:
  host: "production-db.internal"
featureFlags:
  newCheckout: false  # カナリアで段階的に有効化

エフェメラル環境（Ephemeral Environments）

PR単位で一時的な環境を自動構築し、レビューとテストを効率化します。

メリット説明
独立したテスト他チームの作業に影響されない
コスト最適化使用時のみ課金
高速フィードバックPRの変更を即座に確認可能
レビュー効率化レビュアーが実際に動作を確認できる
# GitHub Actions: PR環境の自動構築
name: Preview Environment
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  deploy-preview:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy Preview
        uses: org/deploy-preview@v1
        with:
          environment: "pr-${{ github.event.number }}"
          ttl: "72h"  # 72時間後に自動削除

まとめ

ポイント内容
環境構成Development、Integration、Staging、Productionの4層
プロモーション同一アーティファクトを環境間で昇格
環境パリティ本番との差異を最小化してリスクを低減
エフェメラル環境PR単位の一時環境で独立性とコスト最適化を両立

チェックリスト

  • 標準環境モデルの4層を理解した
  • プロモーション戦略と各昇格条件を理解した
  • 環境パリティの重要性を理解した
  • エフェメラル環境のメリットを理解した

次のステップへ

次は演習です。ここまで学んだ設計原則、ビルド・テスト・デプロイの標準、アーティファクト管理、環境管理を統合して、標準パイプラインを設計してみましょう。

推定読了時間: 30分