Cloudflare ra mắt Worker Previews: Môi trường thử nghiệm biệt lập cho mọi thay đổi của AI Agent

Không gì tệ hơn việc thử nghiệm một thay đổi hoạt động tốt trong môi trường staging, nhưng khi đưa lên production thì lại xảy ra lỗi. Đó là lý do chúng tôi muốn cung cấp cho bạn một môi trường gần giống với production nhất có thể — để bạn có thể kiểm thử các thay đổi của mình một cách khắt khe và đảm bảo chúng hoạt động chính xác như mong đợi.

Các Agent đang giúp chúng ta đẩy nhiều dòng code hơn bao giờ hết, và những thay đổi lớn hơn đồng nghĩa với việc cần phải kiểm thử nhiều hơn trước khi phát hành. Lý tưởng nhất là việc kiểm thử này được thực hiện theo cách không làm chậm các Agent, mà ngược lại còn cung cấp cho chúng các công cụ để đảm nhận nhiều phần hơn trong vòng đời phát triển.

Đó là lý do hôm nay chúng tôi ra mắt Worker Previews. Mỗi nhánh Git sẽ có một không gian chạy thử nghiệm giống hệt production, với mã nguồn, cấu hình, URL, khả năng quan sát (observability) và trạng thái (state) riêng biệt.

Vì vậy, giờ đây, đối với mỗi thay đổi trong codebase của mình, bạn có thể:

Kết quả là một vòng lặp phản hồi tiền sản xuất (pre-production feedback loop) cho mọi nhánh. Đẩy thay đổi của bạn lên một nhánh, kiểm tra hành vi, kiểm tra hiệu năng — trước khi bạn merge vào production.

Điều này cho phép thiết lập một Vòng đời Phát triển Agent (Agent Development Lifecycle - ADLC), nơi mỗi thay đổi đều mang tính nguyên tử (atomic), có thể triển khai độc lập, có thể quan sát và có thể sửa đổi. Nó cũng cung cấp cho các Agent và con người bằng chứng cần thiết để tự cải thiện: phát hiện lỗi, đẩy bản sửa lỗi và xác minh lần triển khai tiếp theo trước khi nó được đưa lên production.

Mỗi nhánh Git có môi trường riêng

Khi bạn bắt đầu làm việc trên một tính năng mới, việc đầu tiên bạn làm là tạo một nhánh (branch) từ nhánh main. Bạn nhận được một bản sao code của riêng mình và thực hiện các thay đổi mà không ảnh hưởng đến bất kỳ thứ gì trên production.

Worker Previews mở rộng mô hình đó ra ngoài phạm vi code. Mỗi nhánh có một môi trường và URL cô lập riêng. Bạn có thể chạy hàng trăm bản Preview cùng lúc — mỗi bản hoạt động độc lập mà không ảnh hưởng đến các Preview khác hoặc production.

Production và mỗi bản Preview đều có cấu hình riêng — được phục vụ trên URL riêng của chúng.

Khi bạn chạy lệnh npx wrangler preview, nhánh đó sẽ nhận được một bản sao cấu hình Previews mà bạn đã định nghĩa, chạy trên URL riêng — tất cả đều nằm dưới cùng một Worker.

Trong bảng điều khiển (dashboard), tính năng này hoạt động giống như việc chuyển đổi giữa các nhánh. Nhấp vào đường dẫn (breadcrumb) bên cạnh tên Worker của bạn (mặc định là Production) để xem tất cả các Preview:

Bảng điều khiển đưa mọi môi trường vào một chế độ xem duy nhất. Production nằm cạnh bao nhiêu Preview tùy thích, vì vậy các cộng tác viên có thể làm việc trên các thay đổi riêng biệt mà không cần tranh giành một trang staging dùng chung. Không giống như các môi trường Wrangler, nơi mỗi môi trường yêu cầu triển khai và quản lý một Worker riêng biệt, Previews giữ sự cô lập đó trong một chế độ xem bảng điều khiển duy nhất.

Mỗi Preview chạy như một phiên bản thực của Worker. Một số thay đổi chỉ có thể được xác thực tại thời điểm chạy (runtime): một API endpoint phải xử lý một yêu cầu thực và trả về phản hồi đúng. Những thay đổi mang tính chủ quan hơn, như cập nhật giao diện (UI), bước onboarding mới hoặc trạng thái lỗi khác, cần được trải nghiệm trong ngữ cảnh thực tế trước khi chúng đến được production.

Mỗi Preview có trạng thái cô lập và bền vững riêng, với Durable Objects và Containers

Để sự cô lập mở rộng ra toàn bộ ứng dụng của bạn, các tài nguyên có trạng thái (stateful resources) cần được xử lý đặc biệt. Lý do là vì Durable Objects chạy trên mô hình singleton. Một instance chịu trách nhiệm cho một ID đối tượng nhất định và instance đó sở hữu bộ lưu trữ của nó.

Nếu một Preview chia sẻ cùng namespace Durable Objects (DO) với production, bạn sẽ không chỉ đọc dữ liệu cũ — mà còn có thể sửa đổi chính instance đang phục vụ lưu lượng truy cập thực tế trong thời gian thực (rất nguy hiểm!).

Đó là lý do tại sao mỗi khi bạn chạy npx wrangler preview, Cloudflare sẽ tự động tạo một namespace Durable Object và ứng dụng Container mới cho Preview đó — để một quá trình di chuyển (migration) thất bại hoặc thay đổi lược đồ (schema) lỗi chỉ nằm gọn trong nhánh đó mà thôi.

