Bazel 8 2026: Monorepo Build System Production Implementation

Bazel 8, 2026 yılında monorepo build system kategorisinin lider aracı olarak yerini sağlamlaştırdı. Google’ın 2015’te açık kaynaklaştırdığı bu build sistemi, Stack Overflow Survey 2025 verilerine göre 5000+ geliştirici çalışan organizasyonların yüzde 34’ü tarafından production’da kullanılıyor. ThoughtWorks Tech Radar Mart 2025 sayısı Bazel’i Adopt halkasında konumlandırdı ve “büyük ölçekli monorepo’lar için varsayılan tercih” olarak nitelendirdi. Bazel 8 ile gelen Bzlmod (modul sistemi) artık varsayılan, WORKSPACE dosyaları deprecated; bu önemli bir mimari dönüşüm. Konuyla ilişkili olarak Monorepo Yönetimi: Nx, Turborepo, Bazel Karşılaştırması rehberimiz detaylı incelemeyi içerir.

Bazel’in temel vaadi basit ama güçlü: deterministik, hermetic, incremental ve scalable build’ler. Aynı kaynaktan aynı output’u garanti eden hermetic build, sadece değişen dosyaları yeniden derleyen incremental özelliği, makineler arası shared cache ve milyonlarca dosyaya ölçeklenebilirlik Bazel’i monorepo dünyasının vazgeçilmezi haline getirdi. Bu yazıda Bazel 8’in production implementation pattern’lerini, Bzlmod geçişini, performans optimizasyonlarını ve kurumsal benimseme deneyimlerini detaylı ele alıyoruz.

Bazel Mimarisinin Temel İlkeleri

Bazel’in mimarisi dört temel ilke üzerine kuruludur: hermetic build, deterministik output, fine-grained dependency tracking ve action caching. Hermetic build, build’in sadece deklare edilmiş input’lara bağlı olmasını garanti eder. Sistem PATH’inde tesadüfen bulunan bir tool, build’i etkileyemez. Bu sayede aynı kaynak, aynı build configuration’ı ile her zaman aynı output’u üretir.

Bazel’in temel kavramları “target”, “rule” ve “package”dır. Target, build edilecek bir yazılım birimini (executable, library, test) ifade eder. Rule, target’ların nasıl build edileceğini tanımlayan template’tir (cc_library, java_binary, py_test gibi). Package, BUILD veya BUILD.bazel dosyası bulunan bir dizindir ve içindeki target’ları gruplar. WORKSPACE dosyası (Bazel 8 ile MODULE.bazel olarak değişti) tüm repository’nin ortak ayarlarını içerir.

Bzlmod ve Modül Sistemi Geçişi

Bazel 8’in en büyük yeniliği Bzlmod’un varsayılan hale gelmesidir. Bzlmod, npm, cargo gibi paket yöneticilerinden esinlenerek tasarlanmış modern bir dependency yönetim sistemidir. Eskiden WORKSPACE dosyasında yazılan external dependency’ler (load fonksiyonu, http_archive, git_repository), artık MODULE.bazel dosyasında bazel_dep ile deklare ediliyor.

• MODULE.bazel: Project root’undaki modul deklarasyon dosyası; bazel_dep, register_toolchains, override directive’leri içerir
• BAZEL_CENTRAL_REGISTRY (BCR): Topluluk tarafından maintain edilen halka açık modül kayıt sistemi; 800+ modül
• Custom registry: Kurumsal kullanımda kuruluşun kendi BCR mirror’ı kurulabiliyor; private modüller için
• Module extensions: Pure modul deklarasyonu yetmeyen senaryolarda (örneğin npm dependency çözmek) module extension yazılır
• Version resolution: Bazel 8, semantic versioning + Minimum Version Selection (MVS) algoritmasıyla dependency çözüyor

WORKSPACE’den Bzlmod’a geçiş, mevcut Bazel projeleri için ciddi bir migration projesi olabiliyor. Bazel ekibi resmi olarak migration_helper araçları sağladı ama büyük projeler 1-3 ay süren bir geçiş projesine ihtiyaç duyuyor. 2026 sonu itibarıyla Bazel ekibi WORKSPACE desteğini tamamen kaldıracak.

Remote Execution ve Remote Caching

Bazel’in en güçlü yanlarından biri, build ve test execution’ı remote worker’lara dağıtabilme kabiliyetidir. Remote Execution API (REAPI) üzerinden Buildbarn, BuildBuddy, EngFlow gibi backend’lerle iletişim kuruluyor. Bu pattern, monorepo’larda dramatik performans iyileşmesi sağlıyor.

