Cloudflare ra mắt CI SDK: Chạy pipeline CI/CD trực tiếp trên hạ tầng Cloudflare

Chúng ta đang tiến tới một thế giới nơi bạn có thể lưu trữ, xây dựng, kiểm thử và triển khai mã nguồn của mình hoàn toàn trên Cloudflare. Chúng tôi đã xây dựng thành phần đầu tiên với Artifacts, một hệ thống lưu trữ mã nguồn có phiên bản, có khả năng mở rộng lên tới hàng triệu kho lưu trữ (repo).

Chúng tôi đã kết nối các bước lưu trữ, xây dựng và triển khai lại với nhau bằng CI SDK, được xây dựng trên Cloudflare Workflows, để bạn có thể chạy quy trình tích hợp liên tục (CI) của mình ngay trên Cloudflare. Bạn có thể gửi các sự kiện đẩy artifact trực tiếp đến Workflow của mình, từ đó kích hoạt một phiên bản thực thi — về cơ bản là một CI job — thông qua một trường sự kiện mới trong tệp cấu hình wrangler của bạn.

Sau đó, trực tiếp từ Workflow với @cloudflare/ci đã được cài đặt, bạn có thể:

Ngày nay, ai cũng đang xây dựng một nền tảng, cho dù đó là một nền tảng "vibe coding" nội bộ hay là phần mở rộng của sản phẩm hướng tới khách hàng thông qua việc tùy chỉnh bằng mã nguồn. Các nền tảng hiện đang sử dụng hàng triệu repo trên Artifacts để lưu trữ mã nguồn của họ, mã nguồn của khách hàng và quản lý phiên bản trên cả hai. Tuy nhiên, mỗi đội ngũ đều có những nhu cầu riêng cho quy trình tích hợp và triển khai liên tục. Đối với các nền tảng, họ có thể muốn xác định một CI job cho mã nguồn của chính họ khác biệt so với mã nguồn của khách hàng.

Nhiều khách hàng cuối xây dựng trên các nền tảng này không muốn gặp thêm rắc rối khi phải quản lý quy trình tích hợp và triển khai liên tục (CI/CD) của riêng họ. Thay vào đó, nền tảng có thể quản lý quy trình xây dựng thay cho khách hàng: viết quy trình CI/CD một lần và chia sẻ nó trên tất cả các ứng dụng mà khách hàng của họ đang xây dựng. Một số khách hàng của nền tảng có thể muốn tự xác định CI của riêng họ; nếu vậy, họ có thể viết Workflow riêng và chạy các CI job tùy chỉnh chỉ trên repo của họ, được hỗ trợ bởi các dynamic workflows. Điểm hay ở đây là bạn không cần phải lựa chọn: cả CI do nền tảng quản lý và CI tùy chỉnh đều có thể chạy cùng lúc, trong cùng một namespace.

Một quy trình CI/CD chỉ đơn giản là một Workflow

Trước hôm nay, chúng tôi đã có tất cả các mảnh ghép để cho phép các nền tảng kết nối quy trình CI/CD của họ trên Cloudflare. Giờ đây, chúng tôi mang đến trải nghiệm lập trình viên tốt hơn để làm cho mọi thứ trở nên đơn giản.

Một quy trình CI/CD — thường được điều phối bằng GitHub Actions — là một chuỗi các bước chạy theo thứ tự cụ thể, trong đó nếu bất kỳ bước nào thất bại, bạn sẽ dừng quy trình và báo lỗi. Về bản chất, một quy trình CI/CD chỉ là một Workflow. Khi được định nghĩa bằng tệp YAML, CI/CD có thể nhanh chóng trở nên phức tạp do các ràng buộc thường dẫn đến tình trạng "YAML fatigue" (mệt mỏi vì YAML). Nhưng mỗi bước trong quy trình CI/CD có thể được chuyển đổi đơn giản thành một bước Workflow step.do. Thay vì YAML, bạn có thể định nghĩa quy trình CI/CD của mình bằng Typescript để tùy chỉnh và cấu hình linh hoạt hơn.

