ビルドとデプロイ
このページで学ぶこと
Section titled “このページで学ぶこと”- 開発用ソースと公開用ファイルの違い
- ビルドツールが行う変換・結合・最適化
- フレームワーク導入によって公開工程が増える理由
- 依存パッケージやNode.jsのバージョン管理
- ビルド時間、失敗、ロールバックをPMが管理する方法
モダンなフロントエンドでは、開発者が書いたファイルをそのまま本番へ置かず、ビルドを通して公開用成果物を作ることが多くなっています。
flowchart LR
S[ソースコード<br/>部品・設定・画像] --> I[依存パッケージ取得]
I --> B[ビルド<br/>変換・結合・最適化]
B --> T[テスト・検査]
T --> A[公開用成果物]
A --> D[デプロイ]
D --> H[ホスティング・サーバー]
ビルドは成果物を作る工程、デプロイは成果物を利用者がアクセスする環境へ反映する工程です。
なぜビルドが必要なのか
Section titled “なぜビルドが必要なのか”ブラウザ向けに変換する
Section titled “ブラウザ向けに変換する”部品ファイル、新しいJavaScript構文、CSSの拡張記法等を、対象ブラウザで動作する形式へ変換します。
ファイルを整理する
Section titled “ファイルを整理する”多数のJavaScript・CSS・画像の依存関係を解析し、必要な公開ファイルを作ります。
配信を最適化する
Section titled “配信を最適化する”- 空白・コメントを削減
- ファイルを分割
- 不要コードを除外
- ファイル名へハッシュを付ける
- 画像・CSSを処理
- ページごとのHTMLを生成
ビルドツールにはVite、webpack等があります。フレームワークの内部で使われ、直接意識しない場合もあります。
開発サーバーと本番ビルド
Section titled “開発サーバーと本番ビルド”開発中は変更をすぐ反映し、エラーを詳しく表示する開発サーバーを使います。本番では、性能・互換性・キャッシュを考慮したファイルを作ります。
flowchart TD
DEV[開発中] --> DS[開発サーバー<br/>高速な更新・詳細エラー]
PROD[本番公開] --> PB[本番ビルド<br/>最適化・圧縮・分割]
「開発環境では動くが本番ビルドで失敗する」「本番だけ環境変数が異なる」という問題が起こります。本番と同じ条件で検証します。
バンドルとコード分割
Section titled “バンドルとコード分割”複数のモジュールと依存関係を解析し、配信用ファイルへまとめる処理をバンドルと呼びます。
必ず一つの巨大ファイルへまとめるわけではありません。ページ・機能ごとに分割し、必要なときだけ読み込むコード分割も行われます。
flowchart LR
M1[ヘッダー部品]
M2[検索部品]
M3[地図ライブラリ]
M4[共通処理]
M1 --> G[依存関係を解析]
M2 --> G
M3 --> G
M4 --> G
G --> C1[共通ファイル]
G --> C2[検索ページ用]
G --> C3[地図ページ用]
分割しすぎると通信・管理が増え、まとめすぎると初回ファイルが大きくなります。性能測定を基に判断します。
依存パッケージ
Section titled “依存パッケージ”フレームワーク、UI部品、フォーム、日付処理、画像処理等を外部パッケージとして利用します。
- 既存機能を再利用できる
- 開発時間を短縮できる
- 実績ある実装を利用できる
- 脆弱性
- 更新停止
- ライセンス
- 互換性
- 間接依存
- メジャーアップデート
導入時だけでなく、公開後の更新責任を決めます。
Node.jsとビルド環境
Section titled “Node.jsとビルド環境”多くのフロントエンドツールはビルド時にNode.js上で動きます。公開物が静的HTMLでも、開発・ビルドにはNode.jsが必要な場合があります。
flowchart LR
N[Node.js実行環境] --> F[フレームワーク]
N --> T[ビルドツール]
F --> O[HTML・CSS・JS]
T --> O
O --> CDN[静的ホスティング・CDN]
次を管理します。
- Node.jsのバージョン
- パッケージ管理ツール
- ロックファイル
- ビルドコマンド
- 環境変数
- ビルドサービスの設定
担当者のPCでしかビルドできない状態を避け、CI等で再現可能にします。
環境変数と秘密情報
Section titled “環境変数と秘密情報”開発・検証・本番で異なるURL、APIキー、機能設定を環境変数として扱うことがあります。
フロントエンド向けにビルドされた値は、ブラウザから見える可能性があります。
- 公開可能なCMS APIキー
- 公開APIのURL
- 計測ID
等は用途に応じて使えますが、管理者用秘密鍵、メール送信の秘密キー、DBパスワード等をブラウザ向けファイルへ含めてはいけません。
秘密処理はサーバー側・サーバーレス関数等へ置きます。
SSGとビルド時間
Section titled “SSGとビルド時間”SSGでは、ビルド中にページごとのHTMLを作ります。ビルド時間は次に影響されます。
- ページ数
- CMS APIの速度
- 画像処理
- 多言語数
- 検索インデックス生成
- 外部API
- ビルド環境性能
- キャッシュ
- 差分ビルド
開発初期の10ページでは短くても、移行後の1万ページでは変わります。実データ量に近い条件で測定します。
ビルド失敗の主な原因
Section titled “ビルド失敗の主な原因”- ソースコードのエラー
- テスト・検査失敗
- CMS・API停止
- APIのレート制限
- 必須データ欠損
- 画像処理失敗
- メモリ不足・タイムアウト
- Node.js・パッケージ不整合
- 環境変数不足
- ビルドサービス障害
ビルド失敗時は、以前の正常版を配信し続けられる構成が望ましいです。
デプロイの方式
Section titled “デプロイの方式”手動アップロード
Section titled “手動アップロード”FTPや管理画面でファイルを配置します。単純ですが、作業漏れ、差分不明、担当者依存が起こりやすい方式です。
特定ブランチへの変更を起点に、ホスティングサービスがビルド・デプロイします。レビューと変更履歴を公開へつなげやすくなります。
CI/CDパイプライン
Section titled “CI/CDパイプライン”テスト、ビルド、承認、デプロイ、通知を自動化します。厳格な公開に向きますが、パイプライン自体の保守が必要です。
プレビュー環境
Section titled “プレビュー環境”Pull Requestやブランチごとに一時URLを作る機能があります。
- URLでレビューできる
- 複数案を並行確認できる
- 本番に近い環境で検証できる
- 検索エンジンへ公開しない
- 個人情報・本番データを使わない
- アクセス制限
- 外部APIの検証環境
- URLの有効期限
- CMS下書きとの連携
ロールバック
Section titled “ロールバック”ロールバックは、公開後に問題が起きた際、以前の正常版へ戻すことです。
flowchart LR
V1[正常版 v1] --> V2[新規公開 v2]
V2 -->|重大不具合| R[ロールバック]
R --> V1
静的ファイルだけなら戻しやすい場合がありますが、次を伴うと単純ではありません。
- CMSコンテンツ変更
- DB構造変更
- 外部API仕様変更
- 送信済みフォームデータ
- キャッシュ
- DNS
- 検索インデックス
「ソースを戻す」だけで全体が戻るか確認します。
実案件ではどう考えるか
Section titled “実案件ではどう考えるか”ヘッドレスCMS＋SSG
Section titled “ヘッドレスCMS＋SSG”CMS更新、Webhook、ビルド、テスト、デプロイ、CDN更新の経路を図示します。通常更新と緊急更新で、反映時間・承認・失敗時対応を決めます。
数千ページ移行
Section titled “数千ページ移行”実データでビルド時間を測り、画像、リンクチェック、サイトマップ生成も含めて公開時間を見積もります。
外部API連携
Section titled “外部API連携”ビルド時に外部APIを読む場合、API停止で公開できない可能性があります。キャッシュデータ、再試行、タイムアウト、旧版維持を検討します。
PMチェックリスト
Section titled “PMチェックリスト”- ビルドが必要な理由と処理内容を説明できる
- 本番と同じ条件でビルドできる環境がある
- Node.js・パッケージ管理ツールのバージョンを固定している
- 依存パッケージの更新担当を決めている
- 公開用環境変数と秘密情報を分けている
- 本番データ量でビルド時間を測定している
- ビルド失敗時に旧版を維持できる
- 通知先・ログ確認・再実行手順がある
- プレビュー環境のアクセス制御を決めている
- デプロイ承認者と公開権限を決めている
- ソース以外のロールバック対象を確認している
よくある誤解・失敗
Section titled “よくある誤解・失敗”「静的サイトなのでビルド環境は不要」
Section titled “「静的サイトなのでビルド環境は不要」”Astro等で生成する場合、公開物は静的でもNode.jsやビルドサービスが必要です。
「ローカルで動くので本番でも動く」
Section titled “「ローカルで動くので本番でも動く」”Node.js、環境変数、OS、パス、ネットワークが異なり、本番ビルドで失敗することがあります。
「パッケージは一度入れたら更新不要」
Section titled “「パッケージは一度入れたら更新不要」”脆弱性、ブラウザ変化、Node.js終了、互換性により更新が必要です。
「ビルド時間はページ数だけで決まる」
Section titled “「ビルド時間はページ数だけで決まる」”CMS速度、画像、API、並列、キャッシュ、メモリにも影響されます。
「ロールバックはGitを一つ前へ戻すこと」
Section titled “「ロールバックはGitを一つ前へ戻すこと」”データ、CMS、キャッシュ、外部仕様等も戻す必要がある場合があります。
理解度チェック
Section titled “理解度チェック”Q1. ビルドとデプロイの違いは何ですか。
Section titled “Q1. ビルドとデプロイの違いは何ですか。”回答と解説
ビルドは開発用ソースから公開用成果物を作る工程、デプロイは成果物を本番等へ反映する工程です。Q2. 公開物がHTMLだけでもNode.jsが必要な理由は何ですか。
Section titled “Q2. 公開物がHTMLだけでもNode.jsが必要な理由は何ですか。”回答と解説
フレームワークやビルドツールがNode.js上で動き、HTML等を生成するためです。本番配信時には不要な構成もあります。Q3. 開発初期だけでビルド時間を判断してはいけない理由は何ですか。
Section titled “Q3. 開発初期だけでビルド時間を判断してはいけない理由は何ですか。”回答と解説
本番ページ数、画像、多言語、CMSデータ、外部APIで処理量が大きく変わるためです。Q4. 秘密キーをフロントエンド環境変数へ入れれば安全ですか。
Section titled “Q4. 秘密キーをフロントエンド環境変数へ入れれば安全ですか。”回答と解説
ブラウザ向けファイルへ埋め込まれる値は見える可能性があります。秘密キーはサーバー側で管理します。Q5. ビルド失敗時の望ましい本番挙動は何ですか。
Section titled “Q5. ビルド失敗時の望ましい本番挙動は何ですか。”回答と解説
新しい版を公開せず、以前の正常版を配信し続け、担当者へ失敗通知とログを提供することです。- Vite「Getting Started」
https://vite.dev/guide/ - Vite「Building for Production」
https://vite.dev/guide/build - webpack「Concepts」
https://webpack.js.org/concepts/ - React「Build a React app from Scratch」
https://react.dev/learn/build-a-react-app-from-scratch - Cloudflare Pages「Build configuration」
https://developers.cloudflare.com/pages/configuration/build-configuration/