Cloudflareは9月22日、Cloudflare Workers向けの
これまでのプレビューURL
ブランチごとの環境で動作を確認
プレビューは、Workers向けのコマンドラインツールnpx wrangler previewを実行すると、作業中のGitブランチに対応するプレビューが同じWorkerの下に作成・
プレビューを更新してもブランチのURLは変わらず、共有したリンクから常に最新版を確認できる。これとは別に、デプロイごとにその時点の版を指す固定URLも発行されるため、レビューで特定の版を示したり、後から同じ版を開いて確認したりする際に使える。
ログ、エラー、メトリクス、トレースもプレビューごとに確認できる。画面上の挙動と実行時の記録を突き合わせ、不具合の修正と再デプロイを繰り返せる。
Cloudflareは、AIエージェントによってコードの変更量が増える中、本番前に検証すべき範囲も広がっていると指摘する。発表記事では、ブラウザー操作やトレースの取得に使うツールと組み合わせ、AIエージェントにこの一連の検証を行わせる例も示した。
プレビューには独自ドメインも使え、CookieやOAuthのリダイレクトなどを本番に近いドメイン条件で確認できる。Cloudflare Accessによるアクセス制限にも対応する。
本番から分離できる範囲と条件
プレビューは本番設定を自動では使わず、開発者が指定した共通のプレビュー用設定を基に作成される。環境変数や、データベースなどへの接続先を示すバインディングは、Wranglerの設定ファイルにあるpreviewsブロックで指定する。シークレットは設定ファイルに書かず、別途設定する。個々のプレビューだけ接続先のデータベースやテスト用APIキーを変更することもでき、本番や他のプレビューの設定には影響しない。
実行中に変化するデータやセッションなどの状態を分ける仕組みも備える。状態を保持するDurable Objectsは、同じWorker内で定義し、参照先のWorkerを指定するscript_を使わない場合、プレビュー専用の名前空間とストレージが自動で用意される。コンテナを実行するContainersにも専用のアプリケーションとインスタンスが用意され、状態の変更や移行処理、並行したテストの影響を各プレビュー内にとどめられるようになる。
一方、KV、D1、R2などのデータを分離するには、別のリソースを接続先に指定する必要がある。同じリソースIDや名前を指定すると、プレビュー同士や本番環境でデータを共有することになる。
また、現時点ではプレビューからサービスバインディングで別のWorkerを呼び出すと、接続先の本番デプロイにつながる。プレビュー側でのQueuesのメッセージ受信や、専用Workflowの自動作成にも対応していない。リソースごとの対応状況や設定条件は、公式ドキュメントで確認できる。
CloudflareのNanda Syahrasyad氏は、プレビューを本番から分離する設計が見た目以上に複雑だったとXに投稿した。Workerにリソースを接続するバインディングを、プレビュー用と本番用に分ける必要があったためという。
社内外での活用と今後の展開
Worker Previewsは、Cloudflare社内の開発でも使われている。CloudflareのYomna Shousha氏はXへの投稿で、AIエージェントを社内システムに接続する
Cloudflareは、複数のWorkerにまたがるリクエストや、QueuesとWorkflowsによる非同期処理も、同じブランチのプレビュー内で完結させられるよう開発を進めている。ステージングやQAなどで、プレビューを長期間利用しやすくすることも目指している。
Worker Previewsはすでに利用可能で、Wrangler 4.