Remote Cache, geliştiricinin lokal build’inin sonucunu cluster üzerinde paylaşılan bir cache’e yazıyor. Aynı action başka bir geliştirici tarafından tekrar tetiklenirse, build yapılmadan cache hit alınıyor. Remote Execution ise build’i tamamen remote worker’larda çalıştırıyor; lokal makine sadece koordinasyon yapıyor. Büyük monorepo’larda bu pattern, geliştirici verimliliğini katbekat artırıyor.

Hangi Diller ve Toolchain’ler Destekleniyor

Bazel, multi-language monorepo’lar için tasarlandı. Tek bir repository’de Go, Java, Python, C++, Rust, JavaScript, Swift gibi farklı dillerde kod yazılması ve hepsinin Bazel ile build edilmesi mümkün.

• Java: Native java_library, java_binary, java_test rule’ları; Maven dependency desteği; Bazel ile Maven projelerin hibrit kullanımı
• Go: rules_go (resmi); Gazelle ile BUILD dosyası otomatik üretimi; modul-aware
• Python: rules_python (resmi); pip dependency yönetimi pip_parse ile; py_runtime soyutlaması
• C++: Native cc_library, cc_binary, cc_test; toolchain abstraction ile cross-compilation
• Rust: rules_rust (resmi); Cargo dependency’leri crate_universe ile
• JavaScript/TypeScript: rules_js (yeni nesil); pnpm tabanlı; ts_project ile TypeScript
• Swift: rules_swift; iOS ve macOS build için
• Kotlin: rules_kotlin; Android development desteği

2026 yılı itibarıyla Bazel community’sinin yayımladığı rules_js (JavaScript/TypeScript) artık tüm büyük monorepo’larda standart olarak benimseniyor. Eski rules_nodejs deprecated; rules_js, pnpm’in efficient node_modules layout’unu Bazel build graph’ine entegre ediyor.

Bazel ile CI/CD Pipeline Entegrasyonu

Bazel’in CI/CD entegrasyonu, geleneksel build sistemlerinden farklı bir yaklaşım gerektiriyor. Tüm pipeline, “bazel build //…” veya “bazel test //…” komutlarıyla başlamaz; etkilenen target’ları akıllıca seçmek gerekiyor.

