Cloudflare は、各 Git ブランチに独立した実行環境を提供する Worker Previews サービスを開始した。これにより、本番に近い条件でコード変更をテストしながら、稼働中のバージョン固有のトラフィック、設定、状態に影響を与えずに済む。このサービスは現在、Workers のユーザーが利用できる。
各プレビューにはブランチ用の固定 URL が付与され、新たなプッシュのたびに更新される。さらに、分離された設定、変数、シークレット、バインディングも提供される。開発者は、ターミナル、継続的インテグレーションシステム、ブラウザーからプレビューへリクエストを送信し、Workers Observability のツールを通じてログ、エラー、メトリクス、実行トレースを調査できる。
単なるバージョン用リンクを超えた独立環境
Cloudflare は、Worker Previews が従来の Version URLs とは異なると説明している。Version URLs はアップロード済みの特定バージョンを指し、本番リソースを使用する場合がある。一方、Worker Previews は各ブランチに分離環境を作成し、1つのダッシュボード内で数百件のプレビューを並行して実行できる。これにより、コードの確認や共有ステージング環境への依存にとどまらず、実際の実行コンテキストで API エンドポイント、ユーザーインターフェースの変更、ログインフローをテストできる。
npx wrangler preview コマンドを実行すると、Cloudflare は Wrangler ファイルで開発者が指定した基本設定に基づいてプレビューのバージョンを作成する。特定のプレビューの設定を変更し、テスト用データベースや API キーへ向けることもできるが、本番や他のプレビューの設定は変更されない。また、カスタムドメインを通じてプレビューのアドレスを提供し、Cloudflare Access を使用して保護やアクセス制限を行うこともできる。
状態と機密リソースの分離
分離は状態を持つリソースにも及ぶ。各プレビューには独立した Durable Objects の領域と Containers アプリケーションが用意されるため、状態やセッションの変更、移行処理、スキーマ変更の失敗が本番や他のブランチに到達するのを防げる。Cloudflare はこの動作をコードのブランチコンテキストに結び付けている。つまり、本番で実行すると ctx.exports は本番領域に解決され、テストブランチ内で実行すると適切なプレビュー領域に解決される。
実際には、これにより同じアプリケーションについて異なる設定を比較できる。例えば、コールド実行とウォーム実行のパフォーマンスをテストしながら、各実験の結果をそれぞれの環境内に限定できる。また、Browser Run を使用してヘッドレスブラウザーでプレビューのリンクを開き、ログインフローを実行してスクリーンショットや再実行可能なセッションを取得し、ユーザーに表示された内容を記録された実行トレースやエラーに関連付けることもできる。
実際には何が変わるのか
Worker Previews は各ブランチに、本番前のフィードバックループを提供する。変更をデプロイし、実行し、監視し、問題を修正してから、マージ前に再度テストするという流れである。Cloudflare は、これが同社の呼ぶエージェント開発ライフサイクルを支えると考えている。ソフトウェアエージェントは、同じブランチの範囲内で変更を実行し、検査し、結果をレビューでき、必要に応じて人間のレビュアーが介入することも可能だ。
Cloudflare は、CloudflareOS と Gatekeepers のテストにこのサービスを社内で使用した。特に、OAuth、権限、承認、アプリケーション状態を組み合わせたフローが対象となった。また同社は、Supermemory と Ramp による Workers の変更テストや、モバイル端末からのマージリクエストのレビューに関する事例も紹介した。
公表された制限と今後のステップ
現在、複数の Workers を使用するアプリケーションでは、リクエストチェーン全体がプレビュー内で分離されるわけではない。プレビューからサービスバインディングを呼び出すと、関連付けられた Worker の本番バージョンが呼び出される場合がある。また、プレビューは Queues にメッセージを送信できるが、現時点ではメッセージを消費できない。Workflows の実行を分離するには、別途設定が必要となる。Cloudflare は、staging、QA、継続的な開発環境向けの長期的なプレビューの提供に加え、これらの経路のサポートにも取り組んでいる。
certi.news の見解：今回の発表の核心的な価値は、新たなテスト用リンクの作成ではなく、分離を設定、状態、監視のレベルへ拡張した点にある。これにより、状態を持つリソースに影響する変更をテストするリスクは低減するが、テスト環境を慎重に設計する必要がなくなるわけではない。特に、サービスが複数の Workers、キューやメッセージ、長期的なフローに依存する場合は注意が必要だ。そのため、Worker Previews は単一バージョンのプレビューよりも完成度が高いように見えるが、現行版ではアプリケーションの一部が完全な分離モデルの外部に残っている。