CI/CD・リリース・監視

CI（継続的インテグレーション）は、push やプルリクエストのたびに、テスト・型の確認・ビルドを自動で行うことです。CD（継続的デリバリー／デプロイ）は、それに通ったものを自動で本番（またはその手前）まで届けることです。

パイプラインの例（GitHub Actions）

on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: pnpm/action-setup@v6
      - uses: actions/setup-node@v7
        with: { node-version: 24, cache: pnpm }
      - run: pnpm install --frozen-lockfile
      - run: pnpm lint
      - run: pnpm typecheck
      - run: pnpm test
      - run: pnpm build

アクションの版（@v7 など）と Node.js の版は上がっていくので、使うときに各アクションのリリースと Node.js の LTS の予定を確かめます。流れの例：lint・型の確認・単体テスト（速いものを先に）→ 結合テスト・ビルド → プレビュー環境へデプロイ → E2E → main にマージしたらステージングへ → 本番へ。

• 10分以内を目安に保つ。依存のキャッシュ、変更のあった所だけの実行、並列化で速くする。遅い CI は、まとめて大きな変更を出す原因になる。
• ロックファイルどおりに入れる（--frozen-lockfile）。
• main ブランチは保護し、CI とレビューを通らないとマージできないようにする。
• 本番への権限は OIDC で一時的な認証にし、長く使える鍵を CI に置かない。

SRE の「CI/CDとGitHub Actions」

プルリクエストごとに、その変更だけを反映した環境を自動で作り、URL をプルリクエストに貼る仕組みです（Vercel・Netlify・Cloudflare Pages などは標準で対応）。デザイナーや PM がマージ前に実際の画面で確かめられ、E2E テストの対象にもできます。注意点は、本番のデータや秘密情報をつながないこと、検索エンジンに載らないようにすること、使い終わったら消すこと（費用）です。DB を使うアプリでは、プレビューごとの DB をどう用意するかも決めます。

リリースで障害を起こさないコツは、一度に変える量を小さくし、すぐ戻せるようにすることです。

Feature Flag

Feature Flag は、コードは本番に出しておき、機能を有効にするかを設定で切り替える仕組みです。デプロイ（コードを出す）とリリース（ユーザーに見せる）を分けられます。

if (flags.isEnabled('new-checkout', { userId: user.id })) {
  return renderNewCheckout();
}
return renderOldCheckout();

• 社内の人だけ → 1% → 10% → 全員、と段階的に広げ、エラー率や指標を見て問題があればフラグを切る（デプロイし直さずに戻せる）。
• 未完成の機能も main にマージでき、長いブランチを作らずに済む。
• 使い終わったフラグは消す。残り続けると分岐が増えて誰も分からなくなる。期限と担当者を決めておく。
• 道具は LaunchDarkly・Unleash・OpenFeature 対応のもの、自前の設定表など。

Feature Flag のほかにも、出し方にはいくつかあります。

どの方式でも、何を見て止めるか（エラー率・レイテンシ・主要な操作の成功率）を先に決めておき、自動で止まる仕組みにできると安全です。

SRE の「デプロイ戦略」

アプリは前の版に戻せても、データは戻りません。新しい版が新しい形でデータを書いたあとに戻すと、古い版がそのデータを読めずに壊れることがあります。

• DB の変更は「新旧どちらのアプリでも動く」形で、アプリのリリースと分けて行う（列の削除は、使わなくなってから別のリリースで）。
• 新しい列・新しい値を書き始める変更は、まず「読めるようにする」版を出してから、「書く」版を出す。
• キャッシュやキューに入るデータの形も同じ。古いワーカーが新しい形のジョブを受け取っても壊れないようにする。
• API の応答を変えるときは、古いアプリ（スマホ）がまだ使っている前提で。
• 戻す手順（前の版のデプロイ・フラグを切る）を事前に決め、実際に試しておく。

本番で起きている問題に、ユーザーより先に気づくための仕組みです。ログ・メトリクス（数値）・トレース（1つのリクエストがどこを通ったか）を組み合わせて見ます。

フロントのエラー監視

ブラウザで起きたエラーは、何もしなければサーバーのログに残りません。エラートラッキング（Sentry など）を入れると、ユーザーのブラウザで起きた例外を集めて、件数・影響したユーザー数・ブラウザの種類・直前の操作とともに見られます。

• ビルドで作ったソースマップをエラートラッキングにアップロードし、圧縮されたコードのエラーを元のファイルと行に戻す。ソースマップ自体は一般には公開しない設定にすることが多い。
• リリースの版をタグ付けし、「どのデプロイから増えたか」が分かるようにする。
• 拡張機能や古いブラウザ由来のノイズを除き、件数の急増で通知する。
• 個人情報（入力値・トークン）を送らないよう、送る前に取り除く設定をする。
• エラーだけでなく、Core Web Vitals などの性能も RUM で集める。
• バックエンドとはリクエスト ID やトレース ID で結びつけ、画面のエラーから API のログにたどれるようにする。

SRE の「SLI・SLO・SLA」

SLO は「この API の 99.9% のリクエストが 500ms 以内に成功する」のような、ユーザーから見た品質の目標です。SLO を下回りそうなときは、機能の開発より信頼性の改善を優先する、という判断の基準にもなります（エラーバジェット）。

• Web エンジニアは、何がユーザーにとって大事な操作か（ログイン・検索・購入）を知っているので、SLI（測る指標）を SRE と一緒に決める。
• アプリのコードに、計測（OpenTelemetry など）・意味のあるログ・ヘルスチェックを入れるのは開発側の仕事。
• アラートは「ユーザーに影響があるとき」に鳴るようにし、鳴ったときに見るダッシュボードと手順を用意する。
• 障害のあとはふり返り（ポストモーテム）に参加し、コードの側の再発防止を担当する。

障害のとき、Web エンジニアは「直近の変更」と「アプリのコード」に一番詳しい人です。SRE と役割を分けて動きます。

対応中は、決めたチャンネルで「何が起きていて、何をしていて、次はいつ報告するか」を短く流します。1人で黙って調べ続けないことが大事です。

ロールバックとデータの互換性

Web エンジニアは、ログを「出す（実装する）」側の中心です。どんなログを出すかは目的によって相談相手が変わり、集めて保管する基盤は SRE やデータエンジニアが持つことが多いです。

会社によっては、行動ログの実装もデータの基盤チームが SDK を用意し、Web エンジニアはそれを呼ぶだけ、という分け方もあります。どの場合も、イベントの名前や項目を勝手に変えない（変えるときはデータ側のレビューに入れる）ことと、個人情報をログに入れないことが Web エンジニアの責任です。分担の全体は Data のログは誰が設計・実装するかにまとめています。