Menciptakan Ulang Cara Build dan Distribusi .NET (Lagi)
(devblogs.microsoft.com)- Proyek .NET Unified Build adalah sistem build baru yang mengintegrasikan seluruh produk ke dalam bentuk 'repositori monolitik virtual (Virtual Monolithic Repository, VMR)' untuk mengurangi kompleksitas dan inefisiensi struktur build lama berbasis repositori terdistribusi
- Struktur komposisi produk terdistribusi sebelumnya menawarkan independensi dan fleksibilitas tinggi, tetapi menimbulkan beban besar dalam hal manajemen dependensi, konsistensi build, dan kecepatan
- Unified Build memperluas prinsip Source Build untuk distribusi Linux, dengan memperkenalkan tata letak sumber tunggal dan struktur 'build vertikal (Vertical Build)' untuk mempersingkat waktu build dan meningkatkan prediktabilitas
- Melalui aliran kode dua arah (two-way code flow), pengujian skenario, serta peningkatan infrastruktur validasi dan penandatanganan otomatis, sistem ini sekaligus meningkatkan efisiensi pengembang dan kualitas produk
- Sistem ini resmi diperkenalkan di .NET 10 dan telah menghasilkan capaian nyata seperti pemangkasan waktu build (24 jam → kurang dari 7 jam), pengurangan biaya pemeliharaan, dan peningkatan keandalan distribusi
Latar belakang perubahan struktur build .NET
- .NET, dalam proses open-source pada 2015~2016, dikembangkan dengan memisahkan banyak repositori seperti CoreCLR, CoreFX, ASP.NET Core, SDK
- Setiap repositori dibangun dan didistribusikan secara independen, sementara keseluruhan produk disusun melalui graf dependensi
- Pendekatan ini mirip dengan ekosistem OSS, tetapi saat terjadi patch keamanan atau perbaikan darurat, diperlukan koordinasi simultan antartim sehingga waktu penyelesaiannya tidak dapat diprediksi
- Meski memiliki kelebihan pengembangan terdistribusi seperti layering, diferensiasi komunitas, dan pengembangan asinkron, pendekatan ini tidak efisien untuk memastikan konsistensi produk (coherency)
Kompleksitas komposisi produk dan overhead
- Kompleksitas (Complexity): didefinisikan sebagai jumlah tahapan yang diperlukan hingga suatu perubahan sampai ke pelanggan
- Semakin banyak repositori dan node dependensi, semakin banyak waktu dan koordinasi manusia yang dibutuhkan untuk menjaga konsistensi
- Overhead: waktu yang tidak secara langsung menghasilkan artefak yang bisa dikirim ke pelanggan
- Contoh: pembuatan PR, menunggu persetujuan, antrean, pengaturan lingkungan, dll.
- Hasil analisis build runtime .NET 8 menunjukkan bahwa sekitar 38,5% dari total waktu build adalah overhead
- Ketika kompleksitas dan overhead bergabung, efisiensi build menurun tajam dan siklus rilis secara keseluruhan menjadi lebih panjang
Asal-usul Source Build dan Unified Build
- Source Build adalah sistem yang dirancang agar distribusi Linux dapat membangun .NET secara offline dari satu sumber tunggal
- Prinsip implementasi tunggal, platform tunggal, dan lingkungan build tunggal
- Orkestrator build mengelola dependensi dan urutan build tiap komponen
- Source Build dapat melakukan build dalam waktu kurang dari 50 menit berkat kompleksitas rendah dan overhead rendah
- Konsep ini sempat ingin diterapkan juga pada build internal Microsoft, tetapi ada kesulitan seperti kode tertutup, dependensi legacy, dan join lintas platform
- Untuk mengatasinya, diperkenalkan pendekatan seperti paket khusus referensi (source-build-reference-packages), prinsip implementasi tunggal, dan penghapusan join
Tujuan dan desain Unified Build
- Seluruh produk .NET dapat di-build dengan satu commit tunggal
- Semua distribusi per platform dapat dihasilkan dalam satu lingkungan tunggal
- Build dan validasi independen dapat dilakukan juga di luar Microsoft
- Aliran kode dua arah memungkinkan sinkronisasi otomatis perubahan antara VMR dan repositori individual
- Pengujian skenario digunakan untuk memverifikasi fungsi pada tingkat keseluruhan produk
- Struktur build vertikal (Vertical Build) memparalelkan build per platform
- Terdiri dari sekitar 35~40 vertikal build (short/tall stack)
Tahapan implementasi Unified Build
- .NET 7: perancangan konsep dan persetujuan
- .NET 8: perbaikan infrastruktur Source Build dan pembangunan fondasi
- .NET 9: eksperimen build vertikal dan aliran kode
- .NET 10: produk resmi dan diterapkan pada RTM
- Proses build baru diperkenalkan di Preview 4, dan transisi penuh dimulai dari Preview 5
Komponen utama
Virtual Monolithic Repository (VMR)
- Repositori dotnet/dotnet berperan sebagai tata letak sumber tunggal untuk semua komponen
- Pengembang dapat bekerja di repositori individual maupun di VMR, sehingga memperoleh fleksibilitas model terdistribusi dan konsistensi model tunggal secara bersamaan
Vertical Build
- Build dijalankan secara independen untuk tiap platform dan runtime
- Setelah build paralel selesai, hasilnya digabungkan, dan beberapa join diproses lewat pass build tambahan
Code Flow
- Sinkronisasi kode dua arah: repositori komponen → VMR, VMR → repositori komponen
- Status aliran kode terakhir dicatat di
eng/Version.Details.xml - Perubahan dibuat sebagai file patch untuk secara otomatis membuat PR
- Logika penanganan konflik dan pemulihan kesalahan sudah tertanam
Scenario Test Validation
- Selain unit test yang sudah ada, ditambahkan pengujian skenario yang memverifikasi fungsi seluruh produk
- Dijalankan berdasarkan artefak hasil build untuk memperkuat pencegahan regresi dan jaminan kualitas
Hasil dan dampak
- Waktu build lebih singkat: lebih dari 24 jam → kurang dari 7 jam (termasuk penandatanganan)
- Fleksibilitas meningkat: siklus build dan distribusi lebih pendek, perbaikan darurat lebih mudah diterapkan
- Prediktabilitas terjamin: waktu selesainya build setelah perubahan menjadi jelas
- Infrastruktur membaik: alat penandatanganan, log, build paralel, otomatisasi aliran dependensi, dll.
- Source Build untuk distribusi Linux juga selalu dipertahankan dalam kondisi bersih sebelum build
Arah ke depan
- Di .NET 11, direncanakan penerapan otomatisasi aliran kode dan agen pemantauan berbasis AI
- Otomatisasi pelacakan kesalahan dalam proses PR → refleksi ke produk
- Dalam jangka panjang, akan didorong penyederhanaan build dan peningkatan kecepatan melalui penghapusan join point
- Target: build lengkap dalam waktu kurang dari 4 jam
Kesimpulan
- Unified Build, yang mengatasi keterbatasan model build terdistribusi, secara mendasar meningkatkan efisiensi build dan distribusi .NET
- Kemajuan nyata telah dicapai dalam tiga sumbu: pengurangan kompleksitas dan overhead, serta peningkatan konsistensi, kecepatan, dan kualitas
- Mulai .NET 10 RTM, sistem ini diterapkan secara penuh dan akan terus disempurnakan pada versi-versi berikutnya
1 komentar
Komentar Hacker News
Saya sangat menghormati tim .NET
Mereka sering menerbitkan tulisan teknis yang mendalam, dan obsesinya terhadap optimasi performa luar biasa (misalnya evolusi Kestrel dan Entity Framework)
ASP.NET adalah salah satu dari sedikit proyek besar yang tetap bertahan meski mengalami perubahan sebesar Python 2→3
Dulu ia bergantung pada fitur seperti sulap untuk sinkronisasi sesi, tetapi sekarang cara kerjanya sudah benar-benar berbeda
Rasanya menyenangkan mengetahui perusahaan bernilai 3 triliun dolar benar-benar berusaha memperbaiki stack yang saya pakai
Lalu saya menggantinya dengan Dapper dan sistem migrasi buatan sendiri, dan waktu verifikasi DB saat startup serta seeding turun dari 10 detik → kurang dari 2 detik (di hardware kelas bawah + lingkungan SQLite)
Query yang dihasilkan Entity punya terlalu banyak multi-join yang tidak perlu
Belakangan saya sedang beralih ke backend Go yang sederhana, dan .NET hanya dipakai untuk solusi lain
Framework seperti WPF punya banyak masalah sampai perlu hacking Win32
Misalnya, baru di .NET 9 semua antarmuka jaringan dikembalikan dengan benar. Runtime sebelumnya hanya mengekspos NIC yang aktif
Masih ada proyek yang tetap harus mempertahankan dukungan Windows 7
Bahkan di proyek baru pun kadang masih harus memakai .NET 4.8. Misalnya saat membangun formula Excel muncul masalah deadlock async/await
Selain itu fitur integrasi Windows rusak, sehingga pemanggilan jaringan yang sama bisa terautentikasi di 4.8 tetapi gagal di Core
Runtuhnya kompatibilitas mundur di banyak library membuat migrasi tidak mudah
Performanya memang membaik, tetapi dari sisi fitur .NET Framework terasa seperti fosil
Butuh 15 tahun sampai JSON serializer masuk ke standard library, dan dukungan format gambar modern seperti webp atau heic juga belum ada
Visual Studio hampir setiap hari menampilkan pesan crash
Dulu saya penggemar berat .NET, tetapi saya merindukan kepemimpinan Anders
Dalam side project terbaru, saya mengembangkan backend C# REST API di VSCode pada macOS, lalu sudah 3 tahun mendeploy-nya ke Linux
Saya memakai SQLite, EFCore, dan Minimal API, dan rasanya jauh lebih nyaman dibanding frontend saya (NextJS/React/MaterialUI, lebih dari 50 paket npm)
Itu framework API favorit saya secara pribadi
Opsi terbaik berikutnya adalah kombinasi TS + Hono + Zod-OpenApi + SwaggerUI, tetapi pengaturan konteks tipenya agak merepotkan
Saya terkesan bahwa fondasi untuk open source dan cross-platform di .NET ternyata adalah sistem build distro Linux
Jadi dibutuhkan sistem build yang memenuhi kebutuhan mereka, dan pada akhirnya integrasi ke model distro Linux adalah satu-satunya arah yang mungkin
Model ini sederhana, tetapi performanya lebih rendah. Sistem build terdistribusi dengan caching memang lebih cepat, tetapi tidak cocok dengan alur kerja maintainer
Kami menilai mengoptimalkan kesederhanaan lebih baik untuk mendorong partisipasi komunitas
Tujuannya adalah agar komunitas bisa langsung membangun dan mendistribusikannya untuk berbagai platform seperti BSD, S390x, dan lainnya
Jumlah pull request dan hasil positif selama 10 tahun terakhir benar-benar mengejutkan
Saya tidak menyangka tulisan rekayasa perangkat lunak paling mengesankan yang saya baca tahun ini datang dari Microsoft
Saya menyukai versi-versi terbaru .NET, tetapi selama ini saya mengira kekokohannya hanyalah hasil kebetulan
Namun artikel ini menunjukkan upaya sistematis untuk meningkatkan kualitas (termasuk diagram dan contoh pemanfaatan LLM)
Kalaupun nanti investasi seperti ini berkurang, ini tetap contoh yang bagus tentang “bagaimana seharusnya dilakukan”
Orang-orang yang ikut mengerjakan proyek ini pasti mendapat pengalaman yang luar biasa
Artikelnya bagus, tetapi saya rasa tim .NET harus meninggalkan Azure DevOps
Waktu tunggu antrean adalah bottleneck terbesar. Mereka harus menjalankan server build bare metal
Hardware Mac bisa terhubung dan mulai dengan cepat
Kami menyalakan VM bersih baru untuk setiap job demi kepatuhan dan stabilitas
Mempertahankan mesin panas yang sudah siap bisa menghilangkan waktu tunggu, tetapi biayanya terlalu besar
Sulit secara realistis untuk selalu menyiagakan berbagai SKU berbeda, jadi kami mengambil jalan tengah
Saya penasaran mengapa Developer Division di Microsoft berada di level terbaik industri, sementara divisi lain justru menjadi simbol ketidakmampuan dan birokrasi
Setelah Bill pergi, budaya untuk bercermin pada diri sendiri ikut hilang
Saya rasa akar masalahnya adalah cara berpikir berbasis abstraksi yang selalu ingin menyederhanakan sistem kompleks
Daripada mencoba menyelesaikan semuanya di level atas, pendekatan yang membangun dari level bawah bisa menghilangkan jauh lebih banyak masalah secara mendasar
Saat membaca kalimat “membangun 3~4 versi utama dan puluhan band SDK per bulan”, saya jadi penasaran mengapa ada begitu banyak varian
Selain itu, tiap versi membangun SDK/aspnet/runtime untuk berbagai platform seperti x64/arm32/arm64 dan Linux/macOS/Windows
Sebelum Node populer, .NET adalah pilihan yang solid untuk membangun backend (performanya juga lebih baik daripada Node)
Setelah serangan rantai pasok di ekosistem Node belakangan ini, saya berharap banyak pengembang kembali ke platform yang lebih stabil
Perubahan besarnya adalah transisi ke .NET Core, tetapi itu sudah hampir 10 tahun lalu
Pembaruan framework dan dependensi memang agak merepotkan, tetapi jauh lebih mudah dibanding memperbarui proyek React
Berkat siklus LTS yang singkat, tetap up to date tidak terlalu sulit. Dalam siklus pengembangan cepat, perawatan seperti ini memang hal yang wajar
Kenyataannya pasar lebih banyak berisi Node.js, Java, dan low-code (iPaaS)
Meski begitu, kadang saya tetap punya peluang mengusulkan addon C++ karena masalah performa