.NET build और deployment तरीके का पुनराविष्कार (फिर से)

 (devblogs.microsoft.com)
1 पॉइंट द्वारा GN⁺ 2025-11-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • .NET Unified Build प्रोजेक्ट मौजूदा distributed repository-आधारित build संरचना की जटिलता और अक्षमता को कम करने के लिए पूरे प्रोडक्ट को ‘Virtual Monolithic Repository (VMR)’ के रूप में एकीकृत करने वाली नई build प्रणाली है
  • मौजूदा distributed product composition model स्वतंत्रता और लचीलापन तो बढ़ाता है, लेकिन dependency management·build consistency·speed के लिहाज़ से बड़ा बोझ पैदा करता है
  • Unified Build, Linux distribution के लिए Source Build के सिद्धांतों का विस्तार करते हुए single source layout और ‘Vertical Build’ संरचना अपनाता है, जिससे build time घटता है और predictability मिलती है
  • two-way code flow, scenario testing, automated validation और signing infrastructure improvements के जरिए developer efficiency और product quality दोनों में सुधार किया गया
  • .NET 10 में आधिकारिक रूप से अपनाई गई इस प्रणाली ने build time reduction (24 घंटे→7 घंटे से कम), maintenance cost reduction, और deployment reliability improvement जैसे ठोस परिणाम हासिल किए

.NET build संरचना में बदलाव की पृष्ठभूमि

  • .NET को 2015~2016 के open source बनने की प्रक्रिया में CoreCLR, CoreFX, ASP.NET Core, SDK जैसे कई repositories में अलग करके विकसित किया गया
  • हर repository स्वतंत्र रूप से build और deploy होती थी, और पूरा प्रोडक्ट dependency graph के जरिए जोड़ा जाता था
  • यह तरीका OSS ecosystem जैसा था, लेकिन security patch या emergency fix के समय कई टीमों के समन्वय की ज़रूरत होने से time predictability की समस्या पैदा होती थी
  • distributed development के फ़ायदे (layering, community separation, asynchronous development आदि) होने के बावजूद, product coherency बनाए रखने में यह अक्षम था

प्रोडक्ट composition की जटिलता और overhead

  • Complexity: इसे उन चरणों की संख्या के रूप में परिभाषित किया गया है, जो किसी बदलाव को ग्राहक तक पहुँचने के लिए चाहिए
    • repository और dependency node जितने ज़्यादा होंगे, consistency बनाए रखने के लिए उतना ही अधिक समय और मानवीय समन्वय चाहिए होगा
  • Overhead: वह समय जो सीधे ग्राहक तक पहुँचने योग्य output बनाने में नहीं लगता
    • उदाहरण: PR बनाना, approval का इंतज़ार, queueing, environment setup आदि
  • .NET 8 runtime build के विश्लेषण में पाया गया कि कुल build time का लगभग 38.5% overhead था
  • जब complexity और overhead साथ आते हैं, तो build efficiency तेज़ी से गिरती है और पूरा release cycle लंबा हो जाता है

Source Build और Unified Build की उत्पत्ति

  • Source Build ऐसा सिस्टम है जिसे Linux distribution को .NET को single source से offline build करने में सक्षम बनाने के लिए डिज़ाइन किया गया था
    • single implementation, single platform, single build environment के सिद्धांत
    • build orchestrator हर component की dependency और build order को manage करता है
  • Source Build, कम complexity·कम overhead के साथ 50 मिनट के भीतर build कर सकता है
  • Microsoft ने इस concept को internal build पर भी लागू करने की कोशिश की, लेकिन closed source·legacy dependencies·platforms के बीच join जैसी कठिनाइयाँ थीं
  • इन्हें हल करने के लिए reference-only packages (source-build-reference-packages), single implementation principle, और join removal जैसे तरीक़े अपनाए गए

Unified Build के लक्ष्य और डिज़ाइन

  • एक single commit से पूरे .NET product का build संभव हो
  • सभी platform-specific distributions को एक single environment में generate किया जा सके
  • Microsoft के बाहर भी स्वतंत्र build और validation संभव हो
  • two-way code flow के जरिए VMR और individual repositories के बीच बदलावों का automatic synchronization
  • scenario testing के जरिए पूरे product स्तर पर functionality validation
  • Vertical Build संरचना के जरिए platform-specific builds को parallelize करना
    • लगभग 35~40 build verticals (short/tall stack) से मिलकर बना

