हर्मिटिटी

Nightly · 9.1 · 9.0 · 8.7 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 8.1

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

खास जानकारी

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

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

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

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

फ़ायदे

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

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

नॉन-हर्मेटिसिटी की पहचान करना

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

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

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

लोकल एक्ज़ीक्यूशन से शुरू होने वाली समस्याएं, लोकल कैश हिट को प्रभावित करती हैं. इससे नॉन-हर्मेटिक कार्रवाइयों का पता चलता है.

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

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