Kiểm soát Dependabot: Nhóm cập nhật và tối ưu tần suất để giảm nhiễu cho dự án

Dependabot giúp các phụ thuộc (dependencies) của bạn luôn được cập nhật, nhưng các thiết lập mặc định có thể làm tràn ngập kho lưu trữ (repository) của bạn bằng các pull request. Dưới đây là cách nhóm các bản cập nhật, làm chậm tần suất và giữ cho các bản vá bảo mật được xử lý nhanh chóng để giảm bớt sự phiền nhiễu trên một dự án mã nguồn mở của Microsoft.

29 tháng 7, 2026

8 phút

Nếu bạn duy trì một kho lưu trữ đang hoạt động, bạn chắc hẳn hiểu cảm giác này. Bạn mở thông báo vào sáng thứ Hai và thấy chúng ở đó: năm, 10, đôi khi là cả chục pull request từ Dependabot, mỗi cái chỉ nâng cấp một phụ thuộc duy nhất lên một phiên bản vá lỗi. Riêng lẻ thì mỗi cái đều hữu ích. Nhưng gộp lại, chúng là sự phiền nhiễu. Và chính sự phiền nhiễu đó khiến các bản cập nhật quan trọng bị bỏ qua.

Chúng tôi đã xem xét GCToolkit của Microsoft, một thư viện Java mã nguồn mở dùng để phân tích nhật ký thu gom rác (garbage collection logs). Tính đến tháng 7 năm 2026, nhật ký git của kho lưu trữ cho thấy 92 trong số 578 commit, tức khoảng một phần sáu, là các bản nâng cấp phiên bản từ Dependabot, với 61 bản chỉ trong 12 tháng gần nhất, đôi khi có vài bản trong một ngày. Đó là rất nhiều chu kỳ đánh giá, hợp nhất và CI (tích hợp liên tục) bị tiêu tốn cho việc bảo trì định kỳ.

Tin tốt là: Dependabot đã có sẵn các tính năng để khắc phục điều này. Trong một pull request gần đây, dự án đã thay đổi tệp dependabot.yml theo ba cách nhỏ nhưng đầy ý nghĩa, biến dòng chảy pull request đơn lẻ hàng ngày thành một đợt cập nhật hàng tháng theo nhóm, có thể dự đoán trước cho từng hệ sinh thái. Dưới đây là những gì đã thay đổi, lý do tại sao nó hiệu quả và cách áp dụng mô hình tương tự cho kho lưu trữ của riêng bạn, theo ví dụ của GCToolkit.

Vấn đề: Thiết lập mặc định tốt, nhưng tần suất chưa phù hợp

Đây là cấu hình của GCToolkit trước đây:

Đây là điểm khởi đầu phổ biến, nhưng khoảng thời gian hàng ngày (daily) ở đây là một lựa chọn có chủ đích chứ không phải mặc định: schedule.interval là bắt buộc, và mẫu khởi đầu được GitHub gợi ý sử dụng hàng tuần (weekly). Có hai yếu tố khiến cấu hình này gây nhiễu:

Dòng open-pull-requests-limit: 10 chỉ là triệu chứng, không phải phương thuốc: nó giới hạn số lượng pull request mở ở mức 10, nhưng không ngăn được sự tràn ngập.

Giải pháp: Ba thay đổi mang lại hiệu quả cộng hưởng

Đây là cấu hình sau khi thay đổi:

Có ba điều đang diễn ra ở đây và chúng bổ trợ cho nhau.

1. Nhóm mọi thứ vào một pull request duy nhất

Khối groups là trọng tâm của thay đổi này:

Một nhóm Dependabot sẽ gộp nhiều bản cập nhật phụ thuộc vào một pull request. Tên nhóm (monthly-batch) là do bạn chọn. Nó sẽ xuất hiện trong tiêu đề pull request và tên nhánh. Danh sách patterns quyết định những phụ thuộc nào thuộc về nhóm đó, và "*" là ký tự đại diện khớp với tất cả các phụ thuộc.

Vì vậy, thay vì 10 pull request, bạn nhận được một pull request có tiêu đề kiểu như “Bump the monthly-batch group with 10 updates.” Một nhánh. Một lần chạy CI. Một lần đánh giá. Nếu toàn bộ đợt cập nhật đều ổn, bạn chỉ cần hợp nhất một lần là xong. Nếu có lỗi xảy ra, nó nằm gọn trong một nơi duy nhất để kiểm tra.

Đối với các dự án lớn hơn, bạn không cần phải gộp tất cả mọi thứ lại với nhau. Bạn có thể định nghĩa nhiều nhóm có tên với các mẫu cụ thể hơn. Ví dụ, bạn có thể giữ tất cả các thư viện kiểm thử (testing libraries) trong một nhóm và các phụ thuộc sản xuất (production dependencies) trong một nhóm khác, để các bản cập nhật liên quan đi cùng nhau và những cái không liên quan được tách biệt.