Unified Build के implementation चरण

  • .NET 7: concept design और approval
  • .NET 8: Source Build infrastructure में सुधार और foundation तैयार
  • .NET 9: Vertical Build और code flow पर प्रयोग
  • .NET 10: आधिकारिक productization और RTM में समावेश
    • Preview 4 में नया build process लागू, Preview 5 से पूर्ण transition

प्रमुख components

Virtual Monolithic Repository (VMR)

  • dotnet/dotnet repository सभी components के single source layout की भूमिका निभाती है
  • developer individual repository या VMR, दोनों में काम कर सकते हैं, जिससे distributed model की flexibility और monolithic model की consistency साथ मिलती है

Vertical Build

  • हर platform और runtime के लिए स्वतंत्र build किया जाता है
  • parallel build के बाद परिणामों को integrate किया जाता है, और कुछ join अतिरिक्त build pass में संभाले जाते हैं

Code Flow

  • दो-तरफ़ा code synchronization: component repository → VMR, VMR → component repository
  • eng/Version.Details.xml में अंतिम code flow स्थिति दर्ज होती है
  • बदलावों को patch file के रूप में बनाकर automated PR तैयार किया जाता है
  • conflict handling और error recovery logic built-in है

Scenario Test Validation

  • मौजूदा unit test के अलावा पूरे product functionality को validate करने वाले scenario tests जोड़े गए
  • ये build outputs के आधार पर चलते हैं, जिससे regression रोकथाम और quality assurance मज़बूत होते हैं

परिणाम और प्रभाव

  • build time में कमी: 24 घंटे से अधिक → 7 घंटे से कम (signing सहित)
  • लचीलापन बढ़ा: build·deployment cycle छोटा, emergency fixes शामिल करना आसान
  • predictability में सुधार: बदलाव के बाद build पूरा होने का समय स्पष्ट
  • infrastructure improvements: signing tools, logs, parallel build, dependency flow automation आदि
  • Linux distribution के लिए Source Build भी हमेशा pre-build clean स्थिति में बना रहता है

आगे की दिशा

  • .NET 11 में code flow automation और AI-आधारित monitoring agents लाने की योजना है
    • PR→product integration प्रक्रिया में error tracking automation
  • लंबी अवधि में join points हटाकर build को सरल और तेज़ बनाने की दिशा में काम होगा
    • लक्ष्य: 4 घंटे के भीतर complete build

