AI viết code khiến CI thành nút thắt, Linear tái cấu trúc để theo kịp

AI viết code khiến CI thành nút thắt, Linear tái cấu trúc để theo kịp

Khi các tác nhân AI giúp lập trình viên tung code nhanh hơn gấp nhiều lần, khâu tích hợp liên tục (CI) bỗng trở thành điểm nghẽn thật sự. Linear đã dành gần một năm để tối ưu lại pipeline CI của mình, qua đó rút ngắn thời gian chờ của pull request và giảm mạnh chi phí hạ tầng.

Sơ đồ hiệu năng CI của Linear

Vì sao CI trở thành nút thắt?

Đầu năm nay, Mufeez Amjad của Linear mở công cụ nội bộ và thấy CTO Tuomas giao cho mình một issue mang tiêu đề ngắn gọn: "Chi phí CI đang quá cao". Kèm theo đó là yêu cầu thứ hai — làm CI nhanh hơn.

Vấn đề nằm ở chỗ các tác nhân AI đã giúp việc ship code nhanh hơn theo cấp số nhân, nhưng tốc độ xác thực những thay đổi đó lại không theo kịp. Mọi pull request vẫn phải đi qua CI, nên khi tốc độ phát triển tăng lên, CI nghiễm nhiên thành nút thắt: chi phí hạ tầng tăng vọt, còn lập trình viên lẫn AI phải chờ phản hồi lâu hơn.

Điều đáng chú ý là khối lượng công việc tăng rất nhanh. Bộ kiểm thử của Linear gần như tăng gấp bốn lần kể từ đầu năm, hiện đang bổ sung khoảng 2.000 bài test mỗi tuần. Dù vậy, họ vẫn đưa thời gian chờ pull request từ hơn 6 phút xuống còn hơn 5 phút — trong khi thời gian chạy máy cho mỗi bài test giảm gần một nửa.

Nếu không chủ động cải thiện CI từ sớm, bộ kiểm thử hiện tại sẽ mất khoảng 11 phút, gần gấp đôi so với mức lập trình viên phải chờ.

Bốn hướng tối ưu chính

Linear tiếp cận bài toán theo bốn hướng: nâng cấp hạ tầng và công cụ, tối ưu các job đóng vai trò cổng chặn, giảm thiết lập lặp lại và làm việc thực thi test hiệu quả hơn. Codebase của Linear chủ yếu là TypeScript, nhưng phần lớn kỹ thuật dưới đây có thể áp dụng cho nhiều ngôn ngữ và toolchain khác.

Nâng cấp hạ tầng và công cụ

Một số cải thiện đầu tiên gần như không cần tối ưu gì phức tạp. Linear chuyển khối lượng công việc khỏi GitHub Actions sang các runner bên thứ ba có CPU nhanh hơn, lưu trữ hiệu năng cao hơn và hạ tầng cache tốt hơn. So sánh hai ngày trước và sau khi chuyển, các job chạy nhanh hơn trung bình 34%, có workload như tsc giảm tới 52%.

Song song đó, việc hiện đại hóa toolchain cũng mang lại kết quả. Chuyển sang tsgo — trình biên dịch TypeScript gốc — giúp trung vị theo tuần của bước kiểm tra tsc giảm 73%, đủ để loại bỏ hẳn kiểm tra kiểu (typecheck) khỏi vị trí nút thắt.

Với lint, Linear vốn có vài rule tùy chỉnh phụ thuộc vào thông tin kiểu của TypeScript, buộc mỗi lần lint phải dựng toàn bộ đồ thị kiểu trước khi đánh giá. Họ viết lại các rule này để dùng phân tích tĩnh trên cây cú pháp trừu tượng, nhận diện cấu trúc giống hàm và mẫu guard mà không cần thông tin kiểu. Nhờ đó ESLint loại bỏ hẳn TypeScript, thời gian lint API giảm 68%, lint toàn kho giảm 55%, kèm mức tiêu thụ bộ nhớ thấp hơn đáng kể.

Giảm thiết lập lặp lại

Sau khi hạ tầng và từng bước kiểm tra chạy nhanh hơn, Linear nhìn CI như một hệ thống tổng thể. Chi phí thiết lập lặp lại ở mọi job — khởi động runner, cài package, chuẩn bị dependency build — khiến một job chỉ làm vài giây hữu ích lại ngốn cả phút tài nguyên.

• Cài sẵn dependency dùng chung trong image CI: mỗi shard test API từng mất 7-8 giây cài Postgres client bằng apt. Đưa nó vào image nền CI giúp mỗi shard khởi động trong môi trường sẵn sàng chạy.
• Chỉ cài dependency mà job cần: codebase Linear là monorepo quản lý bằng pnpm workspace, nhưng workflow test API lại cài toàn bộ workspace. Giới hạn vào package API giúp pnpm install từ 44-73 giây xuống 16-18 giây.
• Không cache khi build lại còn nhanh hơn: thử nghiệm cho thấy cache node_modules chậm hơn. Ngay cả khi cache hit cũng mất khoảng 28 giây để khôi phục, so với khoảng 7,5 giây cho một lần cài đã lọc.

