Dependabot artık sbt’yi görüyor: Java ekosisteminde küçük ama etkili değişim

İlgili içerik: Dependabot'u Sakinleştirmek: Gruplayın, Yavaşlatın, Güvende

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.

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.

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.

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;

Ç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)

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.