Dependabot’u Sakinleştirmek: Gruplayın, Yavaşlatın, Güvende
Aktif bir depo bakıyorsanız o sabah hissini bilirsiniz: Pazartesi bildirimlerinizi açtığınızda karşınızda beş, on, hatta bir düzine Dependabot pull request’i durur. Her biri tek bir bağımlılığı tek bir yama sürümü ilerletir. Tek başına faydalıdır, toplamda gürültüdür. Gürültü ise önemli güncellemelerin gözden kaçmasının en kısa yolu. İyi haber şu: Dependabot bu sorunu çözecek özelliklerle zaten geliyor. Bu yazıda, GitHub Blog’da Bruno Borges’in paylaştığı GCToolkit örneğinden yola çıkarak dependabot.yml dosyanızı nasıl sadeleştirebileceğinizi ele alıyoruz.
Sorun: doğru varsayılanlar, yanlış ritim
GitHub Blog yazısına göre Microsoft’un açık kaynaklı Java kütüphanesi GCToolkit‘in Temmuz 2026 itibarıyla toplam 578 commit’inin 92’si, yani yaklaşık altıda biri Dependabot sürüm güncellemesiydi. Bunların 61’i son 12 aya aitti ve zaman zaman aynı gün içinde birden fazla PR açıldığı görülüyordu. Rutin bakım için hatırı sayılır bir gözden geçirme, birleştirme ve CI eforu.
Projenin başlangıçtaki yapılandırması şöyleydi:
version: 2
updates:
- package-ecosystem: github-actions
directory: "/"
schedule:
interval: daily
open-pull-requests-limit: 10Yaygın bir başlangıç noktası ama burada iki nokta gürültüyü büyütüyor:
interval: dailyDependabot’a güncellemeleri her iş günü kontrol etmesini söyler; yani hafta içinin herhangi bir gününde yeni PR’lar açılabilir.- Gruplama yok. Her bağımlılık kendi PR’ını alır. On güncelleme varsa on PR, on CI çalışması, on inceleme bildirimi olur.
open-pull-requests-limit: 10 satırı ise bir çözüm değil, semptomdur: Seli 10 açık PR ile sınırlar ama sele engel olmaz. Not: schedule.interval zorunlu bir alan; GitHub’ın önerdiği başlangıç şablonu ise weekly kullanıyor.
Çözüm: birbirini tamamlayan üç değişiklik
GitHub Blog yazısında paylaşılan pull request ile yapılandırma şu hale getirildi:
version: 2
updates:
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "monthly"
groups:
monthly-batch:
patterns:
- "*"
- package-ecosystem: "maven"
directory: "/"
schedule:
interval: "monthly"
groups:
monthly-batch:
patterns:
- "*"1. Her şeyi tek bir PR’da gruplayın
Değişikliğin kalbi groups bloğu. Bir Dependabot grubu, birden fazla bağımlılık güncellemesini tek bir PR içinde toplar. Grubun adı (monthly-batch) size aittir; PR başlığında ve dal adında görünür. patterns listesi hangi bağımlılıkların gruba dahil olacağını belirler ve "*" hepsini kapsayan bir joker karakterdir.
Böylece 10 PR yerine, örneğin “Bump the monthly-batch group with 10 updates” gibi tek bir PR alırsınız. Tek dal, tek CI çalışması, tek inceleme. Toplu güncelleme yeşilse tek seferde birleştirirsiniz; bir şey bozulursa sorun tek ve incelenebilir bir yerde kalır.
Daha büyük projelerde her şeyi tek grupta toplamak zorunda değilsiniz. Daha spesifik desenlere sahip birden fazla adlandırılmış grup tanımlayabilirsiniz: Test kütüphaneleri bir grupta, üretim bağımlılıkları başka bir grupta olabilir.
GitHub Blog’a göre Şubat 2026’daki bir güncellemeyle Dependabot, aynı bağımlılığın birden fazla dizin içindeki güncellemelerini tek bir PR olarak gruplayabilme yeteneği kazandı. Özellik monorepo’ları hedefliyor: Bir kütüphane bir düzine servis içinde sabitlenmişse, artık directories anahtarına yol listesi veya /apps/* gibi bir glob verip hepsini tek grupta toplayabilirsiniz.
- package-ecosystem: "npm"
directories:
- "/apps/*"
schedule:
interval: "monthly"
groups:
monthly-batch:
group-by: dependency-name
patterns:
- "*"2. Ritmi günlükten aylığa çekin
schedule.interval‘ı daily‘den monthly‘e almak, “bir şey değiştiğinde her zaman” ritmini “planlayabileceğiniz bir programla ayda bir” ritmine dönüştürür. Gruplama ile birleşince gerçek gürültü azalması burada olur: Dependabot artık her ay her ekosistem için tek bir toplu PR açar.
Bağımlılıkları kararlı ve güncellemeleri nadiren acil olan olgun kütüphaneler için aylık iyi bir tercih. Ara bir seçenek isterseniz weekly de mevcut; ayrıca schedule.day ve schedule.time ile günü ve saati sabitleyebilirsiniz.
3. Kullandığınız her ekosistemi kapsayın
Orijinal yapılandırma yalnızca github-actions için sürüm güncellemesi istiyordu. Ama GCToolkit Maven ile derlenen bir Java projesi olduğundan uygulama bağımlılıkları Dependabot sürüm güncellemesi almıyordu. Yeni yapılandırma ikinci bir updates girdisi ekleyerek bunu düzeltiyor. Gürültüyü azaltmak kazancın yarısı; diğer yarısı önemli bağımlılıkların da izlendiğinden emin olmak.
Peki güvenlik güncellemeleri?
Herhangi bir şeyi yavaşlatmadan önce her bakıcının sorması gereken soru budur ve tasarımın parladığı yer burasıdır. Varsayılan olarak burada belirlediğiniz gruplar ve zamanlama sürüm güncellemelerinizi şekillendirir, güvenlik düzeltmelerinizi değil. GitHub Blog’a göre Dependabot güvenlik güncellemeleri, düzeltmesi olan bir güvenlik açığı açıklandığı anda schedule‘dan bağımsız olarak açılır ve sürüm güncelleme gruplarınızdan ayrı tutulur. Yani rutin bump’lar için aylık ritim, kritik yamayı geciktirmez. (İsterseniz applies-to: security-updates kapsamlı bir grupla güvenlik düzeltmelerini de gruplayabilirsiniz, ama bunlar yine programınıza değil, açıklamalara bağlı tetiklenir.)
Bir uyarı: Bu güvenlik ağı yalnızca depoda Dependabot güvenlik güncellemeleri açıksa devrededir; bunun için bağımlılık grafiği ve Dependabot uyarılarının da etkin olması gerekir. Daha yavaş bir sürüm güncelleme ritmine güvenmeden önce bunların açık olduğunu doğrulayın.
Yeni bir güvenlik ağı: varsayılan paket bekleme süresi
Son dönemde eklenen ve otomatik çalışan bir gürültü azaltma parçası daha var: Dependabot artık yeni bir sürüm için sürüm güncellemesi PR’ı açmadan önce, o sürümün kayıt defterinde en az üç gün geçmesini bekliyor. Bu cooldown varsayılan davranış ve yapılandırma gerektirmiyor.
Neden beklemek? Yeni bir sürüm, tedarik zinciri saldırıları için en yaygın giriş noktalarından biridir. Ele geçirilmiş veya sadece bozuk bir sürüm, bakıcılar ve topluluk sorunu fark etmeden bağımlılık güncellemelerinize ulaşabilir. Kısa bir gecikme bu sinyalin yüzeye çıkması için zaman kazandırır.
Bilmeye değer iki nokta:
- Yalnızca sürüm güncellemelerine uygulanır. Güvenlik güncellemeleri hala hemen açılır; kritik düzeltmeler bekleme süresi tarafından tutulmaz.
- Kontrol sizde.
.github/dependabot.ymliçindekicooldownseçeneğiyle pencereyi genişletebilir, daraltabilir, semantik sürümleme seviyesine göre ayarlayabilir veya tamamen devre dışı bırakabilirsiniz:
- package-ecosystem: "maven"
directory: "/"
schedule:
interval: "monthly"
cooldown:
default-days: 7
groups:
monthly-batch:
patterns:
- "*"Kendi deponuza nasıl uygularsınız?
Bu deseni birkaç dakika içinde benimseyebilirsiniz:
- Deponun varsayılan dalında
.github/dependabot.ymldosyasını açın veya oluşturun. - Bağımlı olduğunuz her
package-ecosystemiçinschedule.interval‘ıweeklyveyamonthlyolarak ayarlayın. - Ekosistem başına tek bir PR’da toplamak için tek joker gruplu (
patterns: ["*"]) birgroupsbloğu ekleyin. - Yalnızca
github-actionsdeğil, gerçekten kullandığınız her ekosistemi listeleyin:maven,npm,pip,gomod,dockerve diğerleri. - Değişikliği commit’leyin ve sonraki zamanlanmış çalıştırmanın tek, gruplanmış bir PR üretmesini bekleyin.
İnce ayar için birkaç ipucu:
- Geniş başlayın, sonra bölün. Tek bir joker grup en basit başlangıç noktasıdır. İlerleyen zamanda yama seviyesi ve ana sürüm güncellemelerini farklı ele almak isterseniz jokeri daha hedefli adlandırılmış gruplara ayırabilirsiniz.
- Güvenlik düzeltmelerini bu ritme sokmayın. Dependabot güvenlik güncellemeleri güvenlik açığı açıklamalarıyla tetiklenir; aylık ritim onları geciktirmez.
- Cooldown’a yaslanın. Üç günlük varsayılan zaten sizi çok yeni bozuk sürümlerden korur; daha geniş bir güvenlik payı isterseniz
cooldown.default-daysdeğerini artırabilirsiniz. - Aralığı doğru boyutlandırın. Hızlı ilerleyen uygulamalar
weekly‘yi tercih edebilir, kararlı kütüphanelermonthlyile idare eder. - Monorepo dizinlerini birleştirin. Aynı bağımlılık birçok dizinde yaşıyorsa bunları
directoriesaltında listeleyin ve gruptagroup-by: dependency-nameayarlayın.
Sonuç
Bağımlılık güncellemeleri, otomatikleştirmesi kolay olan ama sonra görmezden gelinmeye başlayan işlerdendir; bu da amacı yok eder. Çözüm Dependabot’u kapatmak veya PR’ları bakmadan birleştirmek değil, çıktısını rutin işin sessiz ve toplu, acil işin ise fark edilir olduğu bir biçime sokmaktır. GCToolkit bunu yaklaşık bir düzine satır YAML ile yaptı: Her şeyi gruplayın, ritmi aylığa yavaşlatın ve her ekosistemin kapsandığından emin olun. Üzerine yeni varsayılan cooldown eklendiğinde, o aylık toplu PR bile size ulaşmadan önce birkaç günlük olgunluk kazanmış olur.
Kaynaklar ve İleri Okuma
- Tame Dependabot: Group your updates, slow the cadence, keep security fast (Orijinal Yazı)
- Microsoft GCToolkit deposu
- GCToolkit dependabot.yml değişikliği (PR #572)
- Dependabot sürüm güncellemelerini yapılandırma dokümanı
- PR oluşturmayı optimize etme rehberi
- Birden fazla dizinde bağımlılık adına göre gruplama duyurusu
- Dependabot seçenekleri referansı
- Dependabot güvenlik güncellemeleri hakkında
- Cooldown gerekçesi: Dependabot neden bekliyor?
- Gürültüyü aşmak: Dependabot uyarılarını önceliklendirme
- GitHub Actions 2026 Güvenlik Yol Haritası: Sırada Bizi Neler Bekliyor?
- GitHub Advanced Security’de Bütçe Sınırı: Kontrol Artık Sıkı
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
2 comments