How LinkedIn handles merging code in high-velocity repositories

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

Bối cảnh

Gần 10 năm trước (tức khoảng 2010) LinkedIn bỏ một codebase monolith sang microservice, mỗi team một repo. Năm 2020: hàng nghìn dev, hơn 10.000 repo đang hoạt động, có repo hơn 300 commit/ngày. Trunk-based development.
Ba ràng buộc: nhánh chính (primary) luôn xanh; commit vào nhanh; hệ phải tốt cho cả repo rất bận lẫn repo ít commit.
Xếp hàng merge từng commit không scale khi build mất cả giờ; gộp batch rồi chia nhỏ khi lỗi thì một commit xấu trong lô 20 gây chạy lại vô ích.

git submit thay git push: chạy job validation và trả quyền điều khiển cho dev ngay; job tự rebase và push hộ khi qua. Dev không cần HEAD local mới nhất, chấm dứt vòng lặp test → push bị từ chối → rebase ở repo bận.
Pre-merge và post-merge tuỳ repo: repo ít commit (khoảng 5/ngày) chạy pre-merge nhẹ (lint, kiểm bảo mật tĩnh), build ở post-merge; commit hỏng thì sửa tiếp hoặc revert, có thể bật tự revert khi primary đỏ. Repo bận chạy cùng bộ validation ở cả hai phía (chậm hơn, bù bằng build cache): pre-merge chặn commit xấu, post-merge bắt soft conflict (hai commit đều build được, không xung đột merge, nhưng ghép lại thì hỏng).
"Ai xong trước vào trước", không FIFO: commit không phải chờ commit đến trước chạy xong.
Kết quả: repo bận nhất khoảng 5 soft conflict mỗi năm. Đánh đổi: không giữ thứ tự commit, repo bận chạy validation hai lần.

Theo LinkedIn, không có CI hoàn hảo ở quy mô lớn; họ chọn cho từng repo tự cân giữa tốc độ và độ đúng thay vì một cách cho tất cả (và không dùng ML dự đoán xung đột vì cần quy trình ghép được và đổi được theo thời gian).

Cho phép mỗi repo đặt ranh giới pre/post-merge theo tốc độ commit của nó.
Hệ submit làm rebase và push hộ dev giải quyết phần lớn đau đầu của repo bận mà không cần merge queue tuần tự.