Making "never break the build" scale

Jane Street · 2014 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Bối cảnh

"Not Rocket Science Rule" (Graydon Hoare): repo chính không bao giờ có bản fail test. Cách làm ngây thơ là build-bot nhận từng pull request, merge với tip, build và chạy toàn bộ test, đạt thì mới thành tip mới. Jane Street tự viết build-bot cho việc này.
Cách này tuần tự: mỗi request mất m phút thì n request mất ít nhất m × n phút. Ở Jane Street (2014) có nhiều người liên tục đẩy thay đổi nhỏ, một số bị từ chối phải chạy lại, và build cả cây mất từ hai giờ trở lên; có thay đổi phải chờ 24 giờ mới qua được build-bot.

Đầu cơ đơn giản: chạy song song nhiều request; cái đầu tiên đạt thành tip mới, cái fail trả về chủ. Chỉ có ích khi tỉ lệ fail cao, vì cái đạt thứ hai vẫn phải merge và test lại với tip mới.
Đầu cơ gộp: gộp nhiều request thành một lần build; fail thì phải tách ra chạy từng cái để chắc vẫn tiến được.
Build nhanh hơn: tự viết build system Jenga, làm incremental build đáng tin để thay đổi nhỏ được kiểm rất nhanh.
Ít request hơn: đổi quy trình code review từ "tích hợp vào nhánh chính trước, review sau" sang "giữ feature ở nhánh riêng tới khi review xong". Kết quả phụ là tích hợp theo lô: repo chính từ hàng trăm request/tuần xuống 30–40.
Phân cấp: công cụ review Iron hỗ trợ hierarchical features, tổ chức quy trình release thành cây (giống mô hình "lieutenant" của Linux kernel); các nhánh dưới gộp feature lại rồi qua build-bot trung tâm một lần.

Theo tác giả, các mẹo trên chỉ đổi hằng số chứ không đổi tiệm cận; nếu đội tăng 10 hay 100 lần thì cách tuần tự sẽ vỡ. Phân cấp giảm số việc mỗi tầng phải xử lý.

Test trước khi tích hợp, không phải sau, để không ai phải đi tìm "ai làm vỡ build".
Hàng đợi merge tuần tự có throughput giới hạn bởi thời gian build; đầu cơ, gộp lô và build incremental là các đòn bẩy, nhưng ở quy mô lớn phải chia cây release.
Quy trình review ảnh hưởng trực tiếp tới tải CI.