Kỹ sư tuyến tính Mufeez Amjad đã xuất bản một tài khoản chi tiết về cách công ty làm lại quy trình tích hợp liên tục của mình sau khi các tác nhân mã hóa AI biến CI thành nút cổ chai tồi tệ nhất – cắt giảm thời gian chờ yêu cầu kéo từ hơn sáu phút xuống chỉ còn hơn năm trong khi các bộ thử nghiệm của nó tăng gần gấp bốn lần kể từ đầu năm.
Bài đăng được đăng trên blog kỹ thuật của Linear vào ngày 21 tháng 9, bắt đầu, như những điều này thường xảy ra, với một tấm vé ngắn gọn từ phía trên. Đầu năm nay, Amjad mở Linear và phát hiện ra rằng Tuomas, CTO của công ty, đã giao cho anh một vấn đề có tiêu đề "Chi phí CI cao" - và yêu cầu anh làm cho CI nhanh hơn khi anh đang làm việc đó. Để biết thêm bối cảnh về câu chuyện này, hãy xem thông tin liên tục về ngành AI của chúng tôi.
Khi Đại lý vượt quá mức xác thực
Vấn đề là mang tính cấu trúc, không phải ngẫu nhiên. Amjad viết: “Các đại lý đã làm cho việc gửi mã nhanh hơn theo cấp số nhân, nhưng việc xác thực những thay đổi đó không theo kịp tốc độ tương tự”. Mọi yêu cầu kéo vẫn phải đi qua CI, vì vậy khi quá trình phát triển tăng tốc, CI sẽ trở thành điểm nghẽn — làm tăng chi phí cơ sở hạ tầng và khiến các nhà phát triển cũng như đại lý của họ phải chờ đợi phản hồi lâu hơn.
Được tối ưu hóa tuyến tính cho hai chỉ số: thời gian PR chờ trên CI và thời gian chạy mà nó tiêu tốn. Kết quả sau nhiều tháng làm việc: mặc dù số bộ thử nghiệm gần như tăng gấp bốn lần kể từ tháng 1, thời gian chờ yêu cầu kéo đã giảm từ hơn sáu phút xuống chỉ còn hơn năm phút và thời gian chạy cho mỗi bài kiểm tra đã giảm gần một nửa.
Công việc nói chung được chia thành bốn loại: nâng cấp cơ sở hạ tầng và công cụ, tối ưu hóa các công việc hỗ trợ công việc khác, giảm việc thiết lập lặp lại và giúp việc thực hiện kiểm thử hiệu quả hơn. Cơ sở mã của Linear chủ yếu là TypeScript, nhưng nhiều tính năng tối ưu hóa được áp dụng trên nhiều ngôn ngữ và chuỗi công cụ.
Máy nhanh hơn và trình biên dịch gốc
Một số lợi ích sớm nhất hầu như không yêu cầu tối ưu hóa CI. Việc chuyển khối lượng công việc từ GitHub Actions sang các trình chạy của bên thứ ba có CPU nhanh hơn, bộ lưu trữ hiệu suất cao hơn và cơ sở hạ tầng bộ nhớ đệm tốt hơn đã mang lại hiệu quả ngay lập tức: trong một so sánh tương tự giữa hai ngày ở hai bên chuyển đổi, các công việc chạy nhanh hơn trung bình 34%, với một số khối lượng công việc như `tsc` giảm 52%.
Hiện đại hóa chuỗi công cụ đã mang lại chiến thắng. Chuyển sang `tsgo`, trình biên dịch TypeScript gốc, đã cắt giảm 73% mức trung bình hàng tuần của lần kiểm tra đánh máy - đủ lớn để loại bỏ hoàn toàn nút thắt cổ chai khỏi việc kiểm tra đánh máy.
Linting không có biểu đồ kiểu
Linting là một mục tiêu ban đầu khác. Một số quy tắc ESLint tùy chỉnh của Linear phụ thuộc vào thông tin loại TypeScript, điều này buộc mỗi lần chạy lint phải xây dựng biểu đồ loại đầy đủ trước khi đánh giá chúng — khiến việc tìm lỗi mã nguồn trở thành một trong những công việc CI tiêu tốn nhiều bộ nhớ nhất.
Nhóm đã viết lại các quy tắc để sử dụng phân tích tĩnh trên cây cú pháp trừu tượng, xác định các cấu trúc giống hàm và mẫu bảo vệ mà không có bất kỳ thông tin loại nào. Điều đó cho phép ESLint loại bỏ hoàn toàn TypeScript, giảm 68% thời gian tìm lỗi mã nguồn API và giảm 55% thời gian tìm lỗi mã nguồn toàn bộ kho lưu trữ, đồng thời giảm đáng kể mức sử dụng bộ nhớ. Nó cũng giúp dễ dàng di chuyển sang Oxlint sau này, giúp giảm hơn nữa số phút chạy CI dành cho linting.
Thu hẹp đường tới hạn
Với việc kiểm tra từng cá nhân nhanh hơn, Linear đã thu nhỏ và coi CI như một hệ thống. Điều đó đã thu hút sự chú ý đến các công việc nhỏ nằm trước mọi công việc khác - phát hiện thay đổi đường dẫn và bộ đệm kết quả kiểm tra kiểm tra cổng đó ở cấp độ công việc, nghĩa là không có phân đoạn kiểm tra API nào trong số tám phân đoạn kiểm tra API có thể bắt đầu cho đến khi chúng hoàn thành.
Các bản sửa lỗi rất chi tiết nhưng có tính bổ sung. Giới hạn độ sâu tìm nạp đã đưa cổng chậm nhất từ 94 giây xuống 20. Việc loại bỏ hoàn toàn thanh toán khỏi các công việc không bao giờ cần cây làm việc đã cắt giảm thời gian đó từ 27 giây xuống còn 7. Thanh toán thưa thớt, không có đốm màu với lịch sử hạn chế đã tiết kiệm thêm 11 giây lẻ cho các sự kiện đẩy và hợp nhất hàng đợi. Nhìn chung, thời lượng trung bình của công việc phát hiện thay đổi đã giảm từ 26 giây xuống 8, p90 từ 31 xuống 12 và thời gian chạy chậm nhất từ 138 giây xuống 37.
Độ tin cậy của quá trình thanh toán cũng cần được cải thiện: vì người chạy bên thứ ba ngồi bên ngoài mạng của GitHub và dựa vào liên kết IP trực tiếp, nên việc xuống cấp liên kết không liên tục đôi khi khiến quá trình tìm nạp bị đình trệ. Tuyến tính đã thay thế `hành động/kiểm tra` bằng hành động tổng hợp của chính nó sẽ thử lại với thời gian chờ, đặt `GIT_HTTP_LOW_SPEED_LIMIT` và `GIT_HTTP_LOW_SPEED_TIME` để kết nối bị đình trệ sẽ hủy sau khoảng 30 giây thay vì treo và sử dụng bộ đệm kiểm tra để giữ bản sao git liên tục trên đĩa dính.
Một cách khắc phục tinh tế đã loại bỏ thời gian xếp hàng hợp nhất lãng phí: các điểm đánh dấu bộ nhớ đệm được ghi như một phần của bước kiểm tra cuối cùng trước khi hợp nhất, do đó PR có thể nằm trong hàng đợi ngay cả sau khi các thử nghiệm của nó đã vượt qua. Việc chuyển nội dung ghi đó sang một công việc không kiểm soát đã tiết kiệm 42 giây so với đường dẫn hợp nhất cho mỗi yêu cầu kéo API và mục nhập hàng đợi hợp nhất. Cùng với nhau, những thay đổi này đã làm mất đi khoảng một phút các hoạt động kiểm tra bắt buộc đối với API PR về các lỗi bộ đệm trong khi giảm số lần khởi động trình chạy.
Ít lãng phí giây hơn cho mỗi công việc
Chi phí thiết lập tấn công danh mục cuối cùng được lặp lại trong mọi công việc. Mỗi phân đoạn kiểm tra API mất 7 đến 8 giây để cài đặt cùng một ứng dụng khách Postgres với apt trên mỗi lần chạy; di chuyển nó vào một hình ảnh cơ sở CI nhỏ cùng với Node có nghĩa là các phân đoạn có thể bắt đầu sẵn sàng chạy. Sau đó, nhóm đã thêm các tiêu đề bản dựng gốc vào hình ảnh sau khi phát hiện ra rằng việc tải chúng xuống trong quá trình thiết lập đôi khi có thể bị treo.
Tại sao nó lại gây được tiếng vang
Bài đăng đã gây ấn tượng mạnh với các nhà phát triển: nó đã xuất hiện trên trang nhất của Hacker News, thu hút khoảng 250 điểm và khoảng 280 bình luận trong vòng một ngày. Phản ứng này rất dễ giải thích - Kinh nghiệm của Linear cho thấy chi phí phát triển được hỗ trợ bởi AI mà hầu hết các tổ chức kỹ thuật hiện nay mới phải đối mặt. Các tổng đài viên tạo yêu cầu kéo trong vài phút vẫn chờ trên quy trình xác thực được thiết kế theo nhịp của con người và mỗi phút chờ đợi đó sẽ được nhân lên trên mọi tổng đài viên làm việc song song.
Bài học từ quá trình làm lại của Linear là nút thắt cổ chai có thể di chuyển được nhưng chỉ thông qua sự tích lũy vô ích của nhiều bản sửa lỗi nhỏ — trình chạy nhanh hơn, cách đánh máy rẻ hơn, quy tắc tìm lỗi mã nguồn ở cấp cú pháp, tìm nạp giới hạn, kiểm tra linh hoạt, hình ảnh dựng sẵn — thay vì bất kỳ viên đạn bạc nào.
---
Đi trước AINhận tin tức, phân tích và đột phá mới nhất về AI — tất cả ở cùng một nơi.
Đọc thêm tin tức về AI →
