Dependabot artık sbt’yi görüyor: Java ekosisteminde küçük ama etkili değişim
Geçen hafta bir müşteride, İstanbul’daki orta ölçekli bir fintech ekibinde, paket güncellemeleri yüzünden gece yarısı açılan PR’ların sayısı iyice artmıştı. İşin garibi, sorun koddan çok bakım disiplinindeydi. Şimdi GitHub Dependabot’un sbt desteği gelince tablo (belki yanılıyorum ama) biraz değişiyor; çünkü Scala/Java tarafında çalışan ekipler için bağımlılık takibi daha derli toplu hâle geliyor. Küçük bir özellik gibi dürüyor ama pratikte baya iş görüyor.
Açık konuşayım, bu tip duyurular ilk bakışta insanı havaya sokmuyor. “Yeni ecosystem eklendi” deyip geçiyorsunuz. Ama kurumsal tarafta, özellikle build zinciri dağınıksa, her otomasyon kırıntısı değerli oluyor; ben bunu 2024 sonbaharında Ankara’daki bir üretim firmasının platform ekibinde de gördüm (dependency güncellemeleri elle takip edilince sürprizler çoğalıyor, otomasyon devreye girince ekip nefes alıyor) — dürüst olayım, biraz hayal kırıklığı —. Evet.
Ve işler burada ilginçleşiyor.
Bir de şu var: sbt dünyası bazen yanlış okunuyor. Sanki sadece “Scala kullananların derdi” gibi görülüyor ama aslında birçok kurumda JVM tabanlı servislerin omurgasında dürüyor. Dolayısıyla bu destek, sadece teknik bir ekleme değil; bakım yükünü azaltan ufak ama temiz bir hamle.
sbt desteği tam olarak ne getiriyor?
Peki ne yapıyor bu iş? Dependabot artık `.github/dependabot.yml` dosyanıza sbt eklediğinizde, `build.sbt` içindeki bağımlılıkları izleyebiliyor. Upstream tarafta yeni commit ya da uygun sürüm geldiğinde pull request açıyor; buradaki can alıcı nokta şu: Bu mekanizma paket yöneticisi mantığıyla çalışmıyor, daha çok kaynak projedeki güncellemeleri takip eden bir göz gibi davranıyor.
Bunu mutfaktaki erzak takibine benzetiyorum. Her şeyi tek tek hatırlamak yerine biri dolabın içine bakıp “şeker bitmek üzere” diyor (şaşırtıcı ama gerçek). Dependabot da kabaca bunu yapıyor; fakat yalnızca belirlediğiniz zamanlarda ve tanımlı kurallarla hareket ediyor. Basit görünüyor, değil mi?
İşin garibi, 2019’da Logosoft’ta büyükçe bir entegrasyon projesinde buna benzer manuel bağımlılık takibi yapıyorduk. O dönem otomasyon bu kadar yaygın değildi ve dürüst olayım, en çok zaman kaybettiren şeylerden biri buydu; bir kütüphane güncellemesi gelir, sonra testler patlar (sonra kimsenin fark etmediği transitive dependency problemi çıkar), iş uzar gider.
Şimdi durum biraz daha iyi. Yine kusursuz değil — hatta bazı alanlarda hâlâ ham — ama düzeni seviyorsanız bu destek tam yerinde geliyor.
Neden önemli?
İşin garibi, sbt tarafında çalışan ekipler genelde iki uç arasında kalıyor: ya güncellemeleri fazla sıkı tutup sürekli PR yağmuruna maruz kalıyorlar ya da gevşek bırakıp teknik borcu büyütüyorlar. Dependabot burada orta yolu veriyor; düzenli PR açılıyor, ekip inceleyip karar veriyor.
Benim AZ-104. AZ-305 hazırlık süreçlerinde de hep aynı mantık vardı: otomasyonu erken kurmazsanız iş büyüyünce elle kontrol eziyete dönüyor (özellikle sınav notları ve lab ortamları birbirine girince insanın kafası karışıyor). Bağımlılık yönetimi de aynı kafa yapısını istiyor; küçükken disiplin koyarsanız ileride yangın söndürmezsiniz.
İşte tam da bu noktada devreye giriyor.
.github/dependabot.yml içinde nasıl kullanılır?
Konu teknik olarak basit görünüyor ama detaylar önemli. `dependabot.yml` dosyanızda sbt için yeni bir giriş açıyorsunuz ve sonraki planlı çalışmada Dependabot PR üretmeye başlıyor. Yapılandırma kısmında asıl mesele frekans. Kapsamı doğru seçmek; çünkü yanlış ayar yapınca fayda var sanıyorsunuz ama sonra kuyruk şişiyor.
version: 2
updates:
— package-ecosystem: "sbt"
directory: "/"
schedule:
interval: "weekly"
Vallahi, Bu örnek temel hâliyle yeterli olabilir ama büyük organizasyonda çoğu zaman yetmez. Mesela monorepo varsa birden fazla dizin tanımlamanız gerekebilir. Ayrıca review sürecini de düşünmek lazım; yoksa PR sayısı artar ve ekip “bu da mı geldi şimdi” moduna girer.
Garip gelecek ama, Bir dakika, şunu da ekleyeyim: Sadece çalışması yetmiyor, okunabilir olması da gerekiyor. Çünkü bu dosyayı yarın başka biri devralacak olabilir (özellikle enterprise yapılarda). Kötü yazılmış YAML dosyası küçük görünür ama bakım maliyeti gizlice şişer. Daha fazla bilgi için GitHub Copilot Model Yönetiminde Yeni Dönem: Kuralları İnce Ayarla yazımıza bakabilirsiniz.
| Senaryo | sbt + Dependabot | Dikkat Noktası |
|---|---|---|
| Küçük startup | Haftalık PR ile hızlı kontrol | PR sayısını düşük tutun |
| Enterprise ekip | Daha sık tarama ve katı onay akışı | Sahiplik ve test otomasyonu şart |
| Düzenli release yapan takım | Sürüm görünürlüğü artar | Kırılma riski testlerle dengelenmeli |
Sadece avantaj değil: eksik tarafı da var
Bence bu özellik doğru yönde atılmış bir adım ama her şeyi çözdüğünü söylemek fazla iyimser olurdu. Öncelikle güvenlik güncellemeleri kapsam dışında kalıyor; yanı bunu supply chain security’nın tamamı sanmayın (inanın bana). Version update ile security update aynı şey değil, arada ciddi fark var. Bu konuyla ilgili GitHub Copilot’ta.NET İşini Doğru Yerden Tutmak yazımıza da göz atmanızı tavsiye ederim.
E tabi, upstream commit takibi de her zaman sihirli çözüm olmuyor.
Bazı projelerde uyumluluk zinciri uzun oluyor;
sürüm yükselir ama testler kırılır,
ardından neredeyse tüm akşamınız gider.
Geçen mart ayında İzmir’deki bir SaaS müşterisinde buna benzer bir durum yaşadık;
güncelleme PR’ı geldi diye sevindik,
sonra integration testleri üç ayrı modülde patladı.
Neyse uzatmayalım; Bu konuyla ilgili Copilot kullanımında yeni dönem: Cohort verisi ne anlatıyor? yazımıza da göz atmanızı tavsiye ederim.
Çok konuştum, örnekle göstereyim.
bana göre asıl kazanım hız değil, görünürlük.
Ekip “ne değişti” sorusuna daha erken cevap veriyor.
Bu fena değil;
hatta baya işe yarayan türden bir kazanım.
Tam da öyle.
Küçük ekip mi büyük kurum mu?
Küçük ekiplerde yaklaşım daha sade olmalı.
Haftalık tarama yeterli olabilir,
çünkü zaten insanlar birbirinin işini biliyor
ve review döngüsü kısa sürüyor.
Büyük kurumsal yapılarda işe konu biraz çetrefilli;
ownership net değilse gelen her PR top gibi sektirilir (şaşırtıcı ama gerçek) Daha fazla bilgi için küçük konusundaki yazımız yazımıza bakabilirsiniz.
Enterprise tarafta ayrıca compliance meselesi devreye giriyor.
Kim onayladı?
Hangi branch koruması var?
Test koşulları neler?
Bunlar yoksa otomasyon fayda yerine gürültü üretebilir —
açık konuşayım,
en kötü senaryo budur.
Sız ne dersiniz?
Türkiye’deki şirketler açısından ne anlama geliyor?
Bunu Türkiye pazarına oturtunca ilginç bir resim çıkıyor.
Bizde birçok ekip hâlâ “önce çalışsın sonra bakarız” yaklaşımıyla ilerliyor;
özellikle hızlı büyüyen şirketlerde bağımlılık yönetimi biraz arka plana itiliyor.
Sonra kriz günü geliyor
ve kimse hangi kütüphanenin ne zaman değiştiğini hatırlamıyor…
işte orada automation altın değerinde oluyor.
Bakın, Kurumlarda gördüğüm kadarıyla Türkiye’de benimsenme biraz farklı ilerliyor. Ekipler hem maliyet baskısı altında hem de insan kaynağı sınırlı olabiliyor (bir yandan teslim tarihi yaklaşıyor, diğer yandan kimse ekstra işi üstlenmek istemiyor). Böyle ortamlarda Dependabot gibi araçlar sadece konfor sağlamaz; doğrudan operasyonel yükü azaltır.
Açık konuşayım, Maliyet tarafına da bakalım:
GitHub tarafındaki bu tip otomasyonların kendisi genelde lisans planına bağlı olsa da asıl maliyet insan zamanı oluyor.
Bir PR’ı manuel takip etmekle haftada birkaç saat kaybetmek arasında fark var.
TL bazında düşününce o birkaç saat bile can yakabiliyor.
Mesela de de finans veya e-ticaret gibi değişikliklerin sık olduğu sektörlerde bu küçük tasarruf yıl sonunda hiç küçücük kalmıyor.
Bence nasıl konumlandırmak lazım?
Dependabot’un sbt desteği “büyük dönüşüm” değil; ama düzgün kullanılırsa sessizce borcu azaltan o iyi araçlardan biri.
- Lafı gevelemeden söyleyeyim: Bu tarz yenilikleri abartmayı sevmiyorum ama küçümsemeyi de sevmiyorum.
- Çünkü kurumsal hayatta başarı bazen büyük mimarı hamlelerle değil,
birikmiş küçük işleri düzenlemekle geliyor.
(bu kritik) - Bugün sbt desteği,
yarın başka ecosystem,
ertesi gün biraz daha az manuel iş… - Paket versiyonlarını düzenli görmek istiyorsanız işe yarar.
Sadece güvenlik odaklıysanız tek başına yetmez.
Büyük organizasyonda süreç tasarımı şarttır.
Küçük ekipte işe hızlı kazanım verir.
Az önce X dedim diye düşünmeyin; aslında burada mesele X’in kendisi değil, çevresindeki rutin yükün hafiflemesi (hani şu herkesin üstüne sinen küçük işler var ya). Bence olay tam orada dönüyor.
Sıkça Sorulan Sorular
sbt desteği güvenlik güncellemelerini de kapsıyor mu?
Hayır, bu duyuru sadece version updates için geçerli. Yanı Dependabot build.sbt içindeki sürüm değişikliklerini izliyor, ama güvenlik yamaları için ayrı bir mekanizma gerekiyor. Açıkçası bu ikisini karıştırmak çok kolay, dikkat etmekte fayda var.
.github/dependabot.yml içine ne yazmam gerekiyor?
`package-ecosystem` alanına `sbt` yazıyorsun. Sonra ilgili dizini ve tarama sıklığını belirliyorsun. Tecrübeme göre çoğu durumda haftalık tarama ile başlamak gayet yeterli oluyor.
Büyük kurumlarda hemen kullanmak mantıklı mı?
Şahsen, Evet, ama körlemesine değil (en azından benim deneyimim böyle). Önce bir pilot repo seçin, sonra review akışını ve branch protection kurallarını oturtun. Bence bu adımı atlamak istemezsiniz, yoksa gelen PR sayısı ekipte ciddi bir gürültüye dönüşebilir.
Küçük ekipler için en iyi başlangıç ne?
Kritik uygulamalardan başlayın ve haftalık tarama kullanın. İlk etapta kapsamı dar tutmak, aslında en sağlıklı yaklaşım. Sonra ihtiyaç varsa genişletirsiniz, mesela aylık yerine haftalık taramaya geçmek gibi şeyler. Sonradan ayarlanıyor.
Kaynaklar ve İleri Okuma
GitHub Docs — Configuring Dependabot version updates
sbt Resmî Sitesi — Introduction to sbt
GitHub Blog — Dependabot version updates now support the sbt ecosystem
Ayrıca okumaya değer yazılarımızdan bazıları:
GitHub Code Quality API: Repo Bazlı Açma-Kapama Dönemi (buna dikkat edin)
Evet… bitti diyelim ama aslında buradan sonrası sizin repoda başlayacak!
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.







Yorum gönder