Cloudflare Pagesのプレビューデプロイ運用メモ
このサイトは今、NetlifyからCloudflare Pagesへの移行を進めているところです。その中で先に方針を決めておきたいのが、プレビューデプロイをどう運用に組み込むか。個人ブログで一番面倒なのは「本番に出してからレイアウト崩れやリンク切れに気づく」ことで、直すまでその状態が公開され続けるうえ、慌てて修正すると別の場所を壊しがちです。移行後は、記事もデザイン変更も、まずプレビューで確認してから本番に上げる流れを標準にしたい。そのためのメモです。なお、これは移行の真っ最中に書いている運用設計のメモで、完了報告ではありません。
プレビューデプロイの仕組み
Cloudflare PagesをGitHubリポジトリと連携させておくと、本番ブランチ以外のブランチへのプッシュや、プルリクエストの作成をきっかけに、自動でプレビューデプロイが作られます。プレビューには <ハッシュ>.<プロジェクト名>.pages.dev という専用URLが発行され、カスタムドメインにも本番用の *.pages.dev にも影響しません。
URLには実は2種類あります。1つはハッシュ付きのURLで、そのコミット時点の内容を指し続けます。もう1つはブランチ名のエイリアスで、<ブランチ名>.<プロジェクト名>.pages.dev の形をしていて、常にそのブランチの最新コミットを指します（ブランチ名は小文字化され、/ などの英数字以外はハイフンに置き換わります）。使い分けは単純で、誰かに「この状態を見てほしい」と渡すときはハッシュ付き、そのブランチの最新を自分で追うときはエイリアス、と決めておくと混乱が減ります。なお、フォークから作られたプルリクエストにはプレビューURLが作られない、という仕様も公式に明記されています。個人サイトではあまり関係ありませんが、覚えておくと「なぜプレビューが来ないのか」で悩まずに済みます。
どのブランチを自動ビルドの対象にするかも設定で調整できます。デフォルトは本番以外の全ブランチが対象ですが、プロジェクトの設定（Builds & deployments のブランチビルド制御）で対象を絞ったり、特定のパターンを除外したりできます。下書き用のブランチまで全部プレビューが立つと一覧が埋もれるので、運用が固まったら対象の見直しも検討するつもりです。
本番とプレビューで変わるもの・変わらないもの
中身の作りは同じです。同じビルドコマンドが走り、同じ成果物が生成されます。違うのは、公開先のURLと、環境変数のセットです。表にするとこうなります。
| 項目 | 本番（Production） | プレビュー（Preview） |
|---|---|---|
| ビルドコマンド・成果物 | 同じビルドコマンドが走り、同じ成果物が生成される | 本番と同じ（変わらない） |
| 公開先のURL | カスタムドメイン・本番用の *.pages.dev | <ハッシュ>.<プロジェクト名>.pages.dev（本番側には影響しない） |
| 環境変数 | Production 用のセット | Preview 用のセット（本番とは別々に設定する） |
| 解析タグ | 本来の集計対象 | テンプレートに埋め込んでいる場合、本番と同じタグが入り、自分の確認アクセスが本番の集計に混ざる |
Cloudflare Pagesの環境変数は、本番（Production）とプレビュー（Preview）で別々に設定する仕様になっています。これは地味に大事で、プレビュー専用の値を用意できる一方、本番にだけ入れた変数はプレビューで空になる、その逆も起きます。「プレビューでは動いたのに本番で表示がおかしい」の原因が、実は環境変数の入れ忘れだった、というのは十分あり得る話です。変数を追加・変更したら、本番とプレビューの両方に必要な値が入っているかをセットで確認する、をルールにしておきます。環境変数と秘密情報の扱いの詳細は、Cloudflare Pages／Workersの環境変数と秘密情報の扱いにまとめています。
もう1つ気をつけたいのが解析タグです。サイト側のテンプレートにアクセス解析のタグを直接埋め込んでいる場合、プレビューにも同じタグが入り、自分の確認アクセスが本番の集計に混ざります。移行を機に、タグの出し分けが必要かどうかは確認しておきたい点です。少なくとも「プレビューの数字は本番の解析に混ざりうる」と意識しておくだけでも、数字の読み間違いは防げます。
プレビューURLの共有とアクセス制御
プレビューURLは、デフォルトでは公開されています。 URLを知っている人なら誰でも見られる状態です。ハッシュが付いているので推測はされにくいものの、「未公開の記事をプレビューでだけ確認したい」という使い方では少し心もとない。
その場合は、Cloudflare Accessでプレビューに認証をかけられます。プロジェクトの設定（Settings > General）でアクセスポリシーを有効にすると、プレビューデプロイの閲覧がCloudflareアカウント側で許可した相手に制限されます。注意点として、この保護の対象はプレビューデプロイだけで、本番の *.pages.dev やカスタムドメインにはかかりません。「サイト全体を非公開にしたつもり」にはならない、ということです。
個人ブログの場合は、誰かにレビューをお願いする予定がなければ、無理に認証を入れず、プレビューには下書き丸出しの内容を載せない、という割り切りでもいいと思っています。ここは移行後に実際の使い方を見て決めるつもりです。
確認チェックの型
プレビューが立つたびに何をどこまで見るか、最初に型を決めておかないと、結局「なんとなく開いて終わり」になります。今のところ考えている最小セットは次の4つです。
- 表示：対象の記事・ページを開き、レイアウト崩れと画像の欠けがないか。スマートフォン幅でも一度見る
- リンク：記事内のリンクと、前後の記事への導線を実際に踏む。移行直後は旧URLからのリダイレクトも対象
- 検索まわり：タイトルとdescriptionが意図どおりに出ているか、ソースで確認する
- インデックス除外：プレビュー側が検索結果に出ない設定になっているか
4番目については、Cloudflare Pagesのプレビューデプロイにはデフォルトで X-Robots-Tag: noindex ヘッダが付く仕様です。手元でも、ターミナルから
curl -I https://<プレビューURL>.pages.devを実行して、レスポンスに x-robots-tag: noindex が含まれるかで確認できます。重複コンテンツとして検索エンジンに拾われないための仕組みが最初から入っているのは、移行先として地味に安心できる点でした。古くなったプレビューを消したい場合は、wrangler pages deployment delete でデプロイ単位に削除もできます。
運用ルールとして決めたこと
まとめると、このサイトでのプレビューデプロイの使い方はこうなります。変更はブランチで作業し、プレビューURLで上のチェックを通してから本番ブランチへマージする。共有が必要なときは、その時点の状態を指すハッシュ付きURLを渡す。環境変数を触ったら本番・プレビューの両方を確認する。下書き段階の記事はプレビューにも載せないか、載せるならAccessの導入を先に検討する。
いずれも大げさな仕組みではなく、「本番で初見」をなくすための小さい決め事です。実際に回し始めてから不便な点が出たら、このメモ自体を更新していく予定です。