Dependabot hay Renovate: monorepo và số pull request mới quyết định

Với kho mã nhỏ chỉ dùng GitHub, Dependabot thường là lựa chọn phù hợp. Khi monorepo cần gom nhiều bản cập nhật liên quan, hoặc nhóm lưu trữ mã trên nhiều nền tảng, Renovate đáng cân nhắc hơn: bảng đối chiếu của Renovate ghi nhận các nhóm dependency dựng sẵn, lịch chạy theo nhiều phạm vi và khả năng hỗ trợ nhiều nền tảng. Khác biệt có ích nhất cho người duyệt là cách mỗi bot biến một đợt nâng cấp thành các pull request có phạm vi rõ ràng.

Điều đó không có nghĩa Dependabot luôn tạo một pull request cho mỗi gói. Hướng dẫn của GitHub nêu hành vi mặc định là tạo yêu cầu riêng cho từng dependency, đồng thời cho phép đặt lịch và khai báo nhóm; bot mặc định chờ 3 ngày sau khi phiên bản mới phát hành trước khi xét cập nhật phiên bản, nhưng khoảng chờ này không áp dụng cho cập nhật bảo mật. Với cả hai công cụ, lịch kiểm tra, thời gian chờ và quy tắc gom giải quyết những việc khác nhau: thay đổi một mục không tự động làm giảm tải ở các mục còn lại.

Một pull request tốn công ở đâu?

Mỗi yêu cầu cập nhật buộc người duyệt xác định gói nào thay đổi, phần mã nào phụ thuộc vào gói đó, kết quả kiểm thử có đủ liên quan hay không và khi nào nên hợp nhất. Nhiều yêu cầu nhỏ làm nhóm phải lặp lại các quyết định ấy. Một yêu cầu gom quá rộng lại khiến việc truy nguyên lỗi khó hơn: nếu kiểm thử thất bại, người duyệt phải tìm thay đổi gây ra lỗi trong cùng một nhánh cập nhật.

Nghiên cứu về Dependabot trên GitHub ghi nhận 11,3% dự án trong mẫu đã ngừng dùng công cụ để chuyển sang lựa chọn khác; các tác giả cũng nhận thấy điểm tương thích xuất hiện quá thưa để giảm đáng kể sự nghi ngại đối với bản cập nhật. Đây là kết quả của mẫu nghiên cứu, không phải tỷ lệ dự báo cho một nhóm cụ thể. Nó giải thích vì sao giảm thông báo là một nhu cầu thực tế, nhưng số pull request thấp nhất chưa chắc là mục tiêu tốt: nhóm vẫn cần đủ thông tin và phạm vi kiểm thử để ra quyết định.

Đơn vị nên tính là luồng duyệt: một thay đổi có người chịu trách nhiệm, bộ kiểm thử liên quan và quyết định phát hành riêng. Hai pull request cùng đến một người và cùng chạy một bộ kiểm thử có thể là việc lặp lại. Ngược lại, gộp thay đổi của hai nhóm sở hữu khác nhau vào một yêu cầu có thể tiết kiệm thông báo nhưng kéo dài thời gian chờ phê duyệt.

Kho GitHub nhỏ: lợi thế của cấu hình vừa đủ

Với một kho có ít tệp khai báo dependency và một nhóm duyệt mã, Dependabot tận dụng quy trình pull request sẵn có trên GitHub. Nhóm có thể chọn nhịp kiểm tra phù hợp với lúc xử lý hàng đợi, rồi khai báo nhóm cho các bản cập nhật thường được duyệt cùng nhau. Nếu các yêu cầu riêng vẫn được xem và hợp nhất đều đặn, thêm nhiều quy tắc gom có thể làm một thay đổi đơn giản trở nên khó đọc hơn.

Ranh giới gom hữu ích thường xuất phát từ cách dự án kiểm thử. Chẳng hạn, trong một ví dụ giả định, các công cụ chỉ phục vụ bước kiểm tra mã có thể đi chung nếu chúng có cùng người duyệt và cùng bộ kiểm thử. Một bản nâng phiên bản chính của thư viện ảnh hưởng đến mã chạy thực tế nên được xem riêng khi nhóm cần đánh giá thay đổi API. Đây là lựa chọn về phạm vi duyệt, không phải quy tắc cố định theo tên gói.

Dependabot cũng cho phép điều chỉnh lịch theo mục hệ sinh thái trong tệp cấu hình. Vì vậy, kho nhỏ có thể giữ một nhịp cập nhật dễ dự đoán mà chưa cần vận hành thêm bot. Dấu hiệu để xem lại lựa chọn không phải số dependency trong tệp khai báo, mà là các pull request cập nhật bắt đầu chờ lâu, trùng người duyệt hoặc liên tục phải đóng để nâng các gói liên quan cùng lúc.

Monorepo: gom theo thay đổi cần đi cùng nhau

