Fleet Management at Spotify (Part 3): Fleet-wide Refactoring

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

Phần 3: phần 1 Spotify 2023 · phần 2 Spotify 2023. Công cụ Fleetshift về sau được dùng cùng coding agent (Spotify 2026).

Bối cảnh

• Polyrepo hàng nghìn repo; phần lớn backend dùng một service framework và bộ thư viện lõi chung, phần lớn pipeline batch dùng Scio. Từ 2021 Spotify đầu tư vào refactor toàn fleet để "repo" không còn là đơn vị công việc, và kỹ sư bỏ cách nghĩ "code của tôi / code của bạn".

Thay đổi chính

• Quản lý dependency bằng BOM: một artifact Maven chỉ định phiên bản của nhiều thư viện hay dùng, đã được kiểm tương thích với nhau. Thay vì để team tự chọn dùng, tự động onboard mọi backend bằng PR và tự merge nếu qua test. Nay 96% backend production dùng BOM, 80% dùng bản dưới 7 ngày tuổi (giữ 18 tháng liền); đổi phiên bản một thư viện cho cả fleet = một PR vào repo BOM. Làm tương tự cho pipeline Scio bằng plugin sbt (97% pipeline).
• Fleetshift (khởi đầu là hack project của một người, sau thành nền tảng do một team sở hữu): biến đổi code được đóng thành image Docker (từ sed tới OpenRewrite), Fleetshift chạy nó trên từng repo bằng hạ tầng Kubernetes sẵn có (không còn chạy trên laptop), đẩy PR. Mỗi "shift" là một custom resource (operator trên hạ tầng khai báo ở phần 2), chạy một lần hoặc hằng ngày (ví dụ cập nhật BOM mỗi ngày). Tìm repo đích bằng GitHub search hoặc BigQuery (toàn bộ source nạp vào BigQuery hằng ngày).
• Automerger: tự merge khi qua mọi test và check; theo dõi sức khoẻ component sau merge qua sự kiện deploy. Rollout rất chậm: đầu tiên chỉ cho shift BOM, chia backend theo mức quan trọng và bật dần từng nhóm. Mặc định bật, team phải chủ động opt-out. Test không đủ là tín hiệu để chủ component bổ sung (điểm Soundcheck trong Backstage theo dõi mức sẵn sàng tự merge): vừa là cây gậy vừa là củ cà rốt. Theo bài, khi hết sợ, team lại hỏi vì sao thay đổi khác chưa được tự merge.
• Fleetsweep: chạy thử biến đổi trên tập repo, tạo nhánh tạm và build CI, báo tổng hợp repo nào sẽ fail test trước khi gửi PR cho ai.
• Rollout dần theo cohort: với pipeline batch (test trước merge yếu hơn, chạy mỗi giờ/ngày nên phản hồi chậm, thay đổi xấu có thể chỉ ra dữ liệu sai), repo chia thành cohort theo mức quan trọng của dữ liệu và chất lượng test/giám sát; Fleetshift hỏi hệ Firewatch phiên bản cao nhất mà cohort trước đã đạt tỉ lệ deploy/chạy thành công trên ngưỡng. Kết quả hôm qua quyết định có áp tiếp cho repo khác hôm nay.
• Fleetshift còn dùng để gửi "khuyến nghị" (ví dụ storage class rẻ hơn, rightsize pod) dưới dạng PR sẵn.

Kết quả (2022, theo Spotify)

• Hơn 270.000 PR, 77% tự merge, 11% do người merge (tăng 4–6 lần so với 2021); 241.000 PR đã merge.
• Framework backend mới tới 70% service: khoảng 200 ngày → dưới 7 ngày; Scio và plugin sbt tới pipeline: khoảng 300 → 30 ngày.
• 12 tháng qua 49 team dùng Fleetshift gửi PR cho team khác; trung vị 46 repo mỗi shift, 22 shift chạm hơn 1.000 repo.

Vì sao

• Một team nền tảng giữ công cụ, các team khác dùng nó để thay đổi code của người khác: đây là cách nhân rộng mà không bắt chủ mỗi repo làm việc (Quản lý fleet và migrate code hàng loạt).
• Tự merge chỉ an toàn với test đủ, theo dõi sau merge và rollout dần theo mức quan trọng (Deploy và release an toàn).

Bài học cho SWE

• Biến đổi code đóng gói như image chạy được trên hạ tầng chung, không trên laptop.
• Mặc định tự merge (opt-out) cộng chỉ số sẵn sàng theo component tạo động lực để team bổ sung test.
• Với thay đổi mà test trước merge yếu, rollout theo cohort dựa trên kết quả chạy thật của cohort trước.

Liên quan

• Spotify 2023 · Spotify 2023 · Spotify 2026 · Allegro 2024 · eBay 2022
• Quản lý fleet và migrate code hàng loạt · Deploy và release an toàn