Vercel CI beta: chạy CI cho Turborepo bằng một dòng cấu hình

Coding agent đang tạo pull request với tần suất chưa từng thấy, và mỗi PR lại phải chờ CI xong mới được review hay merge. Phần lớn hệ thống CI hiện nay chạy toàn bộ workflow mỗi lần push, kể cả khi thay đổi chỉ là một dòng. Vercel vừa công bố Vercel CI ở dạng Beta (bài đăng ngày 28/10/2026 trên Vercel Blog, tác giả Anthony Shew), với hướng tiếp cận ngược lại: chỉ chạy những task thực sự bị ảnh hưởng và chỉ cấp đúng lượng compute mà các kiểm tra đó cần.

Có gì mới

Điểm cốt lõi của Vercel CI là nó đọc turbo.json để hiểu các task trong repo và quan hệ phụ thuộc giữa chúng. Nếu dự án đã dùng Turborepo thì gần như không phải viết thêm cấu hình CI riêng; nếu chưa, chỉ cần thêm file turbo.json và package turbo — theo Vercel, cách này dùng được cả với repo chỉ có một package.

Để bắt đầu, chỉ cần gắn tag cho các task muốn Vercel CI chạy:

{
  "tasks": {
    "lint": {
      "tags": ["ci"]
    }
  }
}

Theo bài gốc, "tags": ["ci"] là đủ để khởi động. Không có workflow YAML phải bảo trì, không có chuyện cấu hình CI lệch dần so với turbo.json, và Remote Cache được bật mặc định.

Cơ chế chạy khá rõ ràng: khi người dùng hoặc agent push code, Vercel CI xác định task nào cần chạy dựa trên thay đổi. Task có input không đổi sẽ lấy kết quả từ cache. Các task còn lại mỗi cái chạy trên một máy riêng, dùng Hive — lớp compute của Vercel — và bắt đầu ngay khi các phụ thuộc của nó hoàn tất.

Ảnh: Vercel Blog

Vercel cho biết kể từ khi chuyển sang Vercel CI cho chính các repo của mình, thời gian từ git push đến trạng thái "CI passed" nhanh hơn 2–6 lần so với trước. Con số này là trải nghiệm nội bộ của Vercel, không phải benchmark độc lập trên repo bên ngoài.

Trải nghiệm vận hành: xem, tìm lỗi, chặn merge

Một điểm đáng chú ý với người làm frontend là cách Vercel CI xử lý phần "nhìn vào CI". Sau khi thiết lập, có thể theo dõi và kiểm tra CI qua dashboard Vercel, Vercel CLI hoặc Vercel MCP. Khi có lỗi, đi thẳng tới task fail, xem task nào đang bị chặn phía sau nó, mở log, hoặc tìm trên các lần chạy gần đây xem một test có flaky suốt cả tuần hay không.

CLI cung cấp vài lệnh đáng nhớ:

vc ci ls                          # Liệt kê các lần chạy CI của repo
vc ci inspect <run>               # Liệt kê task trong một lần chạy
vc ci logs <run>                  # Lấy log của tất cả task
vc ci logs <run> --task web#test --level=error  # stderr của một task cụ thể
vc ci grep "WARNING"              # Tìm chuỗi trên log các lần chạy

Với quy trình review, Vercel CI đăng một check lên pull request trên GitHub, nên các branch protection rule hiện có vẫn chặn merge khi fail — tức là không phải thay đổi thói quen bảo vệ nhánh đang dùng.

Vercel cũng đưa ra cách thiết lập bằng prompt cho coding agent: chạy npx skills use vercel/ci@setup và làm theo hướng dẫn của skill để chọn task ban đầu, cấu hình Vercel CI và mở pull request.

Vì sao đáng quan tâm với đội frontend và web ở Việt Nam

