How GitHub uses merge queue to ship hundreds of changes every day

GitHub · 2024 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài ngoài sheet. GitHub kể việc dùng chính tính năng sản phẩm của họ; số liệu tự đo.

Bối cảnh

GitHub deploy trước rồi mới merge. Năm 2016, monorepo lớn đã có gần 1.000 PR merge mỗi tháng, nên họ cần gom nhiều PR deploy cùng lúc: train, một PR đặc biệt chứa nhiều PR "hành khách", có một người "lái tàu" điều phối test, deploy, merge.
Train giúp lúc đầu nhưng về sau làm tăng thời gian để một PR lên production. Train tối đa 15 PR và hay "trật bánh" vì lỗi deploy, xung đột, hay ai đó rút thay đổi; có lần chờ hơn 8 giờ rồi bị loại vì hai PR trong cùng train xung đột. Khảo sát nội bộ đều xếp deploy là phần đau nhất; không phải repo nào cũng dùng train nên trải nghiệm giữa các service khác nhau; quy trình cần logic riêng và công cụ ngoài (ChatOps, label).

Yêu cầu từ 2020: developer chỉ cần nói "tôi muốn ship" và "tôi chuyển sang việc khác"; PR có vấn đề không được làm chậm tất cả PR khác (ưu tiên throughput của cả hệ hơn công bằng cho từng PR); nhất quán và tự động trên mọi repo.
Merge queue: tự gom nhóm động các PR ứng viên, chạy build/test qua GitHub Actions, bảo đảm main không bao giờ trỏ tới commit fail; PR xung đột với nhau bị phát hiện và loại tự động, hàng đợi tự gom lại nhóm. Vào/ra hàng đợi bằng một click.
Chuyển dần: vài repo nhỏ từ giữa 2021, monorepo lớn từ 2022, tới 2023 mọi repo của dịch vụ production. Không thể dừng deploy nhiều ngày, tối đa chặn khoảng một giờ cho một bước chuyển, đôi khi thử và lùi vào sáng sớm trước giờ làm.

Trước khi phát hành chung, đã chạy hơn 30.000 PR với 4,5 triệu lượt CI.
Hơn 500 engineer merge 2.500 PR mỗi tháng vào monorepo (hơn gấp đôi vài năm trước); nhóm deploy an toàn được 30 PR trở lên (train là 15); thời gian chờ trung bình để ship giảm 33%.

Gom nhiều PR khấu hao chi phí deploy và kiểm tra, nhưng gom thủ công (train) để một PR xấu kéo cả nhóm. Tự động gom, tự loại phần xung đột giữ được lợi ích của batch mà không mất throughput.

Khi số thay đổi tăng, quy trình tuần tự hoặc gom thủ công thành nút thắt; đo cả thời gian chờ lẫn mức hài lòng của developer.
Chọn rõ ưu tiên: throughput toàn hệ hay công bằng cho từng thay đổi.
Thay hệ deploy đang dùng hằng ngày phải đi từng pha, không có cửa sổ dừng dài.