Khả năng nhóm cũng ngày càng mạnh mẽ hơn. Trong bản cập nhật tháng 2 năm 2026, Dependabot đã có khả năng nhóm các bản cập nhật cho cùng một phụ thuộc trên nhiều thư mục vào một pull request duy nhất. Điều này nhắm trực tiếp vào các monorepo: nếu một thư viện được ghim trong hàng chục dịch vụ, một bản nâng cấp trước đây sẽ mở ra hàng chục pull request gần như giống hệt nhau, mỗi thư mục một cái. Giờ đây, bạn có thể trỏ khóa directories (lưu ý số nhiều) vào một danh sách các đường dẫn, hoặc một glob như /apps/*, và để nhóm của bạn gộp tất cả chúng lại thành một:

Đó chính là nhóm monthly-batch như trước, nhưng giờ đây bao trùm mọi dịch vụ trong kho lưu trữ thay vì chỉ một thư mục. Để xem đầy đủ các tùy chọn, hãy tham khảo tài liệu tham khảo về các tùy chọn của Dependabot.

2. Làm chậm tần suất từ hàng ngày xuống hàng tháng

Chuyển từ hàng ngày sang hàng tháng thay đổi nhịp độ từ “bất cứ khi nào có thay đổi” thành “một lần, theo lịch trình mà bạn có thể lên kế hoạch”. Kết hợp với việc nhóm lại, đây chính là cách giảm nhiễu thực sự: Dependabot giờ đây chỉ mở một pull request đã gộp cho mỗi hệ sinh thái, mỗi tháng một lần, thay vì rải rác liên tục suốt cả tháng.

Hàng tháng là lựa chọn phù hợp cho một thư viện đã trưởng thành, nơi các phụ thuộc ổn định và các bản cập nhật hiếm khi khẩn cấp. Nếu bạn muốn một khoảng thời gian ở giữa, hàng tuần (weekly) cũng có sẵn, và bạn có thể ghim chính xác ngày và giờ với schedule.day và schedule.time.

3. Bao phủ mọi hệ sinh thái mà bạn thực sự sử dụng

Cấu hình ban đầu chỉ yêu cầu cập nhật phiên bản cho github-actions. Nhưng GCToolkit là một dự án Java được xây dựng bằng Maven, vì vậy các phụ thuộc ứng dụng của nó không nhận được các bản cập nhật phiên bản từ Dependabot. Cấu hình cập nhật đã thêm một mục updates thứ hai:

Đây là một điểm dễ bị bỏ sót. Giảm nhiễu chỉ là một nửa thành công; nửa còn lại là đảm bảo Dependabot đang theo dõi các phụ thuộc quan trọng nhất. Mỗi hệ sinh thái có lịch trình và nhóm riêng, vì vậy các bản cập nhật Actions và Maven của bạn sẽ đến dưới dạng hai đợt riêng biệt, sạch sẽ.

Nhưng còn các bản cập nhật bảo mật thì sao?

Đây là câu hỏi mà mọi người duy trì dự án nên đặt ra trước khi làm chậm bất cứ điều gì, và đây là điểm mà thiết kế này thực sự tỏa sáng: theo mặc định, các nhóm và lịch trình bạn thiết lập ở đây chỉ định hình các bản cập nhật phiên bản, không phải các bản vá bảo mật.

Các bản cập nhật bảo mật của Dependabot được đưa ra ngay khi một lỗ hổng có bản vá được công bố, độc lập với lịch trình của bạn và tách biệt với các nhóm cập nhật phiên bản. Vì vậy, tần suất hàng tháng cho các bản nâng cấp định kỳ không làm chậm trễ một bản vá quan trọng. (Bạn có thể cố tình gộp các bản vá bảo mật với một nhóm được chỉ định applies-to: security-updates, nhưng ngay cả khi đó, chúng vẫn được kích hoạt bởi các thông báo lỗ hổng, không phải bởi lịch trình cập nhật phiên bản của bạn.)

Một lưu ý: mạng lưới an toàn này chỉ tồn tại nếu các bản cập nhật bảo mật của Dependabot thực sự được bật cho kho lưu trữ, điều này cũng yêu cầu dependency graph và Dependabot alerts phải được kích hoạt. Hãy xác nhận những tính năng đó đã được bật trước khi bạn dựa vào tần suất cập nhật phiên bản chậm hơn. Làm được điều đó, bạn sẽ có được cả hai lợi ích: bảo trì yên tĩnh, có thể dự đoán trước cho những thứ định kỳ và hành động ngay lập tức khi có lỗ hổng thực sự xuất hiện.

Sự tách biệt đó là điều khiến việc “làm chậm Dependabot” trở thành một khuyến nghị an toàn thay vì rủi ro.

Một mạng lưới an toàn mới: thời gian chờ mặc định cho gói (package cooldown)

Có thêm một cách giảm nhiễu nữa vừa được áp dụng gần đây và nó diễn ra tự động. Dependabot hiện đợi cho đến khi một bản phát hành mới có mặt trên registry ít nhất ba ngày trước khi mở pull request cập nhật phiên bản. Thời gian chờ này là mặc định và không cần cấu hình.

Tại sao phải đợi? Một bản phát hành hoàn toàn mới là một trong những điểm xâm nhập phổ biến nhất cho các cuộc tấn công chuỗi cung ứng. Một phiên bản bị xâm nhập hoặc đơn giản là bị lỗi có thể tiếp cận các bản cập nhật phụ thuộc của bạn trước khi những người duy trì và cộng đồng rộng lớn hơn kịp phát hiện vấn đề. Một khoảng thời gian chờ ngắn giúp tín hiệu đó có thời gian xuất hiện, vì vậy bạn sẽ ít có khả năng hợp nhất một bản phát hành lỗi ngay khi nó vừa ra mắt.

Hai điều đáng biết:

Kết hợp thời gian chờ với việc nhóm và tần suất hàng tháng sẽ tạo ra hiệu quả cộng hưởng: ít pull request hơn, và những cái bạn nhận được đã có vài ngày để chứng minh rằng chúng an toàn để hợp nhất.

Cách áp dụng điều này vào kho lưu trữ của riêng bạn

Bạn có thể áp dụng mô hình này trong vài phút:

Một vài mẹo khi bạn tinh chỉnh nó:

Kết luận