Tổng cộng, ba thay đổi này giảm thời gian thiết lập mỗi shard khoảng 44%, từ 110-140 giây xuống 67-73 giây.

Tối ưu các job cổng chặn

Khi nhìn CI như một hệ thống, Linear chú ý tới những job nhỏ nằm trước mọi thứ khác. Mỗi lần chạy đều bắt đầu bằng việc kiểm tra pull request đã chạm vào đường dẫn nào và các test tương ứng đã từng đạt chưa. Vì được đặt ở cấp job để phần việc bị bỏ qua không chiếm runner, chúng lại nằm ngay trên đường tới hạn — tám shard test API không thể bắt đầu cho tới khi các kiểm tra này xong.

Linear giới hạn độ sâu fetch, đưa job cổng chậm nhất từ 94 giây xuống 20 giây, và loại bỏ hoàn toàn checkout ở những job không cần cây làm việc, giảm từ 27 giây xuống 7 giây. Thời gian trung vị của job phát hiện thay đổi giảm từ 26 xuống 8 giây, p90 từ 31 xuống 12 giây, còn lần chạy chậm nhất từ 138 xuống 37 giây.

Biểu đồ thời gian chạy của các shard test

Họ cũng thay actions/checkout bằng một composite action tự viết, có cơ chế thử lại với backoff và đặt GIT_HTTP_LOW_SPEED_LIMIT cùng GIT_HTTP_LOW_SPEED_TIME để kết nối bị treo sẽ tự hủy sau khoảng 30 giây thay vì treo vô hạn. Nguyên nhân là các runner bên thứ ba nằm ngoài mạng GitHub, phụ thuộc vào liên kết IP trực tiếp và thỉnh thoảng bị suy giảm.

Làm việc thực thi test hiệu quả hơn

Khi chi phí cố định của mỗi shard đã giảm, Linear có thể song song hóa bộ test API mạnh hơn. Đây là phần lớn nhất và được chạy thường xuyên nhất trong workflow, nên cải thiện ở đây tác động rất lớn tới thời gian merge.

Vitest phân chia công việc theo file chứ không theo thời lượng từng test, khiến vài file test quá lớn có thể chi phối cả một shard. Linear tách các file lớn thành nhiều file nhỏ và tập trung hơn, rồi thử nhiều cấu hình shard khác nhau. Từ bốn shard lên tám shard giúp job tới hạn nhanh hơn khoảng 19% và rẻ hơn 19%.

Bước đột phá lớn nhất là cho phép chia sẻ trạng thái module với quy tắc cách ly nghiêm ngặt. Vitest thường cách ly mọi file test, nghĩa là mỗi shard phải dựng lại đồ thị entity, GraphQL và decorator. Linear đưa vào một dự án Vitest tùy chọn với isolate: false, cho phép các file an toàn dùng chung module registry trong mỗi worker. Kết quả: shard chậm nhất giảm từ khoảng 300-379 giây xuống còn khoảng 195 giây, tổng thời gian runner của các shard API giảm từ khoảng 32,8 phút xuống 22 phút mỗi lần chạy.

Đây cũng là tối ưu có rủi ro về tính đúng đắn cao nhất. Linear đánh dấu điều kiện tham gia rõ ràng bằng comment opt-in trên từng file, bổ sung teardown cần thiết cho trạng thái dùng chung và giữ nguyên những file dùng fake timer hoặc trạng thái chia sẻ phức tạp trong dự án cách ly. Vì AI hiện viết phần lớn test, họ còn cập nhật kỹ năng của tác nhân để test sinh ra mặc định tuân theo ràng buộc này.

Bài học cho các đội ngũ Việt Nam

Câu chuyện của Linear có ý nghĩa trực tiếp với các đội phát triển phần mềm ở Việt Nam đang tăng tốc nhờ AI. Khi AI viết code nhanh hơn, chi phí hạ tầng CI và hóa đơn runner có thể tăng vọt mà nhiều đội không lường trước. Vài nguyên tắc có thể áp dụng ngay:

• Đo lường trước khi tối ưu: biết rõ job nào nằm trên đường tới hạn và tốn bao nhiêu runner-minute.
• Giảm chi phí cố định trước khi tăng song song: thêm shard chỉ có lợi khi thời gian thiết lập mỗi shard đã đủ thấp, nếu không sẽ đốt thêm tài nguyên mà không nhanh hơn.
• Coi AI là một phần của quy trình CI: vì AI sinh phần lớn test, quy tắc về hiệu năng và cách ly cần được đưa thẳng vào hướng dẫn cho tác nhân.

Kiến trúc pipeline CI được tối ưu

Công việc này không có điểm dừng. Linear khẳng định codebase sẽ tiếp tục lớn lên, và giữ CI luôn nhanh là nỗ lực thường trực. Nhưng với những gì họ đã làm, bài học rõ ràng: khi AI đẩy nhanh khâu viết code, chính khâu kiểm thử mới là nơi quyết định tốc độ thật của cả đội.