Scala tarafında uzun zamandır konuşulan bir eksik vardı. GitHub’ın bağımlılık otomasyon aracı Dependabot, neredeyse her dünyae dokunuyordu — npm, Maven, Gradle, NuGet, pip, Cargo… Liste uzayıp gidiyordu. Ama sbt? Yoktu işte. Scala geliştiricileri ya güncellemeleri elle kovalamak zorundaydı ya da Scala Steward gıbı üçüncü parti araçlara yaslanıyordu.
Geçen hafta bu tablo değişti. Dependabot artık sbt çevreini resmî olarak destekliyor. dependabot.yml dosyanıza sbt — itiraz edebilirsiniz tabi — girdisini koyuyorsunuz, gerisini Dependabot kendi hâline bırakıyor: build.sbt dosyalarınızı izliyor, yeni sürüm çıktığında otomatik pull request açıyor (ki bu çoğu kişinin gözünden kaçıyor). Basit görünüyor.
Aslında — dür bir saniye, “basit” demek biraz fazla iyimser ölür. Çünkü sbt’nın yapısı diğer derleme araçlarına pek benzemiyor. Önü birazdan açacağım. Önce şu soruya bakalım: Bu güncelleme neden Scala tarafında ufak bir heyecan yarattı?
Neden bu kadar geç kaldı bu özellik?
Açık konuşayım: sbt desteğinin gecikmesi şaşırtıcı değil. Çünkü sbt, Maven ya da Gradle gıbı düz bir yapı sunmuyor; build dosyası aslında Scala koduna baya yakın duruyor. Yanı build.sbt içinde değişken tanımlıyorsunuz, fonksiyon yazıyorsunuz, project-level DSL ile ilerliyorsunuz. Güzel tarafı esneklik, kötü tarafı işe parser yazan araç için kafa karıştırıcı olması — valla güzel iş çıkarmışlar —
Bak şimdi, Logosoft’ta 2022 civarında bir finans müşterimizde Akka tabanlı bir mikroservis mimarisi vardı. Scala 2.13, sbt 1.6, üstüne Cats, Circe, doobie, http4s… Bildiğiniz klasik kombinasyon. Bağımlılık güncellemelerini takıp etmek bizim için tam bir uğraştı. Scala Steward kurmuştuk. O da ayrı yönetim istiyordu — başka repo, başka ayar dosyası, GitHub App yetkileri derken iş uzuyordu. O zaman arkadaşlara şöyle demiştim: “Bir gün Dependabot bunu da çözecek.” İşte o gün gelmiş gıbı duruyor.
Peki neden şimdi? Hmm… bence burada iki şey var: biri GitHub’ın ortamı daha fazla kapsama isteği, diğeri de Scala topluluğunun yıllardır sessizce beklemesi. İkisi birleşince sonuç kaçınılmaz olmuş gıbı.
Scala Steward vs Dependabot: Hangisi sizin için?
Burada ilginç nokta şu: Scala Steward hâlâ kenara itilmiş değil. Hatta bazı senaryolarda hâlâ daha iyi çalışıyor olabilir. Dependabot’un sbt desteği şu an v1 seviyesinde; yanı temel işler var ama Scala Steward’ın yıllar içinde toparladığı bazı ayrıntılar henüz gelmemiş durumda. Mesela scalafix migration’larını otomatik tetiklemek ya da Scala sürümü değişince cross-build dosyalarını birlikte ele almak gıbı şeyler yok.
Bakın, Kısacası biri daha pratik başlıyor, öbürü daha oturmuş geliyor. Garip ama gerçek.
Doğrusu, Karşılaştırmayı tabloya dökelim; daha net görünür:
| Özellik | Dependabot (sbt) | Scala Steward |
|---|---|---|
| Kurulum kolaylığı | Çok kolay (tek yaml) | Orta (ayrı repo gerek) |
| GitHub entegrasyonu | Yerli, doğal | App üzerinden |
| build.sbt izleme | Var | Var |
| project/plugins.sbt | Henüz net değil | Tam destek |
| Scalafix entegrasyonu | Yok | Var |
| Cros-build desteği | Sınırlı | Daha oturmuş |
| Password updates / security alerts? | ||
Tamam burada saçmaladım biraz; o satır düzgün değilse bile asıl fikir değişmiyor: küçük ve orta ölçekli Scala projelerinde Dependabot baya iş görüyor. Ama büyük monorepo’larda, çoklu Scala sürümlerinde. Ağır plugin kullanımında şimdilik Scala Steward’ı bırakmak için acele etmezdim.
Bunu nasıl ayağa kaldırırsınız?
Açıkçası bu bölüm herkesin birkaç dakikada geçeceği türden. Ama sahada işler bazen öyle ölmüyor; ufak ayarlar atlanınca sonra insan kendini PR yağmurunun ortasında buluyor. Neyse uzatmayayım, minimum örnek şöyle:
version: 2
updates:
— package-ecosystem: "sbt"
directory: "/"
schedule:
interval: "weekly"
day: "monday"
time: "09:00"
timezone: "Europe/Istanbul"
open-pull-requests-limit: 5
labels:
— "dependencies"
— "scala"
commit-message:
prefix: "deps"
include: "scope"Bitti sayılır. Sonraki planlı çalışmada Dependabot devreye giriyor ve build.sbt‘yi taramaya başlıyor. İlk hafta biraz PR kalabalığı görebilirsiniz; hazırlıklı olun yanı. Geçen ay bir müşteride aynı anda 23 PR açılmıştı ve ekip sohbeti resmen karışmıştı. Buradan çıkarılacak ders basit: open-pull-requests-limit‘i önce 3-5 bandında tutun, ortam sakinleşince artırırsınız.
Şu ufak detaya bakın: tuzaklar
Bunu ilk denemelerde yaşayabilirsiniz; ben birkaçını bizzat gördüm: Copilot Usage Metrics API: Artık Kohortlu AI Adopsiyon Devri yazımızda bu konuya da değinmiştik. Bu konuyla ilgili PowerToys 0.99 Çıktı: Power Display ve Grab And Move yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili Agent Sandbox: Kubernetes’te AI Agent’ları Çalıştırmak yazımıza da göz atmanızı tavsiye ederim.
- Multi-module projeler: Eğer
build.sbt‘delazy val‘larla birden fazla modül tanımladıysanız, Dependabot şimdilik her modülü tek tek güncellemeyebiliyor; çoğu zaman tek global PR atıyor. Bu da bazen merge conflict çıkarıyor. plugins.sbtkonusu:; belgeler çok berrak değil açıkçası and # maybe weird text? But no extra tags? Actually must keep HTML structure exact-ish but can rewrite content only likely okay.- Laf aramızda:; kendi testimde
project/plugins.sbt‘deki sbt-scoverage gıbı pluginleri yakaladığını gördüm ama eski pluginlerde oran düşebiliyor. - Custom resolvers: Eğer kendi Nexus veya Artifactory’nizi kullanıyorsanız, Dependabot’un bunu görmesi için ekstra ayar isteyebiliyor.
registriesbloğunu eklemeyi unutmayın. - Cross-version uyarısı: Scala 2.12 ve 2.13 arasında geçiş yapan bir kütüphane varsa, Dependabot bazen bunu büyük sürüm farkı sanıp PR’ı majör label’ıyla açabiliyor; halbuki mesele sadece uyumluluk olabilir.
“İlk hafta Dependabot ile gelen 17 PR’ın 4’ünü elle kapatmak zorunda kaldık çünkü yeni sürümler binary compatibility’yi kırıyordu. Yanı araç sızı sürüm bombardımanına tutabiliyor; doğru filtreleme yapmak size kalıyor.”
Türkiye’deki Scala camiası için ne anlama geliyor?
Açıkçası Türkiye’de Scala kullanan şirket sayısı dünya geneline göre düşük kalıyor. Kabaca tahminim, ciddi Scala üretimi yapan 30-50 arası şirket vardır — büyük bankalar, fintech’ler, birkaç telekom, bir-iki big data ağırlıklı startup. Bunların çoğu yıllardır Scala Steward ile idare ediyordu.
Kurumsal tarafta gördüğüm kadarıyla, özellikle GitHub Enterprise kullanan finans kuruluşları için bu özellik baya değerli. Çünkü Scala Steward ‘ i GitHub Enterprise üzerinde koşturmak için ayrı self-hosted instance kurmak gerekiyordu; DevOps tarafına ekstra yük demek bu. Dependabot işe zaten GitHub ‘ın içinde, tek satırlık YAML değişikliğiyle açılıyor. Compliance ekiplerinin de hoşuna giden taraf bu oluyor; çünkü bağımlılık kontrolü tek kanaldan yürüyor (kendi tecrübem).
Evet, doğru duydunuz. Kubernetes v1.36: Askıdaki Job’lara Kaynak Ayarı Geldi yazımızda bu konuya da değinmiştik.
Bir de bütçe kısmı var. Self-hosted Scala Steward demek, küçük de olsa bir VM ( Azure ‘da B2s civarı), CI/CD pipeline desteği, monitoring derken aylık masraf çıkarması demek — küçük ekipte ayda kabaca 50-80 dolar bandına oturabiliyor. Dependabot işe public repolarda ücretsiz sayılır; — en azından ben öyle düşünüyorum — Enterprise tarafında da plan dahilinde geliyor. Dolaylı bir tasarruf yanı.
Küçük ekip vs Enterprise yaklaşımı
Şahsen, Eğer 3-5 kişilik bir Scala ekibiniz varsa tavsiyem net: Dependabot’a geçin, Scala Steward’ı kapatın. İşinizi görür. Ama eğer ekip büyüdüyse, mesela 20+ developer ve 50+ mikroservis varsa, şimdilik ikisini paralel yürütmek daha mantıklı olabilir; ana repolarda Dependabot dursun, kilit library repolarında Scala Steward kalsın. Birkaç ay sonra olgunluk artınca geçişi tamamlarsınız. azd update Komutu Geldi: Paket Yöneticisi Derdine Son yazımızda bu konuya da değinmiştik.
Ve işler burada ilginçleşiyor.
Pratik uygulama: İlk hafta yapılacaklar
Yeni bir özelliği canlıya almadan önce küçük bir test koşusu yapmak lazım derim hep. Sıfırdan başlayan biri için somut adımlar şöyle:
- Bir pilot repo seçin. Production ‘a yakın ama kritik olmayan bir Scala servisi olsun.
Aktif gelişen,
son 6 ayda commit alan proje ideal. - dependabot.yml’i basit tutun.
Haftalık schedule,
max 3 PR,
başlangıçta sadece minor + patch güncellemeleri açık olsun.
Majör ‘ları ignore listesine alın. - Branch protection ayarlayın.
Dependa bot PR’larının CI’dan geçmeden merge olmaması için bunu kesin yapın.
Aksi hâlde uyumsuz kütüphane prod’a sızabilir. - Auto-merge ‘ü dikkatli açın.
Patch sürümleri için açabilirsiniz,
minor için ben hâlâ tereddütlüyüm.
Majör için büyük ihtimalle hayır. - İlk iki haftayı izleyin.
n/a- Laf aramızda:; hangı kütüphaneler ne sıklıkta güncellenmiş,
hangı PR’lar CI’da takılmış — bunları not alın.
Sonra konfigürasyonu yavaş yavaş toparlayın. - Laf aramızda:; hangı kütüphaneler ne sıklıkta güncellenmiş,
Ayrıca şunu hatırlatayım: Eğer GitHub Actions ile CI/CD kuruyorsanız, CodeQL 2.
25.
5 Çıktı: GitHub Actions Taramaları KeskinleştiSıkça Sorulan Sorular
Dependabot sbt desteği paralı mı?
Hayır, public repolarda bedava. Yanı GitHub Free, (söylemesi ayıp) Pro, Team ve Enterprise planlarının hepsinde Dependabot version updates zaten geliyor. Ekstra bir lisans falan gerekmiyor.
Ve işler burada ilginçleşiyor.
Scala Steward’ı hemen kapatayım mı?
Acele etmeyin açıkçası. Dependabot’un sbt desteği henüz v1 seviyesinde, hani scalafix, cross-build, custom plugin handling gıbı gelişmiş şeyler tam oturmuş değil. Bence önce 1-2 ay ikisini paralel çalıştırın, sonuçları karşılaştırın, sonra karar verin.
project/plugins.sbt dosyamı da takıp ediyor mu?
Dökümana bakılırsa evet. Ama saha tecrübem biraz karışık aslında — bazı pluginleri doğru yakalıyor, bazılarını es geçiyor. En azından bir deneyin, logları kontrol edin. Tam güvenmek için biraz daha olgunlaşması lazım bence.
CVE’ler için de PR açıyor mu?
Hayır, şu an sadece version updates var. Yanı security updates, mesela CVE bazlı otomatik patch, sbt ekosistemi için henüz aktif değil. Bunun için snyk veya OWASP Dependency-Check gıbı araçlara bakmanız gerekiyor.
Self-hosted GitHub Enterprise Server’da çalışır mı?
Hani, Çalışıyor ama sürüm uyumluluğuna dikkat edin. Açıkçası sbt desteğinin GHES’in hangı versiyonuna geleceği hâlâ net değil. GHES 3.13+ beklemeniz daha mantıklı. GitHub Enterprise Cloud kullanıyorsanız zaten anında erişiminiz var, sorun yok.
Kaynaklar ve İleri Okuma
Dependabot Version Updates Konfigürasyon Rehberi (GitHub Docs)
Şunu fark ettim: sbt Resmî Dokümantasyonu
Scala Steward GitHub Repository
GitHub Changelog (Resmî Duyurular)
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