Chúng tôi đang ra mắt các công cụ mới trong CI SDK cho phép bạn chạy từng bước trong quy trình CI của mình (ví dụ: build, lint và typecheck) trong một môi trường an toàn, biệt lập, được xây dựng trực tiếp trên nền tảng dành cho nhà phát triển của Cloudflare thông qua Workflows và Sandbox SDK. Thêm vào đó, giờ đây bạn có thể khởi chạy một CI job ngay khi có sự kiện push thay vì phải cấu hình đăng ký sự kiện, hàng đợi (queue) và trình xử lý hàng đợi.

Trước đây, bạn phải gọi trực tiếp Sandbox API và tự quản lý trạng thái qua các bước khác nhau trong quy trình CI. SDK mới cho phép bạn chạy từng lệnh trong sandbox trong một bước Workflow riêng biệt, cung cấp các tính năng thử lại (retries) và hết thời gian chờ (timeouts) được tích hợp sẵn trong Cloudflare Workflows.

Bạn cũng có thể tăng tốc quy trình CI bằng cách lưu kết quả các bước vào bộ nhớ đệm (caching) — ví dụ như bước cài đặt — để không cần phải cài đặt lại cho các thao tác tiếp theo. Việc lưu bộ nhớ đệm các phụ thuộc (dependency caching) giúp giảm độ trễ của quy trình CI/CD vì mọi bước CI sẽ không cần phải chạy lại quá trình cài đặt.

Để định nghĩa CI job của bạn, tất cả những gì bạn cần làm là:

Việc tự viết quy trình CI trong một Workflow cho phép bạn tùy chỉnh nhiều nhất có thể. Ví dụ: bạn có thể gọi một tác nhân (agent) từ Workflow CI của mình để cung cấp cho các CI job khả năng tự phục hồi: nếu một bước trong quá trình build bị lỗi, tác nhân có thể tự động sửa lỗi đó và đẩy một commit để bạn phê duyệt.

Hãy thử ví dụ về Workflow CI tự phục hồi với Project Think: https://github.com/cloudflare/ci/blob/main/examples/self-healing

Viết Workflow CI của riêng bạn

Để viết Workflow CI của riêng bạn, hãy bắt đầu với import { CIWorkflow } from @cloudflare/ci. Bắt đầu với một bước cài đặt:

Sau đó, định nghĩa các bước cho việc build và kiểm tra, mỗi bước được thực thi trong môi trường sandbox an toàn, biệt lập của riêng nó.

Theo mặc định, mỗi bước trong Workflow bắt đầu độc lập, nghĩa là các bước sẽ thực thi đồng thời trừ khi được chỉ định khác. Chạy song song từng bước giúp giảm độ trễ cho quá trình chạy CI của bạn. Để đảm bảo tất cả các bước kiểm tra hoàn tất trước khi quy trình CI tiếp tục (ví dụ: hoàn thành build, lint, test và typecheck trước khi bước triển khai bắt đầu), hãy bao bọc chúng trong Promise.all:

Bây giờ, để thực sự kích hoạt Workflow CI của bạn, hãy thêm trường events vào cấu hình wrangler của Worker, cùng với các ràng buộc (bindings) Workflow và Artifact của bạn. Trường events là một trường mới được hỗ trợ trong trường triggers của bạn.

Bạn đã có thể đăng ký Artifacts thông qua Cloudflare Queues thông qua các đăng ký sự kiện và khởi chạy quy trình build mỗi khi có sự kiện push. Nhưng điều đó đòi hỏi phải thiết lập đăng ký sự kiện, Queue, consumer và trình xử lý hàng đợi. Giờ đây, bạn có thể nhắm mục tiêu một Workflow với sự kiện đó — mỗi khi sự kiện đó kích hoạt, nó sẽ khởi chạy một phiên bản của Workflow.

Chỉ định Workflow CI làm mục tiêu cho trình kích hoạt đẩy artifact của bạn để tự động kích hoạt một phiên bản Workflow trên mỗi sự kiện cf.artifacts.repo.pushed. Mỗi lần chạy CI sẽ xuất hiện dưới dạng một phiên bản Workflow để bạn có thể xem quá trình thực thi từng bước và khả năng quan sát (observability) trực tiếp trong bảng điều khiển Workflows. Đây là một tích hợp ưu tiên Artifacts; sắp tới, các kiểu dữ liệu (types) sẽ hỗ trợ các sự kiện từ các nguồn trên toàn bộ tài khoản Cloudflare của bạn để cho phép tiêu thụ theo lập trình trên toàn bộ bộ sản phẩm.

Nếu bạn muốn chạy Workflow CI trên mọi repo trong namespace của mình — ví dụ: nếu bạn là một nền tảng chạy CI trên tất cả các kho lưu trữ của khách hàng — hãy bỏ qua repoName và chỉ chỉ định namespace trong filter.

Để cấu hình đầy đủ Workflow CI của bạn, hãy thêm các ràng buộc vào từng phần của cơ sở hạ tầng cung cấp năng lượng cho quy trình: các ràng buộc artifacts, workflows, containers và durable_objects (+ cấu hình exports) (để truy cập sandbox của bạn), cộng với ràng buộc r2 nếu bạn đang sử dụng bộ nhớ đệm. Ràng buộc R2 là bắt buộc vì bản snapshot của sandbox bước cài đặt của bạn được lưu trữ trong một bucket.

Các lần chạy CI tự phục hồi

Để cho phép CI job của bạn tự phục hồi, bạn sẽ cần hai thành phần: LLM và bộ công cụ tác nhân (agent harness) của nó. Trong ví dụ trên, chúng tôi đã bao gồm một tác nhân Think sử dụng Workers AI để bắt lỗi trong quy trình của bạn và thực hiện các bản sửa lỗi thay cho bạn. CI job của bạn có thể được chạy và chạy lại từ xa — không cần phải ngồi canh chừng với máy tính xách tay mở hoặc kiểm tra lại sau mỗi vài phút. Thay vào đó, Cloudflare xử lý nó trên đám mây, chạy tác nhân phục hồi của bạn cùng với các bước CI trong một container. Thay vì phải trông chừng CI job, thực hiện sửa lỗi thủ công và chạy lại quy trình, bạn chỉ cần merge commit sau khi tác nhân của bạn đã thực hiện xong bản sửa lỗi.

Để thiết lập một tác nhân tự phục hồi quy trình CI của bạn, hãy thêm ràng buộc Durable Object cho tác nhân Think của bạn:

Tạo tác nhân Think của bạn — Healer — bằng cách mở rộng lớp HealingAgent, bao gồm phương thức heal để bạn gọi khi có lỗi. Truyền mô hình bạn muốn sử dụng:

Sau đó, bao bọc các bước của bạn trong khối try/catch nơi lỗi sẽ kích hoạt tác nhân phục hồi:

Ví dụ này minh họa một quy trình CI tự phục hồi, nhưng thực tế, mô hình "Bring Your Own Workflow" (BYO-W) cho phép bạn tùy chỉnh CI job theo bất kỳ cách nào bạn muốn. Đây có thể là nơi để thêm các quy tắc bảo mật, bộ lọc hoặc các bước CI có điều kiện. Sử dụng mô hình BYO-W, các nền tảng có thể cấu hình quy trình CI/CD của họ trên các đội ngũ, khách hàng hoặc ứng dụng khác nhau tùy theo từng trường hợp sử dụng cụ thể.

Lợi ích của việc sử dụng Workflow

Bằng cách chạy quy trình CI của bạn trên Cloudflare Workflow, bạn tự động kế thừa:

Tiếp theo là gì

Một quy trình CI/CD chỉ đơn giản là một Workflow — và với CI SDK, bạn có thể định nghĩa CI của mình trên mã nguồn của bạn và của khách hàng bằng Typescript đơn giản thay vì YAML thiếu linh hoạt. Xây dựng dựa trên các nguyên tắc của Cloudflare Workflows, bạn có thể định nghĩa bất kỳ logic nào bạn muốn, cho dù đó là một tác nhân phục hồi như ví dụ Think của chúng tôi, hay ghi các build artifact vào R2. Chạy CI trên Workflows giúp thu hẹp khoảng cách giữa lưu trữ (thông qua Artifacts), xây dựng và triển khai. Với tư cách là một nền tảng, điều này cho phép bạn dễ dàng quản lý từng bước trên mã nguồn của chính mình và thay mặt cho khách hàng của bạn.

Yêu cầu tham gia bản beta riêng tư của Artifacts và bắt đầu với hướng dẫn Workflows CI của chúng tôi. Nếu bạn có bất kỳ yêu cầu tính năng nào hoặc phát hiện lỗi, hãy chia sẻ phản hồi trực tiếp với đội ngũ Cloudflare bằng cách tham gia cộng đồng Cloudflare Developers trên Discord.

Những gì sắp tới: