- Bazel, Google द्वारा बड़े monorepo को कुशलतापूर्वक build करने के लिए विकसित किया गया एक open source build system है
- यह जटिल projects को सटीक और तेज़ी से build करता है, खासकर तब जब बड़े codebase और multi-language dependencies को संभालना हो
- Bazel की मुख्य अवधारणाएँ
- सटीकता-आधारित गति: Bazel build को एक pure function मानता है, जिससे यह सुनिश्चित होता है कि समान input से समान output बने
- कुशल caching: Google जैसे बड़े पैमाने के environment में caching अनिवार्य है, और सटीकता इसे संभव बनाती है
- clean के बिना build: source बदलने के बाद भी "clean build" के बिना स्थिर build संभव
- Bazel का उपयोग कब करें
- उपयोग की सिफारिश
- बड़ा monorepo: जब code lines लाखों में हों और कई भाषाएँ इस्तेमाल हो रही हों
- विभिन्न भाषाओं की dependency management: उदाहरण के लिए Python से model training, Scala से data processing
- तेज़ और सटीक CI/CD की आवश्यकता: development की गति बढ़ाने और conflicts रोकने के लिए
- उपयोग की सिफारिश नहीं
- छोटे projects: जब code lines 1 लाख से कम हों और केवल एक भाषा इस्तेमाल हो
- open source libraries: Bazel distributable artifacts बनाने के लिए उपयुक्त है, लेकिन reusable library distribution के लिए अपेक्षाकृत कमज़ोर
- Bazel अपनाते समय ध्यान देने योग्य बातें
- शुरुआती learning curve ऊँची होती है, और build files लिखने व maintain करने के लिए अतिरिक्त resources चाहिए
- cache server और remote execution configuration जैसी infrastructure setup अनिवार्य है
- Bazel के सफल उदाहरण
- Netflix
- समस्या: 2.5 लाख-3 लाख lines of code वाले repo में CI समय 45 मिनट-1 घंटा लगता था
- समाधान: Bazel अपनाने के बाद build time 20 मिनट से घटकर 6 मिनट हो गया
- प्रभाव: merge conflicts कम हुए, PR processing की गति बेहतर हुई
- Open Systems
- समस्या: धीमा build time और अक्षम workflow
- समाधान: Bazel पर switch करने के बाद feedback loop 20 मिनट से घटकर 5 मिनट हो गया
- सीख: developer training और communication महत्वपूर्ण हैं
- Bazel अपनाने के फायदे और नुकसान
- फायदे
- तेज़ build time: caching और incremental build से speed बेहतर होती है
- सटीकता और reproducibility: जटिल dependency graph को सटीक रूप से व्यक्त करता है
- multi-language integration: Haskell, TypeScript, Python जैसी विभिन्न भाषाओं का समर्थन
- नुकसान
- उच्च adoption cost: शुरुआती setup और learning curve काफ़ी कठिन
- build file management की आवश्यकता: input/output को स्पष्ट रूप से बताना ज़रूरी, और automation tools का उपयोग आवश्यक
- JavaScript और frontend tooling: hot reloading जैसे मौजूदा workflow के साथ compatibility कठिन
- Bazel migration tips
- core team बनाना: Bazel को समझने और configure करने वाले experts सुनिश्चित करें
- training और communication: adoption की शुरुआत में developer education और expectations set करना अनिवार्य
- भाषा-विशिष्ट जटिलता: हर भाषा के लिए build configuration की ज़रूरत अलग होती है
- build file automation: Gazelle जैसे tools का उपयोग
- निष्कर्ष
- Bazel बड़े monorepo और जटिल dependencies को संभालने में बेहतरीन है, लेकिन adoption cost ऊँची है
- यह उन संगठनों के लिए उपयुक्त है जो लाखों lines of code और कई भाषाओं के साथ काम करते हैं
- छोटे projects या gradual transition चाहने की स्थिति में Bazel के बजाय Earthly जैसे विकल्पों पर विचार करें
3 टिप्पणियां
Bazel को अपनाने में विफल रहने के उदाहरणों का भी ज़िक्र हो तो अच्छा रहेगा.
AOSP के मामले में, पिछले कुछ वर्षों के दौरान BazelCon में मौजूदा build system (Soong) से Bazel में migration पर कुछ प्रस्तुतियाँ दी गई थीं.
https://developers.googleblog.com/en/…
लेकिन इस साल के BazelCon में AOSP से जुड़ी सामग्री साझा नहीं की गई है, और AOSP के हालिया build-संबंधित दस्तावेज़ों में यह सूचना आई है कि Bazel migration रोक दिया गया है.
Bazel migration के संदर्भ में AOSP टीम से काफ़ी मदद मिल सकती थी, इसलिए यह तथ्य कि उन्होंने इसे अपनाना छोड़ दिया, मुझे लगता है कि कई महत्वपूर्ण संकेत देता है.
शायद… आपके सॉफ़्टवेयर को Bazel की ज़रूरत नहीं होगी।
हाहा, Earthly में Earthly का विज्ञापन कर रहा है।
Bazel का जोर तेज़ build और तेज़ "test" पर है। test की बात ज़्यादा नहीं है।