हर्मिटिटी

Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

इस पेज पर, हर्मेटिकिटी, हर्मेटिक बिल्ड इस्तेमाल करने के फ़ायदों, और बिल्ड में नॉन-हर्मेटिक व्यवहार की पहचान करने की रणनीतियों के बारे में बताया गया है.

खास जानकारी

एक हर्मेटिक बिल्ड सिस्टम, एक ही इनपुट सोर्स कोड और प्रॉडक्ट कॉन्फ़िगरेशन दिए जाने पर हमेशा एक जैसा आउटपुट देता है. ऐसा इसलिए, क्योंकि यह बिल्ड को होस्ट सिस्टम में हुए बदलावों से अलग रखता है.

बिल्ड को अलग करने के लिए, हर्मेटिक बिल्ड, लाइब्रेरी और स्थानीय या रिमोट होस्ट मशीन पर इंस्टॉल किए गए अन्य सॉफ़्टवेयर के लिए संवेदनशील नहीं होते हैं. ये कंपाइलर जैसे बिल्ड टूल के खास वर्शन और लाइब्रेरी जैसी डिपेंडेंसी पर निर्भर होते हैं. इससे बिल्ड प्रोसेस अपने-आप पूरी हो जाती है, क्योंकि यह बिल्ड एनवायरमेंट के बाहर की सेवाओं पर निर्भर नहीं होती है.

हर्मेटिकिटी के दो अहम पहलू ये हैं:

  • आइसोलेशन: हर्मेटिक बिल्ड सिस्टम, टूल को सोर्स कोड के तौर पर इस्तेमाल करते हैं. वे टूल की कॉपी डाउनलोड करते हैं. साथ ही, मैनेज किए गए फ़ाइल ट्री में अपने स्टोरेज और इस्तेमाल को मैनेज करते हैं. इससे होस्ट मशीन और स्थानीय उपयोगकर्ता के बीच आइसोलेशन बनता है. इसमें भाषाओं के इंस्टॉल किए गए वर्शन भी शामिल हैं.
  • सोर्स की पहचान: हर्मेटिक बिल्ड सिस्टम, इनपुट के एक जैसे होने की पुष्टि करते हैं. Git जैसी कोड रिपॉज़िटरी, कोड में हुए बदलावों के सेट की पहचान एक यूनीक हैश कोड से करती हैं. हर्मेटिक बिल्ड सिस्टम, इस हैश का इस्तेमाल करके बिल्ड के इनपुट में हुए बदलावों की पहचान करते हैं.

फ़ायदे

हर्मेटिक बिल्ड के मुख्य फ़ायदे ये हैं:

  • स्पीड: किसी कार्रवाई के आउटपुट को कैश मेमोरी में सेव किया जा सकता है. साथ ही, इनपुट में बदलाव होने पर ही कार्रवाई को फिर से चलाने की ज़रूरत होती है.
  • पैरलल एक्ज़ीक्यूशन: दिए गए इनपुट और आउटपुट के लिए, बिल्ड सिस्टम सभी कार्रवाइयों का ग्राफ़ बना सकता है, ताकि असरदार और पैरलल एक्ज़ीक्यूशन का हिसाब लगाया जा सके. बिल्ड सिस्टम, नियमों को लोड करता है. साथ ही, कैश मेमोरी में खोजने के लिए, ऐक्शन ग्राफ़ और हैश इनपुट का हिसाब लगाता है.
  • कई बिल्ड: एक ही मशीन पर कई हर्मेटिक बिल्ड बनाए जा सकते हैं. हर बिल्ड में अलग-अलग टूल और वर्शन का इस्तेमाल किया जाता है.
  • दोहराने की क्षमता: हर्मेटिक बिल्ड, समस्याओं को हल करने के लिए बेहतर होते हैं. ऐसा इसलिए, क्योंकि आपको उन शर्तों के बारे में सटीक जानकारी होती है जिनकी वजह से बिल्ड तैयार हुआ है.

यह पता लगाना कि क्या क्वेरी के नतीजे, इनपुट डेटा के हिसाब से तय किए गए हैं या नहीं

