- Bazel là hệ thống build mã nguồn mở do Google phát triển để build monorepo quy mô lớn một cách hiệu quả
- Có thể build các dự án phức tạp một cách chính xác và nhanh chóng, đặc biệt hiệu quả khi xử lý codebase lớn và các dependency đa ngôn ngữ
- Các khái niệm cốt lõi của Bazel
- Tốc độ dựa trên tính chính xác: Bazel coi quá trình build là hàm thuần, bảo đảm cùng một đầu vào sẽ tạo ra cùng một đầu ra
- Caching hiệu quả: Trong môi trường quy mô lớn của Google, caching là yếu tố bắt buộc, và tính chính xác giúp điều đó trở nên khả thi
- Build không cần dọn sạch: Sau khi thay đổi mã nguồn, vẫn có thể build ổn định mà không cần "clean build"
- Khi nào nên dùng Bazel
- Trường hợp nên dùng
- Monorepo quy mô lớn: Khi số dòng mã lên đến hàng triệu và sử dụng nhiều ngôn ngữ
- Quản lý dependency đa ngôn ngữ: Ví dụ huấn luyện mô hình bằng Python, xử lý dữ liệu bằng Scala
- Yêu cầu CI/CD nhanh và chính xác: Tăng tốc độ phát triển và tránh xung đột
- Trường hợp không khuyến nghị
- Dự án nhỏ: Khi số dòng mã dưới 100.000 và chỉ dùng một ngôn ngữ
- Thư viện mã nguồn mở: Bazel phù hợp để tạo artifact có thể phát hành, nhưng còn hạn chế với việc phân phối thư viện tái sử dụng
- Những điểm cần cân nhắc khi áp dụng Bazel
- Đường cong học tập ban đầu khá dốc, và cần thêm nguồn lực để viết cũng như bảo trì các file build
- Việc xây dựng hạ tầng như cache server và cấu hình remote execution là bắt buộc
- Các trường hợp thành công với Bazel
- Netflix
- Vấn đề: Ở repo chứa 250.000-300.000 dòng mã, thời gian CI mất từ 45 phút đến 1 giờ
- Giải pháp: Sau khi áp dụng Bazel, thời gian build giảm từ 20 phút xuống còn 6 phút
- Hiệu quả: Giảm xung đột khi merge, cải thiện tốc độ xử lý PR
- Open Systems
- Vấn đề: Thời gian build chậm và quy trình làm việc kém hiệu quả
- Giải pháp: Sau khi chuyển sang Bazel, rút ngắn vòng phản hồi từ 20 phút xuống còn 5 phút
- Bài học: Đào tạo và giao tiếp với lập trình viên là rất quan trọng
- Ưu và nhược điểm của việc áp dụng Bazel
- Ưu điểm
- Thời gian build nhanh: Cải thiện tốc độ nhờ caching và incremental build
- Tính chính xác và khả năng tái lập: Biểu diễn chính xác đồ thị dependency phức tạp
- Tích hợp đa ngôn ngữ: Hỗ trợ nhiều ngôn ngữ như Haskell, TypeScript, Python
- Nhược điểm
- Chi phí áp dụng cao: Thiết lập ban đầu và đường cong học tập khá dốc
- Cần quản lý file build: Bắt buộc phải khai báo rõ đầu vào/đầu ra, và cần tận dụng công cụ tự động hóa
- Tooling JavaScript và frontend: Khó tương thích với workflow hiện có như hot reloading
- Mẹo migration sang Bazel
- Lập đội ngũ nòng cốt: Bảo đảm có chuyên gia hiểu và có thể cấu hình Bazel
- Đào tạo và giao tiếp: Ở giai đoạn đầu áp dụng, việc đào tạo lập trình viên và thiết lập kỳ vọng là bắt buộc
- Độ phức tạp theo từng ngôn ngữ: Mỗi ngôn ngữ đòi hỏi cấu hình build khác nhau
- Tự động hóa file build: Dùng các công cụ như Gazelle
- Kết luận
- Bazel rất xuất sắc trong việc xử lý monorepo quy mô lớn và dependency phức tạp, nhưng chi phí áp dụng cao
- Phù hợp với các tổ chức quản lý hàng triệu dòng mã và nhiều ngôn ngữ
- Với dự án nhỏ hoặc nếu muốn chuyển đổi dần dần, có thể cân nhắc các lựa chọn thay thế như Earthly
3 bình luận
Có lẽ sẽ tốt hơn nếu cũng đề cập đến các trường hợp thất bại khi áp dụng Bazel.
Trong trường hợp của AOSP, trong vài năm gần đây tại BazelCon đã có một số bài trình bày về việc di chuyển từ hệ thống build hiện có (Soong) sang Bazel.
https://developers.googleblog.com/en/…
Tuy nhiên, tại BazelCon năm nay, nội dung liên quan đến AOSP đã không còn được chia sẻ, và trong các tài liệu gần đây về build của AOSP cũng đã xuất hiện thông báo rằng việc chuyển sang Bazel đã bị dừng lại.
Xét về việc migration sang Bazel, một đội như AOSP hẳn có thể nhận được rất nhiều hỗ trợ, nên việc họ từ bỏ triển khai dường như cho thấy khá nhiều hàm ý đáng suy ngẫm.
Có lẽ… phần mềm của bạn không cần Bazel.
Haha, Earthly đang quảng cáo cho chính Earthly ở đây nhỉ.
Bazel nhấn mạnh vào build nhanh và "test" nhanh. Không thấy nói nhiều về phần test.