Skip to content
←

✍️ 필사 모드: フロントエンド CI/CD·デプロイ 2025 — GitHub Actions·Turborepo·Vercel·Netlify·Cloudflare·プレビュー·カナリア·機能フラグ·SLSA/SBOM (シーズン6 第12回)

日本語
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

プロローグ — CI/CDがプラットフォームである

2016年のCI/CDは「Jenkinsがテストを走らせ、rsyncする」だった。2026年、パイプラインはデプロイ面そのもので、「1日10回出荷するチーム」と「3週間に1回出荷するチーム」の差はほとんどパイプライン成熟度にある。

本稿はフロントエンドCI/CDの風景をたどる: ランナー、キャッシング、プレビュー、カナリア/ブルーグリーン、機能フラグ、サプライチェーン整合性 (SLSA/SBOM) — 2026年の具体的パターン。

1章. 2026年のパイプライン解剖

モダンなフロントエンドパイプラインは7段階。

  1. Install — lockfile検証 + キャッシュされたインストール。
  2. Lint/typecheck — 並列。
  3. Test — ユニット + 統合 + e2e (最後はしばしば条件付き)。
  4. Build — モノレポではパッケージごと、キャッシュ対応。
  5. Preview deploy — PRスコープのURL。
  6. Security — SBOM、SLSA証跡、脆弱性スキャン。
  7. Production deploy — カナリア → 全面。

各段階は積極的にキャッシュし、早く失敗する。

2章. GitHub Actions — デフォルト

GitHub ActionsはOSSと公開企業で約80%シェア。2024–2025プラクティス:

  • Reusable workflows (workflow_call) でコピペ回避。
  • Composite actions でローカル「ミニアクション」。
  • Self-hosted runners を大規模リポで。
  • Concurrency groups — 同じPRの古いラン取り消し。
  • OIDCでクラウド資格情報 — 長期シークレットなし。

最小だが堅牢なワークフロー

name: ci
on:
  pull_request:
  push:
    branches: [main]
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v3
      - uses: actions/setup-node@v4
        with: { node-version: '22', cache: 'pnpm' }
      - run: pnpm install --frozen-lockfile
      - run: pnpm turbo run build test lint
        env:
          TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }}
          TURBO_TEAM: ${{ vars.TURBO_TEAM }}

3章. Turborepo Remote Cache — 性能の解錠

リモートキャッシュのないモノレポは時間を浪費。導入で典型的CIが8分→2分未満。

  • Turborepo: 入力 (ソース + deps + env) をハッシュ → 既存ハッシュのタスクをスキップ。
  • Remote cache: マシン間で結果共有。Vercelがホスト、turbo-cache + S3/MinIOでセルフホスト可能。
  • Nxに同等機能 (Nx Cloud)。
  • Bazelは重量級オプション — フロントエンド専用チームには不要。

ルール: CIが3分超で複数パッケージあるなら、リモートキャッシュは必須。

4章. プレビュー環境

PRごとのプレビューURLは標準に。

  • Vercel/Netlify/Cloudflare Pages — プッシュごと自動プレビュー。
  • Render/Railway — バックエンド用コンテナ風プレビュー。
  • Playwright + Chromatic — 各プレビューでビジュアル回帰。
  • GitHub environments + 保護ルールでステージ昇格。

パターン: 各PRがURL、ボットコメント、スクリーンショットdiffを2分以内に得る。

5章. デプロイプラットフォーム — Vercel, Netlify, Cloudflare

次元VercelNetlifyCloudflare Pages/Workers
主強みNext.js統合元祖Jamstackグローバルエッジ + コンピュート
Build分速、計測類似寛容/無料
エッジコンピュートEdge Functions + FluidEdge FunctionsWorkers (最強)
価格シート + 利用シート + 利用利用のみ、規模で安
画像最適化内蔵内蔵R2 + Image Transformations

2025のシフト

  • Vercel Fluid Compute — 「isolate風並行性のサーバーレスNode Functions」。性能向上が響きより大。
  • Cloudflareはフレームワーク統合でギャップを縮めた (Next.js、SvelteKit、SolidStart)。
  • Netlifyは「コンポーザブル」へ大転換 — モノリスでなく統合。

6章. カナリアとブルー/グリーン

フロントエンドのカナリアは「デプロイして祈る」だった。2026年は:

  • トラフィック%分割 (Vercel Skew Protection、Cloudflare %分割)。
  • コホート (ユーザーIDでキーの機能フラグ)。
  • ヘッダベース (内部ユーザーがヘッダ経由でカナリア)。
  • ブルー/グリーン: CDN origin swapまたはatomic symlinkで静的アセット。

Skew protectionは微妙だが重要 — v1のHTMLをロードしたユーザーがv2チャンクをフェッチしてクラッシュしない保証。Vercel/Netlifyが提供。セルフホストなら自作。

7章. 機能フラグ — 必須

2026年、機能は出荷ではなくロールアウト。

プロバイダ: LaunchDarkly、Statsig、Unleash、PostHog、Vercel Edge Config、GrowthBook。

ユースケース:

  • キルスイッチ (デプロイなしで壊れた機能無効化)。
  • コホートロールアウト (10% → 50% → 100%)。
  • 実験 (A/Bテスト、ファネル分析)。
  • 長期ダークローンチ。