bazel query komutu, hangi target’ların değiştiğini anlamak için kullanılıyor. Pull Request’lerde sadece etkilenen target’ları build/test etmek için “bazel query ‘rdeps(//…, set(‘${changed_files}’))'” pattern’i yaygın olarak kullanılıyor. Bu pattern, monorepo CI sürelerini dramatik biçimde azaltıyor; 10000 target’lı bir monorepo’da tek dosya değişikliği ortalama 5-10 target’ı etkiliyor.

Bazel 8 ile Gelen Performans İyileştirmeleri

Bazel 8 sürümünde birçok performans iyileştirmesi gerçekleştirildi. Aşağıdaki tablo, Bazel 7 ile karşılaştırmalı ölçümleri içeriyor.

Bazel 8’in en önemli iyileştirmelerinden biri Skyframe evaluation engine’in yenilenmesi oldu. Skyframe, Bazel’in incremental computation engine’i ve hangi action’ların re-evaluate edilmesi gerektiğini takip ediyor. Bazel 8 ile Skyframe %18 daha hızlı evaluation yapıyor ve büyük graph’lerde memory consumption belirgin biçimde düştü.

Türkiye’de Kurumsal Bazel Adopsiyonu

Türkiye’de Bazel benimsemesi 2024-2025 döneminde belirgin biçimde arttı. Özellikle 100+ mühendis ekipli teknoloji şirketleri, monorepo stratejisi izlerken Bazel’e yöneldiler.

• Fintech: 2025’te Türkiye’nin en büyük fintech şirketlerinden biri 18 farklı git repo’yu tek Bazel monorepo’sunda konsolide etti
• E-ticaret: Frontend (React) ve backend (Java) kodbase’lerini tek monorepo’da yönetme stratejisi; rules_js + rules_jvm_external
• Telekom: Mikroservis Go ekosistemi; Gazelle ile BUILD dosyası üretimi otomatize edildi
• Otomotiv: C++ ağırlıklı gömülü sistem kodu; cross-compilation toolchain’ler ile multi-target build
• Bankacılık: Hala Maven hakim; pilot Bazel projeleri var ama tam adopsiyon henüz başlamadı

Bir Türkiye fintech şirketinin 18 repo’yu Bazel monorepo’suna konsolide etme projesi, 2025’in Mart ayından Eylül’üne kadar 7 ay sürdü. Migration tamamlandığında dependency yönetimi tek noktada toplandı, cross-team library paylaşımı 12 kat hızlandı ve CI pipeline süreleri ortalama yüzde 65 oranında azaldı.

Kurumsal Bazel Dönüşümünde Tipik Sorunlar

Bazel adopsiyonunda karşılaşılan zorluklar üç grupta toplanabilir.

• BUILD dosyası yazma yükü: Her source directory için BUILD dosyası yazılması başlangıçta yorucu; Gazelle (Go) ve benzeri tool’lar otomatik üretim sağlıyor
• Bzlmod migration: WORKSPACE’den Bzlmod’a geçiş 1-3 ay süren proje olabiliyor; özellikle complex external dependency’lerde
• Remote execution altyapısı: Self-hosted Buildbarn veya BuildBuddy/EngFlow ücretli backend; setup ve maintenance operasyonel yük
• Toolchain’ler: Cross-compilation toolchain konfigürasyonu kompleks; yanlış yapılırsa “lokalde çalışıyor, CI’da çalışmıyor” yaşanıyor
• Developer onboarding: Maven/Gradle/npm gibi familiar araçlardan farklı bir mental model; junior’lar için öğrenme eğrisi dik
• Custom rule yazma: Bazel built-in rule’lar yeterli olmadığında Starlark ile custom rule yazma gerekiyor; bu uzmanlık ister

Uzman Yorumu

Bazel, 5000+ developer ölçeğindeki kuruluşlarda gerçek anlamda transformatif bir araç. Ama unutulmaması gereken bir kural var: Bazel, 100 developer’ın altındaki ekipler için genellikle overkill. Maven veya Gradle’ın sunduğu basitlik, küçük ölçekte daha hızlı sonuç veriyor. Danışmanlık projelerimde Bazel adopsiyonu için üç ön koşul arıyorum. Birincisi: monorepo stratejisi netleşmiş olmalı; multi-repo’da Bazel yatırımının dönüşü zayıf. İkincisi: 50+ developer’ın etkilendiği bir ekosistem olmalı; setup yatırımı küçük ekipte amortize olmuyor. Üçüncüsü: remote execution veya remote cache altyapısına yatırım yapılmaya hazır olunmalı; lokal-only Bazel kazançların yarısını kaybettirir.

— Ömer ÖNAL, Bulut Mimari Danışmanı

SSS

Bazel ne zaman doğru tercih?

Monorepo stratejisi, 50+ developer ekibi, multi-language codebase, deterministik build ihtiyacı, remote execution altyapı kapasitesi olan kuruluşlar için Bazel doğal tercih. Bu kriterlerden çoğu sağlanmıyorsa Maven, Gradle, npm gibi geleneksel araçlar daha pragmatik.

WORKSPACE’den Bzlmod’a geçiş zorunlu mu?

Bazel 9’da WORKSPACE desteği tamamen kalkıyor. 2026 sonuna kadar tüm Bazel kullanıcılarının Bzlmod’a geçişi tamamlamış olması gerekiyor. Geçiş süreci için Bazel ekibi resmi migration helper araçları yayımladı.

Remote execution için en uygun backend hangisi?

Self-hosted Buildbarn (open source) maliyet etkin ama operasyonel yük getiriyor. BuildBuddy ve EngFlow ücretli ama managed hizmet sunuyor; setup hızı ve maintenance kolaylığı için tercih ediliyor. Google Cloud Build (Remote Execution) GCP altyapısında olan kuruluşlar için entegre çözüm.

Bazel ile Docker entegrasyonu nasıl?

rules_oci modern yaklaşım; OCI image format’ında container image üretiyor. Eski rules_docker deprecated. rules_oci, Bazel’in deterministik özelliğinden yararlanarak reproducible container image üretiyor; aynı kaynak her zaman aynı SHA-256 digest’i veriyor.

Bazel hangi cache backend’leri destekliyor?

HTTP cache (basit), gRPC cache (REAPI), AWS S3, Google Cloud Storage, Azure Blob Storage, Buildbarn, BuildBuddy, EngFlow. Kuruluşun mevcut object storage altyapısı uyumlu cache backend seçimini kolaylaştırıyor.

Sonuç

Bazel 8, monorepo build system kategorisinin lider aracı olarak 2026’da konumunu sağlamlaştırdı. Bzlmod’un varsayılan hale gelmesi, Skyframe iyileştirmeleri ve rules_js gibi modern rule set’lerin olgunlaşması platformu daha pragmatik bir seçim haline getiriyor. 5000+ developer ölçeğinde transformatif değer sunan Bazel, doğru koşullarda CI sürelerini yüzde 65’e varan oranlarda azaltabiliyor ve deterministik, hermetic build vaadini production’da gerçekleştirebiliyor. Bazel adopsiyonu için monorepo stratejisi, ekip ölçeği ve remote execution altyapı yatırımı kritik ön koşullar. Doğru koşullarda Bazel, kurumsal yazılım üretkenliğinin yeni standardını belirleyebiliyor.