解決策
Cloudflare Workersにはすでに、アップロードされた特定のバージョンを指すVersion URLがありましたが、それは本番リソースしか指せず、変更ごとに独立した環境を作るものではなかったため、大きな変更を安全にテストするには共有ステージングの状態を危険にさらすか、環境ごとに別のWorkerを立ち上げる必要がありました。エージェント支援による開発がより多くの、より大きな変更をパイプラインに流すようになるにつれ、エージェントの速度を落とさずに、マージ前に実施すべきテストが増えていきました。
Worker Previewsはブランチのモデルをコードの範囲を超えて拡張します。任意のブランチで npx wrangler preview を実行すると、独自のURLと設定を持つ独立した環境が作成され、ブランチごとに上書きできる基本設定を継承します。より難しい問題は状態でした。Durable Objectsは1つのインスタンスがそのストレージを所有するシングルトンモデルを採用しているため、Previewが本番と同じ名前空間を共有すると、失敗したマイグレーションが稼働中のトラフィックを変更してしまう可能性がありました。この修正ではPreviewごとに新しいDurable Object名前空間を作成し、ctx.exportsを通じて解決することで、同一のコードが本番とPreviewで異なる名前空間に到達するようにしています。
Cloudflareはこの機能をCloudflareOSでドッグフーディングしました。CloudflareOSは、権限をスコープした「Gatekeepers」を通じてエージェントがGoogle、GitHub、Slackなどのサービスを扱えるようにする、Cloudflare自身のオープンソースプラットフォームです。Gatekeeperのバグ、OAuthコールバック、承認フロー、権限状態の不整合は、システム全体が一緒に動作したときに初めて表面化するため、チームはレビュー対象の変更ごとにCloudflareOSの独立したPreviewをデプロイし、マージ前にワークフロー全体を実行しています。
達成したこと
gitのブランチをコードから環境と状態へと拡張する
うまくいった理由
Previewごとに新しいDurable Object名前空間とContainerアプリケーションを自動的にプロビジョニングすることで、Previewが本番トラフィックを処理するストレージを気づかないうちに変更してしまうという障害モードを解消します。
Previewが継承する再利用可能な基本設定を定義し、ブランチごとの上書きを可能にすることで、個別の環境が必要としていたようにブランチごとにシークレットやバインディングを一から再設定する必要がなくなります。
CloudflareOSのGatekeepersでのドッグフーディングは、分離されたコンポーネントテストではバグを検出できないケースを狙ったものでした。そのバグはOAuth、権限、承認フローが一緒に動作したときにのみ現れるからです。
Previewごとに可観測性をスコープすることで、障害を本番トラフィックや他の進行中の変更に混ざった状態ではなく、そのブランチ自身のトレースとログから診断できるようになります。
応用できること
「ステージングでは動くが本番では壊れる」という問題が繰り返されるなら、多くのツールが共有したままにしているステートフルな部分も含め、あらゆる環境をコードのブランチと同じくらい安価かつ独立してプロビジョニングできるようにしましょう。
その後
Cloudflareはローンチ時点で残るギャップを挙げています。Previewから呼び出されたサービスバインディングは、対応するPreviewではなく、バインドされたWorkerの本番デプロイを依然として呼び出すこと、PreviewはQueuesにメッセージを送信できるがまだ消費はできないこと、永続的なステージングやQA環境向けの長期間稼働するPreviewは、プライベートベータのフィードバックに基づいてまだ範囲を検討中であることです。Worker PreviewsはWorkersプラットフォーム全体で現在利用可能で、以前のVersion URLは、アップロードされた特定のバージョンを指すための、より狭い別個の仕組みとして維持されています。
出典をたどる
出典
- Introducing Worker Previews: isolated preview environments for every change your agent makes The Cloudflare Blog · blog.cloudflare.com ·