हर्मिटिटी

किसी समस्या की शिकायत करें सोर्स देखें रात · 7.4 को अपनाएं. 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

खास जानकारी

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

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

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

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

फ़ायदे

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

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

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

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

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

ऐसे बिल्ड से जुड़ी समस्या हल करना जो पूरी तरह से सुरक्षित नहीं हैं

लोकल कैश मेमोरी में सेव होने पर, उन समस्याओं का पता चलता है जो लोकल कैश मेमोरी पर असर डालती हैं नॉन-हर्मेटिक कार्रवाइयां.

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

बेज़ल के साथ हरमैटिसिटी

हर्मेटिक का इस्तेमाल करके दूसरे प्रोजेक्ट को कैसे सफलता मिली, इस बारे में ज़्यादा जानकारी के लिए बनाने के बारे में ज़्यादा जानकारी मिल सकती है, तो BagelCon से जुड़ी ये बातें देखें: