リリースとローンチ

概要

自信を持ってリリースします。目標は単にデプロイすることではなく、安全にデプロイすること、監視を配置すること、ロールバック計画を用意すること、成功の定義を明確に理解することです。すべてのローンチは可逆的で、可観測で、段階的である必要があります。

使用時期

• 機能を本番環境に初めてデプロイする場合
• 重大な変更をユーザーにリリースする場合
• データまたはインフラストラクチャを移行する場合
• ベータ版または早期アクセスプログラムを開始する場合
• リスクを伴うあらゆるデプロイメント(すべてのデプロイメント)

プリローンチチェックリスト

コード品質

• すべてのテスト(ユニット、統合、E2E)が成功している
• ビルドが成功し、警告がない
• リントと型チェックが成功している
• コードがレビュー済み、承認済みである
• ローンチ前に解決すべきTODOコメントがない
• 本番コードにconsole.logデバッグステートメントがない
• エラーハンドリングが想定される障害モードをカバーしている

セキュリティ

• コードまたはバージョン管理にシークレットがない
• npm auditに重大または高い脆弱性が表示されない
• ユーザー向けすべてのエンドポイントに入力検証がある
• 認証と認可のチェックが実施されている
• セキュリティヘッダーが設定されている(CSP、HSTSなど)
• 認証エンドポイントにレート制限がある
• CORSが特定のオリジンに設定されている(ワイルドカードではない)

パフォーマンス

• Core Web Vitalsが「良好」の閾値内である
• 重要なパスにN+1クエリがない
• 画像が最適化されている(圧縮、レスポンシブサイズ、遅延読み込み)
• バンドルサイズが予算内である
• データベースクエリに適切なインデックスがある
• キャッシングが静的アセットと反復クエリのために設定されている

アクセシビリティ

• すべてのインタラクティブ要素でキーボードナビゲーションが機能している
• スクリーンリーダーがページコンテンツと構造を伝達できる
• 色のコントラストがWCAG 2.1 AA(テキストは4.5:1)を満たしている
• モーダルと動的コンテンツのフォーカス管理が正しい
• エラーメッセージがわかりやすく、フォームフィールドに関連付けられている
• axe-coreまたはLighthouseでアクセシビリティ警告がない

インフラストラクチャ

• 環境変数が本番環境で設定されている
• データベースマイグレーションが適用されている(または適用準備ができている)
• DNSとSSLが設定されている
• CDNが静的アセット用に設定されている
• ロギングとエラーレポートが設定されている
• ヘルスチェックエンドポイントが存在し、応答している

ドキュメント

• READMEが新しいセットアップ要件で更新されている
• APIドキュメントが最新である
• アーキテクチャ上の決定についてADRが書かれている
• チェンジログが更新されている
• ユーザー向けドキュメントが更新されている(該当する場合)

フィーチャーフラグ戦略

デプロイメントをリリースから分離するため、フィーチャーフラグの背後でリリースします:

// フィーチャーフラグチェック
const flags = await getFeatureFlags(userId);

if (flags.taskSharing) {
  // 新機能: タスク共有
  return <TaskSharingPanel task={task} />;
}

// デフォルト: 既存動作
return null;

フィーチャーフラグのライフサイクル:

1. DEPLOY with flag OFF     → コードは本番環境にあるが非アクティブ
2. ENABLE for team/beta     → 本番環境でのチーム内テスト
3. GRADUAL ROLLOUT          → 5% → 25% → 50% → 100%のユーザー
4. MONITOR at each stage    → エラー率、パフォーマンス、ユーザーフィードバックを監視
5. CLEAN UP                 → 完全なロールアウト後、フラグと不要なコードパスを削除

ルール:

• すべてのフィーチャーフラグに所有者と有効期限がある
• 完全なロールアウトから2週間以内にフラグをクリーンアップする
• フィーチャーフラグをネストしない(指数関数的な組み合わせが生じる)
• CIで両方のフラグ状態(オン、オフ)をテストする

段階的ロールアウト

ロールアウトシーケンス

1. DEPLOY to staging
   └── ステージング環境で完全なテストスイートを実行
   └── 重要なフローの手動スモークテスト

2. DEPLOY to production (feature flag OFF)
   └── デプロイメント成功を確認(ヘルスチェック)
   └── エラー監視を確認(新しいエラーがない)

3. ENABLE for team (flag ON for internal users)
   └── チームが本番環境で機能を使用
   └── 24時間の監視期間

4. CANARY rollout (flag ON for 5% of users)
   └── エラー率、レイテンシ、ユーザー動作を監視
   └── メトリクスを比較: カナリ vs. ベースライン
   └── 24～48時間の監視期間
   └── すべての閾値がパスした場合のみ進める(下表を参照)

5. GRADUAL increase (25% -> 50% -> 100%)
   └── 各ステップで同じ監視を実施
   └── いつでも前の割合にロールバック可能

6. FULL rollout (flag ON for all users)
   └── 1週間監視
   └── フィーチャーフラグをクリーンアップ

ロールアウト決定閾値

各ステージで進める、保留する、ロールバックするかを判断するために、これらの閾値を使用します:

メトリクス	進める(緑)	保留して調査(黄)	ロールバック(赤)
エラー率	ベースラインの10%以内	ベースラインより10～100%上昇	ベースラインの2倍以上
P95レイテンシ	ベースラインの20%以内	ベースラインより20～50%上昇	ベースラインより50%以上上昇
クライアントJSエラー	新しいエラータイプがない	セッションの<0.1%で新しいエラー	セッションの>0.1%で新しいエラー
ビジネスメトリクス	中立または肯定的	<5%の低下(ノイズの可能性あり)	>5%の低下

ロールバック時期

以下の場合は直ちにロールバック:

• エラー率がベースラインの2倍以上に増加する
• P95レイテンシがベースラインより50%以上増加する
• ユーザー報告の問題が急増する
• データ整合性の問題が検出される
• セキュリティ脆弱性が発見される

監視と可観測性

監視対象

アプリケーションメトリクス:
├── エラー率(合計とエンドポイント別)
├── レスポンス時間(p50、p95、p99)
├── リクエストボリューム
├── アクティブユーザー
└── 主要ビジネスメトリクス(コンバージョン、エンゲージメント)

インフラストラクチャメトリクス:
├── CPUとメモリ使用率
├── データベース接続プール使用状況
├── ディスク容量
├── ネットワークレイテンシ
└── キューの深さ(該当する場合)

クライアントメトリクス:
├── Core Web Vitals(LCP、INP、CLS)
├── JavaScriptエラー
├── クライアント視点のAPIエラー率
└── ページロード時間

エラーレポート

// エラーレポート機能付きエラーバウンダリーをセットアップ
class ErrorBoundary extends React.Component {
  componentDidCatch(error: Error, info: React.ErrorInfo) {
    // エラー追跡サービスにレポート
    reportError(error, {
      componentStack: info.componentStack,
      userId: getCurrentUser()?.id,
      page: window.location.pathname,
    });
  }

  render() {
    if (this.state.hasError) {
      return <ErrorFallback onRetry={() => this.setState({ hasError: false })} />;
    }
    return this.props.children;
  }
}

// サーバー側のエラーレポート
app.use((err: Error, req: Request, res: Response, next: NextFunction) => {
  reportError(err, {
    method: req.method,
    url: req.url,
    userId: req.user?.id,
  });

  // ユーザーに内部情報を公開しない
  res.status(500).json({
    error: { code: 'INTERNAL_ERROR', message: 'Something went wrong' },
  });
});

ローンチ後の確認

ローンチ後の最初の1時間で:

1. ヘルスエンドポイントが200を返すか確認
2. エラー監視ダッシュボードを確認(新しいエラータイプがない)
3. レイテンシダッシュボードを確認(パフォーマンス低下がない)
4. 重要なユーザーフローを手動でテスト
5. ログが流れており、読み取り可能か確認
6. ロールバック機構が機能することを確認(可能であればドライランを実施)

ロールバック戦略

すべてのデプロイメントには、実施前にロールバック計画が必要です:

## [機能/リリース]のロールバック計画

### トリガー条件
- エラー率 > ベースラインの2倍
- P95レイテンシ > [X]ms
- [特定の問題]に関するユーザー報告

### ロールバックステップ
1. フィーチャーフラグを無効化(該当する場合)
   OR
1. 前のバージョンをデプロイ: `git revert <commit> && git push`
2. ロールバックを確認: ヘルスチェック、エラー監視
3. 連絡: チームにロールバックを通知

### データベースに関する考慮事項
- マイグレーション[X]はロールバック可能: `npx prisma migrate rollback`
- 新機能で挿入されたデータ: [保持 / クリーンアップ]

### ロールバック時間
- フィーチャーフラグ: < 1分
- 前のバージョンの再デプロイ: < 5分
- データベースロールバック: < 15分

参照

• セキュリティプリローンチチェックについては、references/security-checklist.mdを参照してください
• パフォーマンスプリローンチチェックリストについては、references/performance-checklist.mdを参照してください
• ローンチ前のアクセシビリティ確認については、references/accessibility-checklist.mdを参照してください

よくある正当化

正当化	現実
「ステージングで動作するなら、本番環境でも動作する」	本番環境には異なるデータ、トラフィックパターン、エッジケースがあります。デプロイ後に監視してください。
「このためにフィーチャーフラグは必要ない」	すべての機能は機能停止スイッチからメリットを得ます。「シンプルな」変更でも問題が生じる可能性があります。
「監視はオーバーヘッド」	監視がないと、ダッシュボードではなく、ユーザー苦情から問題を発見します。
「監視は後で追加します」	ローンチ前に追加してください。見ることができないものはデバッグできません。
「ロールバックは失敗を認めることだ」	ロールバックは責任あるエンジニアリングです。破損した機能をリリースすることが失敗です。

レッドフラグ

• ロールバック計画なしでデプロイする
• 本番環境での監視またはエラーレポートがない
• ビッグバンリリース(すべてを一度に、ステージングなし)
• 有効期限または所有者のないフィーチャーフラグ
• デプロイ後の最初の1時間を監視している人がいない
• 本番環境の設定がメモリで行われ、コードで行われていない
• 「金曜日の午後だ、リリースしよう」

確認

デプロイ前:

• プリローンチチェックリストが完了している(すべてのセクションが緑)
• フィーチャーフラグが設定されている(該当する場合)
• ロールバック計画がドキュメント化されている
• 監視ダッシュボードがセットアップされている
• チームがデプロイメントについて通知されている

デプロイ後:

• ヘルスチェックが200を返す
• エラー率が正常である
• レイテンシが正常である
• 重要なユーザーフローが機能する
• ログが流れている
• ロールバックがテストされた、または準備完了が確認されている