निष्कर्ष

  • distributed build model की सीमाओं को पार करने वाला Unified Build .NET की build·deployment efficiency को मूल रूप से बेहतर बनाता है
  • complexity·overhead में कमी, consistency·speed·quality में सुधार इन तीनों आयामों में ठोस प्रगति हासिल हुई
  • .NET 10 RTM से यह प्रणाली पूरी तरह लागू हो चुकी है, और आगे के versions में भी इसमें लगातार सुधार होगा

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-11-28
Hacker News राय

  • मैं .NET टीम का सच में बहुत सम्मान करता हूँ
    वे अक्सर गहराई वाली तकनीकी पोस्ट लिखते हैं, और performance optimization को लेकर उनका जुनून कमाल का है (जैसे Kestrel, Entity Framework का विकास)
    ASP.NET उन कुछ बड़े प्रोजेक्ट्स में से एक है जो Python 2→3 स्तर के बड़े बदलाव के बाद भी बचा रहा
    पहले यह session synchronization के लिए किसी जादुई फीचर पर निर्भर करता था, लेकिन अब यह पूरी तरह अलग तरीके से काम करता है
    अच्छा लगता है कि 3 ट्रिलियन डॉलर की कंपनी उस stack को सच में बेहतर बनाने की कोशिश कर रही है जिसका मैं इस्तेमाल करता हूँ

    • मैंने पहले Entity Framework इस्तेमाल किया था, और यह बहुत धीमा था
      इसलिए मैंने इसे Dapper और अपने बनाए migration system से बदल दिया, और startup पर DB validation और seeding time 10 सेकंड → 2 सेकंड से कम हो गया (लो-एंड हार्डवेयर + SQLite वातावरण में)
      Entity जो queries बनाता था उनमें बेवजह बहुत सारे multiple joins होते थे
      इन दिनों मैं एक साधारण Go backend की ओर जा रहा हूँ, और .NET का इस्तेमाल सिर्फ दूसरे solutions में करता हूँ
      WPF जैसे framework इतने समस्याग्रस्त थे कि Win32 hacks की जरूरत पड़ती थी
      उदाहरण के लिए, .NET 9 में जाकर ही यह सभी network interfaces सही तरह लौटाता है। पुराने runtimes केवल active NICs दिखाते थे
      अभी भी कुछ प्रोजेक्ट हैं जिनमें Windows 7 support बनाए रखना पड़ता है
    • मुझे लगता है कि बहुत से प्रोजेक्ट .NET Core में माइग्रेट नहीं हो पाए और पीछे छूट गए
      नए प्रोजेक्ट्स में भी कभी-कभी अब तक .NET 4.8 इस्तेमाल करना पड़ता है। उदाहरण के लिए, Excel formulas बनाते समय async/await deadlock समस्या आती है
      साथ ही Windows integration फीचर्स टूट जाते हैं, इसलिए वही network call 4.8 में authenticate हो जाती है लेकिन Core में फेल हो जाती है
      अनगिनत libraries में backward compatibility के टूटने की वजह से migration आसान नहीं है
      performance बेहतर हुई है, लेकिन features के मामले में .NET Framework एक fossil जैसा लगता है
      JSON serializer को standard library में जुड़ने में 15 साल लग गए, और webp या heic जैसे आधुनिक image formats का support भी नहीं है
      Visual Studio लगभग हर दिन crash message दिखाता है
      मैं पहले .NET का बहुत बड़ा fan था, लेकिन अब Anders की leadership याद आती है

  • हाल की एक side project में मैं macOS पर VSCode से C# REST API backend बना रहा हूँ, और पिछले 3 साल से उसे Linux पर deploy कर रहा हूँ
    मैं SQLite, EFCore, Minimal API इस्तेमाल करता हूँ, और यह frontend (NextJS/React/MaterialUI, 50 से ज्यादा npm packages) की तुलना में कहीं ज्यादा सुखद है

    • अगर API थोड़ी जटिल हो जाए तो मैं FastEndpoints library की सिफारिश करूँगा
      यह व्यक्तिगत रूप से मेरा पसंदीदा API framework है
      दूसरा विकल्प TS + Hono + Zod-OpenApi + SwaggerUI का संयोजन है, लेकिन type context सेटअप थोड़ा झंझट वाला है

  • यह बात प्रभावशाली लगी कि .NET के open source और cross-platform बनने की नींव Linux distribution build systems थे

    • अगर मैं, इस लेख का लेखक, सीधे समझाऊँ, तो distribution maintainers को .NET को native package feeds में शामिल करने देने के लिए उन्हें इसे खुद build करने में सक्षम होना था
      इसलिए उनके requirements को पूरा करने वाला build system चाहिए था, और अंत में Linux distribution model में एकीकरण ही एकमात्र रास्ता था
      यह model सरल है, लेकिन performance कम देता है। caching वाला distributed build system ज्यादा तेज़ होता, लेकिन maintainers के workflow से मेल नहीं खाता
      हमें लगा कि simplicity को optimize करना community participation बढ़ाने के लिए बेहतर है
      लक्ष्य यह है कि community खुद BSD, S390x और कई दूसरे platforms के लिए build और distribution कर सके
    • मुझे लगता है कि .NET अब open source में जाने के फैसले पर पछताने के चरण से बहुत आगे निकल चुका है
      पिछले 10 सालों में pull requests और सकारात्मक नतीजों की मात्रा हैरान करने वाली रही है

  • इस साल पढ़े गए लेखों में यह सबसे प्रभावशाली software engineering लेख था, और मैंने नहीं सोचा था कि यह Microsoft से आएगा
    मुझे .NET के हालिया versions पसंद हैं, लेकिन मैं समझता था कि उसकी मजबूती बस संयोग का परिणाम है
    मगर इस लेख ने quality सुधारने के लिए व्यवस्थित प्रयास दिखाया (diagrams, यहाँ तक कि LLM उपयोग के उदाहरण सहित)
    आगे चलकर अगर ऐसे investments कम भी हो जाएँ, तब भी यह “कैसे करना चाहिए” का अच्छा उदाहरण है

  • इस प्रोजेक्ट में शामिल लोगों के लिए यह वाकई शानदार अनुभव रहा होगा

  • लेख अच्छा था, लेकिन मुझे लगता है कि .NET टीम को Azure DevOps छोड़ देना चाहिए
    queue waiting time सबसे बड़ा bottleneck है। उन्हें bare-metal build servers चलाने चाहिए

    • Azure DevOps खुद समस्या नहीं है। यह bare metal पर भी चलता है
      Mac hardware जल्दी attach होकर शुरू हो जाता है
      हम compliance और stability के लिए हर job पर एक clean VM नया शुरू करते हैं
      पहले से तैयार hot machines बनाए रखने से waiting time खत्म हो सकता है, लेकिन cost बहुत ज्यादा है
      अलग-अलग SKUs को हमेशा standby में रखना व्यावहारिक नहीं है, इसलिए समझौता करना पड़ता है

  • मैं सोचता हूँ कि Microsoft की Developer Division इंडस्ट्री में सर्वश्रेष्ठ स्तर की कैसे है, जबकि बाकी divisions अयोग्यता और bureaucracy का प्रतीक बन गए

    • इसकी वजह राजनीतिक कारण और इंडस्ट्री leaders का अंधानुकरण है
      Bill के जाने के बाद आत्मचिंतन की संस्कृति गायब हो गई

  • मुझे लगता है कि जटिल systems को सरल बनाने की abstraction-केंद्रित सोच ही समस्या की जड़ है
    ऊपरी स्तर पर सब कुछ हल करने की कोशिश करने के बजाय, निचले स्तर से बनाते हुए ऊपर जाना कई समस्याओं को जड़ से खत्म कर सकता है

  • “हम हर महीने 3~4 major versions और दर्जनों SDK bands build करते हैं” यह पढ़कर मैं सोचने लगा कि इतने variants क्यों हैं

    • अभी .NET 8(LTS), .NET 9(standard support), और .NET 10(LTS) एक साथ maintain किए जा रहे हैं
      साथ ही हर version के लिए SDK/aspnet/runtime को x64/arm32/arm64, Linux/macOS/Windows जैसे कई platforms पर build किया जाता है

  • Node के लोकप्रिय होने से पहले, .NET backend builds के लिए एक मजबूत विकल्प था (और performance भी Node से बेहतर थी)
    हाल में Node ecosystem में हुई supply-chain attacks के बाद, उम्मीद है कि बहुत से developers फिर से स्थिर platforms की ओर लौटेंगे

    • मैं जानना चाहता हूँ कि “churn” से क्या मतलब है। यह लेख तो internal build system के बारे में है, इसका अस्थिरता से क्या संबंध है, समझ नहीं आता
    • .NET अब भी शानदार है और हर release के साथ बेहतर हो रहा है
      बड़ा बदलाव .NET Core की ओर transition था, लेकिन वह लगभग 10 साल पहले की बात है
    • C# + JetBrains Rider का संयोजन मेरे career का सबसे संतोषजनक development experience रहा है
    • .NET Core 3 के बाद से मुझे शायद ही कोई बड़ी compatibility समस्या मिली है
      framework और dependencies को update करना थोड़ा झंझट भरा है, लेकिन React project updates की तुलना में काफी आसान है
      छोटे LTS cycle की वजह से up-to-date रहना मुश्किल नहीं है। तेज़ development cycle में ऐसी maintenance सामान्य बात है
    • एक multi-language consultant के रूप में, मैं चाहता हूँ कि .NET से जुड़े RFPs ज्यादा दिखें
      हकीकत में ज़्यादातर काम Node.js, Java, और low-code(iPaaS) के इर्द-गिर्द है
      फिर भी performance समस्याओं की वजह से कभी-कभी C++ addons सुझाने का मौका मिल जाता है