Với các đội frontend dùng Next.js hoặc monorepo Turborepo, chi phí thời gian chờ CI thường bị đánh giá thấp. Một repo có vài chục package, mỗi PR chạy lint, typecheck, unit test, build cho toàn bộ workspace — nhân với số PR mỗi ngày, đây là khoảng chết rất thật. Khi đội bắt đầu dùng coding agent để mở PR hàng loạt, khoảng chết đó nhân lên nhanh hơn nữa.

Hướng "chỉ chạy task bị ảnh hưởng" không mới về ý tưởng — Turborepo và nhiều công cụ monorepo đã làm việc này ở mức local — nhưng việc đưa nó thành mặc định của CI, không cần viết pipeline riêng, là điểm khác biệt đáng chú ý. Đội nào đã có turbo.json gần như được dùng miễn phí phần logic phát hiện thay đổi; đội chưa dùng Turborepo thì phải cân nhắc thêm một lớp công cụ vào repo.

Một lợi ích phụ với đội nhỏ: không phải bảo trì file workflow YAML dài, vốn là nguồn lỗi âm thầm khi cấu hình CI trôi lệch khỏi cấu hình build thực tế. Việc Remote Cache bật mặc định cũng giúp các lần chạy lặp lại (rebase, push lại sau khi sửa một file) không phải build lại từ đầu.

Ai nên thử, và thử thế nào

Phù hợp nhất là các đội đã hoặc đang cân nhắc Turborepo, đặc biệt khi đã host frontend trên Vercel — vì CI, dashboard và compute nằm chung một chỗ. Đội đang chạy GitHub Actions với pipeline phức tạp, nhiều bước không phải task Node (ví dụ deploy hạ tầng, chạy migration, kiểm thử trên thiết bị thật) nên đọc kỹ tài liệu trước khi chuyển, vì mô hình của Vercel CI xoay quanh task trong turbo.json.

Các bước thử nhanh:

1. Thêm turbo.json và package turbo nếu repo chưa có.
2. Gắn "tags": ["ci"] cho các task muốn Vercel CI chạy (lint, test, build…).
3. Cấu hình Vercel CI theo tài liệu, hoặc prompt agent bằng npx skills use vercel/ci@setup.
4. Theo dõi lần chạy đầu bằng vc ci ls và vc ci inspect <run>.
5. Kiểm tra branch protection rule vẫn chặn merge khi check fail.

Lưu ý và hạn chế

Đây là bản Beta, và Vercel nêu rõ một số thứ còn đang phát triển trước khi general availability: khả năng quan sát nâng cao (advanced observability), một lệnh vc ci cho phép chạy phân tán trước khi push code, và chọn test ở mức chi tiết hơn. Nếu quy trình của đội phụ thuộc vào việc chạy test trước khi push hoặc cần lọc test rất mịn, nên chờ các tính năng này.

Con số "nhanh hơn 2–6 lần" là số liệu Vercel tự công bố từ repo nội bộ và private beta, chưa có kiểm chứng độc lập; mức cải thiện thực tế sẽ phụ thuộc cấu trúc repo và mức độ thay đổi giữa các lần push. Bài gốc cũng cho biết Vercel CI đã hoàn thành gần 8 triệu task trên repo của Vercel và trong private beta tính đến thời điểm đăng bài. Ngoài ra, đây là thông báo sản phẩm trên blog của chính Vercel — đơn vị bán dịch vụ liên quan trực tiếp — nên các so sánh với hệ thống CI khác cần được đọc trong bối cảnh đó.

Kết

Vercel CI không cố thay thế mọi hệ thống CI phức tạp, mà nhắm vào một điểm đau cụ thể: CI chạy thừa khi thay đổi nhỏ, và số lần push tăng vọt vì coding agent. Với đội đã dùng Turborepo, chi phí thử nghiệm thấp — thêm tag vào turbo.json là xong. Với đội chưa dùng, đây có thể là lý do để xem lại cấu trúc monorepo trước khi nghĩ tới việc đổi CI.

Nguồn: Vercel Blog