Trong monorepo, cùng một dependency có thể xuất hiện ở nhiều thư mục, còn các hệ sinh thái khác nhau có thể phục vụ cùng một đợt phát hành. Renovate có preset cho những nhóm gói monorepo phổ biến và cho phép tinh chỉnh quy tắc gom. Lợi ích rõ nhất xuất hiện khi các gói cần được nâng đồng bộ và cùng đi qua một quyết định kiểm thử; tên gói giống nhau không đủ để kết luận chúng nên chung một pull request.

Dependabot cũng xử lý được nhiều trường hợp gom trong monorepo. Cấu hình nhóm cho phép chọn dependency theo tên, loại và mức cập nhật; GitHub còn mô tả cách gom một dependency xuất hiện ở nhiều thư mục. Với các hệ sinh thái khác nhau, hướng dẫn nhóm nhiều hệ sinh thái của GitHub cho phép đặt lịch chung, gán từng hệ sinh thái và mẫu dependency vào nhóm để nhận một pull request hợp nhất ở lần chạy kế tiếp.

Sự khác nhau vì thế nằm ở lượng quy tắc nhóm phải tự xây và duy trì. Nếu một monorepo chủ yếu dùng các gói vốn cần nâng cùng nhau, nhóm dựng sẵn của Renovate có thể rút bớt công cấu hình ban đầu. Nếu ranh giới thay đổi của dự án ổn định và mô tả gọn trong cấu hình Dependabot, chuyển bot chỉ để giảm số yêu cầu có thể không đem lại lợi ích tương xứng.

Một ví dụ giả định cho thấy giới hạn của việc gom: cấu hình ảnh container và hạ tầng có thể cần đi chung khi chúng phục vụ cùng một đợt triển khai. Nhưng nếu chúng thuộc hai nhóm chịu trách nhiệm và hai quy trình kiểm thử độc lập, một pull request chung sẽ phải chờ cả hai phía. Monorepo cần ít luồng duyệt lặp lại, đồng thời giữ được ranh giới cần thiết để tìm lỗi và quyết định phát hành.

Lịch chạy và Dependency Dashboard điều tiết hàng đợi

Lịch chạy quyết định lúc bot kiểm tra và đề xuất cập nhật; quy tắc gom quyết định phạm vi từng yêu cầu. Dồn các lần kiểm tra về một ngày thuận tiện có thể giúp nhóm duyệt theo đợt, nhưng không biến nhiều dependency thành một pull request. Với Renovate, lịch có thể áp dụng ở phạm vi rộng hoặc theo loại dependency; với Dependabot, nhịp kiểm tra được khai báo cho các mục cập nhật trong cấu hình.

Renovate có thêm một nơi điều phối trước khi mở pull request. Tài liệu Dependency Dashboard mô tả một issue trong kho mã hiển thị trạng thái cập nhật và cho phép yêu cầu phê duyệt trước khi tạo pull request cho những gói hoặc loại nâng cấp được chọn. Cách này hữu ích khi nhóm muốn thấy việc đang chờ nhưng chỉ đưa một số cập nhật vào hàng đợi duyệt khi đã sẵn sàng xử lý.

Phê duyệt trước cũng chuyển một phần công việc sang issue điều phối. Nếu nhóm ít xem issue đó, các cập nhật thông thường có thể tiếp tục chờ thay vì biến thành pull request. Do vậy, Dashboard phù hợp nhất khi đã có người theo dõi hàng đợi và có tiêu chí rõ cho thay đổi nào cần giữ lại trước khi mở yêu cầu.

Nhiều nền tảng: tính cả công vận hành bot

Khi kho mã nằm trên GitHub cùng GitLab, Bitbucket hoặc một nền tảng khác, Renovate cho phép tổ chức quy tắc cập nhật bằng cùng một công cụ trên nhiều nơi. Tự lưu trữ mang lại quyền kiểm soát cách bot chạy, đổi lại nhóm phải duy trì lịch thực thi, quyền truy cập và cấu hình kết nối. Đây là chi phí có thật bên cạnh thời gian duyệt pull request; chọn Renovate chỉ vì có thể tự lưu trữ sẽ bỏ qua phần vận hành ấy.

Dependabot tích hợp trực tiếp vào GitHub. Nhóm có thể dùng dependabot-core để xây cách chạy riêng ngoài quy trình tích hợp, nhưng khi đó phải tự tổ chức phần vận hành cho môi trường của mình. Nếu toàn bộ kho vẫn ở GitHub và hàng đợi cập nhật đã được kiểm soát bằng lịch cùng nhóm cấu hình, lợi thế đa nền tảng chưa tạo thêm giá trị. Nếu nhiều nơi lưu trữ mã là điều kiện lâu dài, khả năng dùng chung quy tắc và cách điều phối của Renovate trở thành lý do cụ thể hơn để chọn công cụ này.

Đọc thêm:

• Substack, beehiiv hay Kit: khi nào phí 10% trở nên quá đắt?
• VMware gom AI và dữ liệu về private cloud: chi phí mới là lực kéo
• Stan Store hay Fourthwall: doanh thu nào khiến phí 5% đắt hơn thuê bao?