Tất cả những gì bạn cần làm là export class, thêm migration của nó và truy cập thông qua ctx.exports:

Trong production, ctx.exports.Counter phân giải đến namespace production, trong khi trong Preview, nó phân giải đến namespace của Preview đó.

Giờ đây, bạn có cả một sân chơi để thử nghiệm. Hãy lấy Sandboxes làm ví dụ, nơi việc cải thiện thời gian khởi động dù chỉ vài mili giây cũng có thể quyết định sự thành bại của trải nghiệm người dùng. Nếu bạn đang cố gắng cải thiện hiệu năng cold-start, bạn có thể chạy các cấu hình khác nhau trên các nhánh cùng lúc, so sánh hiệu năng cold và warm cạnh nhau, và tìm ra thiết lập tốt nhất nhanh hơn.

Kiểm tra, quan sát và sửa đổi từng Preview (hoặc để Agent của bạn làm việc đó)

Giờ đây, khi mỗi nhánh chạy trên URL riêng trong một môi trường cô lập với trạng thái riêng, bạn có thể tham gia vào vòng lặp phản hồi và bắt đầu kiểm thử khắt khe mọi thay đổi trước khi nó đến được production.

Bạn có thể gửi lưu lượng truy cập đến URL Preview theo cách thông thường — từ terminal, từ CI, từ một Agent hoặc bằng cách tự nhấp chuột trải nghiệm. Khi lưu lượng truy cập bắt đầu, mọi công cụ Workers Observability mà bạn đã quen thuộc đều khả dụng, được giới hạn cho từng Preview riêng lẻ.

Khi mỗi yêu cầu gửi đến Preview, Workers Observability sẽ theo dõi toàn bộ vòng đời của nó dưới dạng thác nước (waterfall), bao gồm các lệnh gọi fetch, các thao tác binding và các lệnh gọi handler. Vì vậy, khi có lỗi xảy ra, bạn có thể theo dõi chính xác những gì đã xảy ra mà không cần phải lọc qua lưu lượng truy cập production hoặc các tín hiệu từ những thay đổi khác.

Khả năng quan sát (Observability) cho các Preview trông giống hệt như những gì bạn đã quen dùng cho các Worker production. Chọn Preview của bạn từ breadcrumb và mở tab Observability để xem các sự kiện, lỗi và dấu vết (traces):

Để cung cấp cho các Agent quyền kiểm soát nhiều hơn nữa, bạn có thể để chúng mở URL Preview trong một trình duyệt không giao diện (headless browser), nhấp qua quy trình đăng nhập từng bước và chụp ảnh màn hình hoặc ghi lại toàn bộ phiên làm việc dưới dạng các sự kiện DOM có thể phát lại – với Browser Run.

Dưới đây là ví dụ về việc một Agent mở Preview, ghi lại những gì đã hiển thị và kết nối một yêu cầu thất bại với các sự kiện Workers Observability từ cùng một lần chạy.

Người đánh giá có thể xem phiên làm việc trong thời gian thực với Live View hoặc can thiệp bằng Human in the Loop khi quá trình tự động hóa cần sự phán đoán của con người.

Nếu có lỗi xảy ra, bạn sẽ thấy nó từ cả hai góc độ: những gì đã hiển thị và những gì đã xảy ra tại thời điểm chạy.

Điều đó cung cấp cho Agent đủ bằng chứng để duy trì vòng lặp tiền sản xuất một cách tự chủ: triển khai, mở URL bằng Playwright MCP, nhấp chuột trải nghiệm, truy vấn các dấu vết thông qua máy chủ Workers Observability MCP, vá lỗi, triển khai lại và xác minh. Mọi lần lặp lại đều nằm trong phạm vi của nhánh đó.

Cấu hình cơ sở cho Previews một lần, sau đó ghi đè khi cần

Giống như việc bạn không muốn cấu hình lại code từ đầu mỗi khi tạo nhánh, bạn cũng không nên phải cấu hình lại môi trường của mình.

Bạn thiết lập cấu hình cơ sở cho Previews một lần, trong khối previews trong tệp cấu hình Wrangler của bạn.

Trong bảng điều khiển tại mục Worker → Settings, bạn sẽ thấy phần này được hiển thị dưới dạng Production và Previews Base. Khi cấu hình cơ sở đã được thiết lập, hãy chạy npx wrangler preview từ bất kỳ nhánh nào để tạo Preview. Nếu Worker của bạn được kết nối với Git thông qua Workers Builds, việc này sẽ tự động diễn ra khi bạn push code.

Bạn có thể ghi đè bất kỳ cài đặt nào chỉ cho một Preview — mà không ảnh hưởng đến production, cấu hình cơ sở hoặc các Preview khác.

URL Preview trên tên miền tùy chỉnh của riêng bạn, được bảo vệ bằng Cloudflare Access

Để đưa toàn bộ thiết lập đến gần hơn với production, các URL preview của bạn có thể được phục vụ từ tên miền tùy chỉnh của riêng bạn. Nếu ứng dụng của bạn chạy trên example.com, một Preview cho nhánh login có thể chạy tại feature-login.previews.example.com.

Nếu bạn muốn giữ các URL đó ở chế độ riêng tư, bạn có thể bảo vệ các Preview của mình bằng Cloudflare Access và yêu cầu khách truy cập phải đăng nhập trước.