- .NET Unified Build projesi, mevcut dağıtık depo tabanlı derleme yapısının karmaşıklığını ve verimsizliğini azaltmak için, ürünün tamamını “sanal tekil depo (Virtual Monolithic Repository, VMR)” biçiminde birleştiren yeni bir derleme sistemi sunuyor
- Mevcut dağıtık ürün bileşimi yaklaşımı bağımsızlık ve esneklik sağlasa da, bağımlılık yönetimi, derleme tutarlılığı ve hız açısından büyük bir yük oluşturuyordu
- Unified Build, Linux dağıtımları için Source Build ilkesini genişleterek tekil bir kaynak yerleşimi ve “dikey derleme (Vertical Build)” yapısını devreye alıyor; böylece derleme sürelerini kısaltıp öngörülebilirlik sağlıyor
- İki yönlü kod akışı (two-way code flow), senaryo testleri, otomatik doğrulama ve imzalama altyapısındaki iyileştirmeler sayesinde geliştirici verimliliği ile ürün kalitesi aynı anda artırılıyor
- .NET 10 ile resmi olarak devreye alınan bu sistem, derleme süresinin kısaltılması (24 saat → 7 saatin altı), bakım maliyetinin azaltılması ve dağıtım güvenilirliğinin artırılması gibi somut sonuçlar üretti
.NET derleme yapısındaki değişimin arka planı
- .NET, 2015~2016 dönemindeki açık kaynaklaştırma sürecinde CoreCLR, CoreFX, ASP.NET Core, SDK gibi birçok depoya ayrılarak geliştirildi
- Her depo bağımsız olarak derlenip dağıtılırken, ürünün tamamı bir bağımlılık grafiği üzerinden bir araya getiriliyordu
- Bu yaklaşım OSS ekosistemine benziyor olsa da, güvenlik yamaları veya acil düzeltmeler gerektiğinde birden fazla ekibin eşzamanlı koordinasyonunu zorunlu kıldığı için zamanın öngörülemez hale gelmesi sorununu doğuruyordu
- Dağıtık geliştirmenin avantajlarına rağmen (katmanlama, topluluğun ayrışması, asenkron geliştirme vb.), ürün tutarlılığını (coherency) sağlamak açısından verimsizdi
Ürün bileşimi karmaşıklığı ve ek yük
- Karmaşıklık (Complexity): Bir değişikliğin müşteriye ulaşması için gereken adım sayısı olarak tanımlanıyor
- Depo ve bağımlılık düğümü sayısı arttıkça, tutarlılığı sağlamak için daha fazla zaman ve insan koordinasyonu gerekiyor
- Ek yük (Overhead): Müşteriye teslim edilebilir çıktıları doğrudan üretmeyen zaman
- Örnek: PR oluşturma, onay bekleme, kuyruğa alma, ortam yapılandırması vb.
- .NET 8 runtime derleme analizine göre, toplam derleme süresinin yaklaşık %38,5’i ek yükten oluşuyordu
- Karmaşıklık ve ek yük birleştiğinde derleme verimliliği hızla düşüyor ve toplam sürüm döngüsü uzuyordu
Source Build ve Unified Build’in kökeni
- Source Build, Linux dağıtımlarının .NET’i tek bir kaynaktan çevrimdışı derleyebilmesi için tasarlanmış bir sistemdir
- Tek uygulama, tek platform, tek derleme ortamı ilkeleri
- Derleme orkestratörü, her bileşenin bağımlılıklarını ve derleme sırasını yönetir
- Source Build, düşük karmaşıklık ve düşük ek yük ile 50 dakika içinde derleme yapabiliyordu
- Microsoft, bu kavramı dahili derlemelerde de uygulamak istedi ancak kapalı kaynak, eski bağımlılıklar ve platformlar arası join gibi nedenlerle zorluklar vardı
- Bunu çözmek için yalnızca başvuru amaçlı paketler (source-build-reference-packages), tek uygulama ilkesi ve join noktalarını kaldırma gibi yaklaşımlar benimsendi
Unified Build’in hedefleri ve tasarımı
- Tek bir commit ile tüm .NET ürününü derleyebilmek
- Tüm platformlara yönelik dağıtımları tek bir ortamda üretebilmek
- Microsoft dışından da bağımsız derleme ve doğrulama yapılabilmesi
- İki yönlü kod akışı ile VMR ve ayrı bileşen depoları arasındaki değişiklikleri otomatik eşitlemek
- Senaryo testleri ile ürünün tamamı düzeyinde işlev doğrulaması yapmak
- Dikey derleme (Vertical Build) yapısıyla platform bazlı derlemeleri paralelleştirmek
- Yaklaşık 35~40 derleme dikeyinden (short/tall stack) oluşuyor
Unified Build’in hayata geçirilme aşamaları
- .NET 7: Kavram tasarımı ve onay
- .NET 8: Source Build altyapısının iyileştirilmesi ve temel hazırlık
- .NET 9: Dikey derleme ve kod akışı deneyleri
- .NET 10: Resmi ürünleştirme ve RTM’e yansıtma
- Preview 4’te yeni derleme süreci devreye alındı, Preview 5’ten itibaren tamamen geçildi
Ana bileşenler
Virtual Monolithic Repository (VMR)
- dotnet/dotnet deposu, tüm bileşenler için tekil kaynak yerleşimi işlevi görüyor
- Geliştiriciler ister ayrı depolarda ister VMR içinde çalışabiliyor; böylece dağıtık yapının esnekliği ile tekil yapının tutarlılığı aynı anda korunuyor
Vertical Build
- Her platform ve runtime için bağımsız derleme yürütülüyor
- Paralel derlemelerin ardından sonuçlar birleştiriliyor; bazı join işlemleri ek derleme geçişleriyle ele alınıyor
Code Flow
- İki yönlü kod senkronizasyonu: bileşen deposu → VMR, VMR → bileşen deposu
eng/Version.Details.xml içinde son kod akışı durumu kaydediliyor- Değişiklikler patch dosyaları olarak oluşturulup otomatik PR açılıyor
- Çakışma yönetimi ve hata kurtarma mantığı yerleşik olarak bulunuyor
Scenario Test Validation
- Mevcut birim testlerine ek olarak, ürünün genel işlevini doğrulayan senaryo testleri eklendi
- Bunlar derleme çıktıları temel alınarak çalıştırılıyor; böylece regresyon önleme ve kalite güvencesi güçleniyor
Sonuçlar ve etkiler
- Derleme süresi kısaldı: 24 saatin üzeri → 7 saatin altı (imzalama dahil)
- Esneklik arttı: Derleme ve dağıtım döngüsü kısaldı, acil düzeltmeleri yansıtmak kolaylaştı
- Öngörülebilirlik sağlandı: Değişiklik sonrası derlemenin ne zaman tamamlanacağı netleşti
- Altyapı iyileşti: İmzalama araçları, loglar, paralel derleme, bağımlılık akışının otomasyonu vb.
- Linux dağıtımları için Source Build de her zaman önceden derlenmiş kalıntılardan arındırılmış durumda tutuluyor
Gelecek yönelim
- .NET 11’de kod akışı otomasyonu ve yapay zeka tabanlı izleme ajanlarının devreye alınması planlanıyor
- PR → ürüne yansıtma sürecindeki hata takibinin otomasyonu
- Uzun vadede join noktalarının kaldırılması ile derlemenin sadeleştirilmesi ve hızlandırılması hedefleniyor
- Hedef: 4 saat içinde tam derleme
Sonuç
- Dağıtık derleme modelinin sınırlarını aşan Unified Build, .NET’in derleme ve dağıtım verimliliğini kökten iyileştiriyor
- Karmaşıklık ve ek yükün azaltılması, tutarlılık, hız ve kalitenin artırılması olmak üzere üç eksende somut ilerleme sağlandı
- Bu sistem .NET 10 RTM’den itibaren tamamen uygulanıyor ve sonraki sürümlerde de sürekli iyileştirilmesi planlanıyor
1 yorum
Hacker News görüşleri
.NET ekibine gerçekten büyük saygı duyuyorum
Sık sık derinlikli teknik yazılar yayımlıyorlar ve performans optimizasyonuna takıntı derecesinde önem veriyorlar (ör. Kestrel, Entity Framework'ün gelişimi)
ASP.NET, Python 2→3 düzeyindeki büyük değişime rağmen hayatta kalmayı başaran az sayıdaki büyük projeden biri
Eskiden oturum senkronizasyonu için sihir gibi çalışan özelliklere dayanıyordu ama artık tamamen farklı bir şekilde çalışıyor
3 trilyon dolarlık bir şirketin kullandığım stack'i gerçekten iyileştirmeye çalışması güzel hissettiriyor
Bu yüzden onu Dapper ve kendi yazdığım migration sistemiyle değiştirdim; başlangıçta DB doğrulama ve seeding süresi 10 saniyeden 2 saniyenin altına düştü (düşük özellikli donanım + SQLite ortamında)
Entity'nin ürettiği sorgularda gereksiz çoklu join'ler vardı
Bugünlerde daha basit bir Go backend'ine geçiyorum ve .NET'i yalnızca diğer çözümler için kullanıyorum
WPF gibi framework'lerde, Win32 hack'leri gerektirecek kadar çok sorun vardı
Örneğin ancak .NET 9 ile tüm ağ arayüzlerini düzgün şekilde döndürüyor. Önceki runtime'lar yalnızca etkin NIC'leri gösteriyordu
Hâlâ Windows 7 desteğini sürdürmek zorunda olan projeler var
Yeni projelerde bile hâlâ .NET 4.8 kullanmak zorunda kaldığınız durumlar oluyor. Örneğin Excel formülü derlerken async/await deadlock sorunu yaşanıyor
Ayrıca Windows entegrasyonu bozuluyor; aynı ağ çağrısı 4.8'de kimlik doğrularken Core'da başarısız oluyor
Sayısız kütüphanede geriye dönük uyumluluğun bozulması yüzünden migration kolay değil
Performans iyileşti ama özellikler açısından .NET Framework fosilleşmiş gibi hissettiriyor
JSON serializer'ın standart kütüphaneye eklenmesi 15 yıl sürdü ve webp ya da heic gibi modern görsel formatlarına da destek yok
Visual Studio neredeyse her gün çökme mesajı gösteriyor
Eskiden koyu bir .NET hayranıydım ama Anders'in liderliğini özlüyorum
Son dönemde bir yan projede macOS üzerindeki VSCode ile C# REST API backend'i geliştiriyorum ve 3 yıldır Linux'a deploy ediyorum
SQLite, EFCore ve Minimal API kullanıyorum; frontend'den (NextJS/React/MaterialUI, 50'den fazla npm paketi) çok daha rahat
Şahsen en sevdiğim API framework'ü
İkinci seçenek olarak TS + Hono + Zod-OpenApi + SwaggerUI kombinasyonu iyi, ama type context ayarı biraz uğraştırıyor
.NET'in açık kaynaklaşması ve çapraz platforma taşınması için temelin Linux dağıtımlarının build sisteminden gelmiş olması etkileyiciydi
Bu yüzden onların gereksinimlerini karşılayan bir build sistemine ihtiyaç vardı ve sonuçta Linux dağıtımı modeli etrafında birleşmek tek gerçekçi yoldu
Bu model basit ama performansı daha düşük. Cache'li dağıtık build sistemleri daha hızlı olurdu ama bakımcıların iş akışına uymuyor
Topluluk katılımını teşvik etmek için sadeliği optimize etmenin daha doğru olduğuna karar verdik
Amaç, BSD, S390x ve diğer çeşitli platformlar için build ve dağıtımın doğrudan topluluk tarafından yapılabilmesi
Son 10 yıldaki pull request ve olumlu çıktılar gerçekten şaşırtıcı düzeyde
Bu yıl okuduğum yazılar arasında en etkileyici yazılım mühendisliği yazısının Microsoft'tan geleceğini beklemiyordum
.NET'in son sürümlerini seviyorum ama bu sağlamlığın tesadüfen ortaya çıktığını düşünüyordum
Oysa bu yazı, kaliteyi artırmaya yönelik sistematik çabayı gösteriyor (diyagramlar ve LLM kullanım örnekleri dahil)
İleride bu tür yatırımlar azalsa bile, bu yazı “nasıl yapılmalı” sorusuna iyi bir örnek
Bu projeye katılan insanlar gerçekten inanılmaz bir deneyim yaşamış olmalı
Yazı iyiydi ama .NET ekibinin Azure DevOps'tan vazgeçmesi gerektiğini düşünüyorum
En büyük darboğaz kuyrukta bekleme süresi. Bare-metal build sunucuları kullanmaları gerek
Mac donanımı hızlıca bağlanıp başlıyor
Biz her iş için uyumluluk ve kararlılık sağlamak amacıyla yeni bir temiz VM ayağa kaldırıyoruz
Önceden hazırlanmış sıcak makineleri hazır tutmak bekleme süresini sıfırlayabilir ama maliyeti çok yüksek
Farklı SKU'ları sürekli hazır bekletmek pratikte zor olduğu için bir ödünleşim yapıyoruz
Microsoft'un Developer Division'ı sektörün en iyileri arasındayken, şirketin geri kalanının nasıl beceriksizlik ve bürokrasinin simgesi hâline geldiğini merak ediyorum
Bill gittikten sonra şirketin kendine bakma kültürü kayboldu
Karmaşık sistemleri sadeleştirmeye çalışan soyutlama merkezli düşünce biçiminin sorunun kökü olduğunu düşünüyorum
Her şeyi üst seviyede çözmeye çalışmak yerine, alt seviyeden başlayıp yukarı doğru inşa eden yaklaşım birçok sorunu daha kökten ortadan kaldırabilir
“Ayda 3-4 büyük sürüm ve onlarca SDK band'ı build ediyoruz” cümlesini görünce neden bu kadar çok varyant olduğunu merak ettim
Ayrıca her sürümde SDK/aspnet/runtime; x64/arm32/arm64, Linux/macOS/Windows gibi farklı platformlar için build ediliyor
Node popüler olmadan önce .NET, backend geliştirme için sağlam bir seçenekti (performansı da Node'dan iyiydi)
Node ekosistemindeki son tedarik zinciri saldırılarından sonra, birçok geliştiricinin daha istikrarlı platformlara dönmesini umuyorum
Büyük değişim .NET Core'a geçişti ama bu neredeyse 10 yıl önceydi
Framework ve bağımlılık güncellemeleri biraz zahmetli olabiliyor ama React projelerini güncellemeye kıyasla çok daha kolay
Kısa LTS döngüsü sayesinde güncel kalmak zor değil. Hızlı geliştirme döngülerinde bu tür bakım zaten işin doğal parçası
Gerçekte ise işler daha çok Node.js, Java ve low-code (iPaaS) etrafında dönüyor
Yine de performans sorunları sayesinde ara sıra C++ addon önermeye fırsat çıkıyor