アンチパターン:

  • クリーンアップされないフラグ (フラグ負債)。
  • 核心フローの分岐ロジックとしてのフラグ (コード難読化)。
  • フラグ状態の観測性なし。

ルール: フラグライフサイクルは第一級の関心事 — 年齢追跡、削除マーク、削除PR。

8章. サプライチェーン — SLSA, SBOM, 証跡

2024年、SolarWindsとnode-ipc以降、多くの企業でSLSA Level 3+が現実に。

  • SBOM (Software Bill of Materials) — CycloneDXまたはSPDX JSONをビルドごとに出力。
  • Provenance attestation — ビルドがコミットXからアクションYで作られた署名証跡。
  • Sigstore / cosign — 鍵管理なしの署名OSSツールチェーン。
  • npm provenance (2023+) — --provenanceで発行しコンシューマが検証。
  • GitHub Artifact Attestations (2024) — Actions内蔵。

なぜフロントエンドが気にするか: 侵害されたビルドは悪意コードを全ユーザーに配信。SBOM + 証跡が「このバンドルを信頼できるか？」を検証可能にする。

9章. シークレット管理

  • リポに長期シークレットなし — 明白だが違反多し。
  • クラウドへのOIDC — GitHub Actions ↔ AWS STSが標準。
  • Vault / Doppler / 1Password Secrets Automation — ランタイム用。
  • Vercel/Netlify環境変数 — 環境ごとスコープ。
  • gitleaks/trufflehogのpre-commitフック — 誤コミット捕獲。

10章. パイプラインの観測性

CIメトリクスを本番メトリクスのように見るべき:

  • ワークフローごとのP50/P95/P99継続時間。
  • ジョブごとの失敗率。
  • キャッシュヒット率。
  • 実行あたりコスト。

ツール: GitHub Insights、Datadog CI Visibility、BuildPulse、Foresight。

11章. 共通の失敗モード

  1. Flakyテスト — 根本原因、リトライでなく。必要ならslow-laneへ隔離。
  2. キャッシュ無効化の驚き — node版、OS、lockfileハッシュをキャッシュキーに常に含める。
  3. 並列ジョブ間の共有可変状態 — 避ける。matrix outputsを使う。
  4. 広すぎるconcurrency group — cancel-in-progressがmainを殺す。
  5. ログ漏れシークレット — 動的値に常に ::add-mask::。
  6. ロールバック計画なし — DBマイグレーション戦略なしの「前にデプロイ」では不十分。

12章. 2026年の理想パイプライン

PR opened
├─ 30秒: installキャッシュヒット
├─ 60秒: lint + typecheck (並列)
├─ 90秒: ユニットテスト
├─ 120秒: build (Turboキャッシュ)
├─ 150秒: preview URLポスト
├─ 180秒: visual回帰 + e2e on preview
├─ 200秒: SBOM + 証跡署名
└─ review required → merge → canary → full

PRフィードバック総時間: 約3分
本番到達総時間: 約10分 (カナリア保持付き)

13章. 今後

  1. Dagger / サンドボックスビルド — TypeScript/Goでパイプラインをコード化、プラットフォーム横断。2025年で勢い。
  2. AI拡張CI — flakyテスト検出、失敗トリアージ (Datadog FlakyTest、BuildPulse AI)。
  3. エッジパイプライン — グローバルデプロイ高速化のためエッジでCIランナー。
  4. プラットフォームチームのデプロイ所有権 — 大企業が「各チームがデプロイ所有」から「プラットフォームが滑走路所有、チームがアプリ執筆」へ。

12項目チェックリスト

  1. 典型的PRでCIが5分未満？
  2. リモートキャッシュ有？
  3. 各PRにプレビューURL？
  4. lockfile整合性検証？
  5. シークレット戦略はOIDC + 長期トークンなし？
  6. SBOM + provenance出力？
  7. カナリアまたは%ロールアウト有？
  8. 機能フラグシステム + ライフサイクル管理？
  9. 月次ロールバックテスト？
  10. パイプライン観測性が本番と統合？
  11. 依存変更監査 (Dependabot/Renovate)？
  12. デプロイ通知がSlack/Linear/Discordに連動？

10アンチパターン

  1. キャッシングなし — CIがコード量に比例。
  2. プレビューURLなし — PRレビューが頭内で起きる。
  3. 「便利のため」コミットされた.envのシークレット。
  4. OIDCなし — 回転しない長期AWSキー。
  5. 「デプロイ = マージ」 — カナリア、ゲートなし。
  6. フラグが永遠に蓄積 (フラグ負債)。
  7. Flakyテストを失敗時リトライ — 真のバグを隠す。
  8. SBOMなし — サプライチェーン不可視。
  9. ロールバック手順なし — 「前進」はユーザーを壊す。
  10. #generalへのデプロイ通知 — 誰も読まず、誰も無視。

シーズン6最終回 — 次

次はシーズン6を締めくくる: 2025年のフロントエンドエンジニア キャリア成長 — RSC、Signals、AI、エッジ、フルスタック、デザインエンジニア、バーンアウト、韓国コミュニティ。今後3年のキャリアマップ。

— CI/CD編、完。

현재 단락 (1/142)

2016年のCI/CDは「Jenkinsがテストを走らせ、rsyncする」だった。2026年、パイプラインは**デプロイ面そのもの**で、「1日10回出荷するチーム」と「3週間に1回出荷するチーム」の...

작성 글자: 0자원문 글자: 5,076자작성 단락: 0/142