अगर आपको Bazel पर स्विच करना है, तो पहले से मौजूद बिल्ड की हर्मेटिसिटी को बेहतर बनाने से, माइग्रेशन करना आसान हो जाता है. बिल्ड में हर्मेटिक न होने की कुछ सामान्य वजहें ये हैं:

  • .mk फ़ाइलों में मनमुताबिक प्रोसेसिंग
  • ऐसी कार्रवाइयां या टूल जो फ़ाइलों को नॉन-डिटरमिनिस्टिक तरीके से बनाते हैं. इनमें आम तौर पर, बिल्ड आईडी या टाइमस्टैंप शामिल होते हैं
  • सिस्टम बाइनरी, जो अलग-अलग होस्ट पर अलग-अलग होती हैं. जैसे, /usr/bin बाइनरी, ऐब्सलूट पाथ, और नेटिव C++ नियमों के अपने-आप कॉन्फ़िगर होने के लिए सिस्टम C++ कंपाइलर
  • बिल्ड के दौरान सोर्स ट्री में लिखना. इससे, एक ही सोर्स ट्री को किसी दूसरे टारगेट के लिए इस्तेमाल करने से रोका जा सकता है. पहला बिल्ड, सोर्स ट्री में लिखता है. इससे टारगेट A के लिए सोर्स ट्री ठीक हो जाता है. ऐसे में, टारगेट बी को बनाने की कोशिश करने पर आपको सफलता नहीं मिल सकती.

नॉन-हर्मेटिक बिल्ड से जुड़ी समस्याओं को हल करना

स्थानीय तौर पर एक्ज़ीक्यूट करने से शुरू होने वाली, स्थानीय कैश हिट पर असर डालने वाली समस्याएं, गैर-हर्मेटिक कार्रवाइयों के बारे में बताती हैं.

  • पक्का करें कि कोई भी टारगेट दोबारा न बनाया गया हो: अगर आपने make चलाया है और आपको एक सफल बिल्ड मिला है, तो बिल्ड को फिर से चलाने पर कोई भी टारगेट दोबारा नहीं बनाया जाना चाहिए. अगर हर बिल्ड चरण को दो बार या अलग-अलग सिस्टम पर चलाया जाता है, तो फ़ाइल के कॉन्टेंट के हैश की तुलना करें और अलग-अलग नतीजे पाएं. ऐसे में, बिल्ड को फिर से नहीं बनाया जा सकता.
  • स्थानीय कैश मेमोरी के हिट को डीबग करने के लिए, अलग-अलग क्लाइंट मशीनों पर चरण चलाएं. इससे यह पक्का किया जा सकेगा कि आपको क्लाइंट एनवायरमेंट से जुड़ी किसी भी समस्या का पता चल जाए.
  • डॉकर कंटेनर में एक बिल्ड को एक्ज़ीक्यूट करें. इस कंटेनर में, चेक-आउट किया गया सोर्स ट्री और होस्ट टूल की सूची के अलावा कुछ नहीं होता. बिल्ड ब्रेक और गड़बड़ी के मैसेज से, सिस्टम की छिपी हुई डिपेंडेंसी का पता चलेगा.
  • रिमोट एक्ज़ीक्यूशन के नियमों का इस्तेमाल करके, हर्मेटिकिटी से जुड़ी समस्याओं का पता लगाना और उन्हें ठीक करना.
  • हर कार्रवाई के लेवल पर, स्ट्रिक्ट सैंडबॉक्सिंग चालू करें. ऐसा इसलिए, क्योंकि बिल्ड में कार्रवाइयां स्टेटफ़ुल हो सकती हैं और बिल्ड या आउटपुट पर असर डाल सकती हैं.
  • वर्कस्पेस के नियमों की मदद से डेवलपर, बाहरी वर्कस्पेस में डिपेंडेंसी जोड़ सकते हैं. हालांकि, ये नियम इतने बेहतर होते हैं कि प्रोसेस में किसी भी तरह की प्रोसेसिंग की जा सकती है. Bazel वर्कस्पेस के नियमों में, कुछ ऐसी कार्रवाइयों का लॉग पाया जा सकता है जो हर्मेटिक नहीं हैं. इसके लिए, आपको अपनी Bazel कमांड में --experimental_workspace_rules_log_file=PATH फ़्लैग जोड़ना होगा.

Bazel के साथ हर्मेटिसिटी

Bazel के साथ हर्मेटिक बिल्ड का इस्तेमाल करके, अन्य प्रोजेक्ट को कैसे सफलता मिली, इस बारे में ज़्यादा जानने के लिए, BazelCon की ये बातचीत देखें: