इस पेज पर खास समस्याओं और चुनौतियों के बारे में खास जानकारी दी गई है बेज़ेल के बेहतर नियमों को बनाया जा सकता है.
खास जानकारी में ज़रूरी शर्तें
- अनुमान: सटीक, थ्रूपुट, इस्तेमाल में आसान, और जवाब के लिए इंतज़ार करना पड़ा
- अनुमान: लार्ज स्केल रिपॉज़िटरी
- अनुमान: बिल्ड जैसी जानकारी देने वाली भाषा
- ऐतिहासिक: लोडिंग, विश्लेषण, और एक्ज़िक्यूशन के बीच हार्ड सेपरेशन है पुराना, लेकिन अब भी एपीआई पर असर डालता है
- Intrinsic: रिमोट एक्ज़िक्यूशन और कैश मेमोरी बनाना मुश्किल होता है
- Intrinsic: सही और तेज़ इंक्रीमेंटल बिल्ड के लिए, बदलाव की जानकारी का इस्तेमाल करना असामान्य कोडिंग पैटर्न की ज़रूरत है
- Intrinsic: क्वाड्रेटिक टाइम और मेमोरी के इस्तेमाल से बचना मुश्किल है
अनुमान
यहां बिल्ड सिस्टम के बारे में कुछ अनुमान दिए गए हैं, जैसे कि उसके सटीक होने, इस्तेमाल में आसानी, डेटा की क्षमता, और बड़े स्तर पर डेटा स्टोर करने की जगहें. कॉन्टेंट बनाने नीचे दिए सेक्शन में, इन अनुमानों पर बात की गई है और यह पक्का करने के लिए दिशा-निर्देश दिए गए हैं कि नियम असरदार तरीके से लिखे जाने चाहिए.
सटीक, थ्रूपुट, इस्तेमाल में आसानी, और इंतज़ार का समय
हम मान लेते हैं कि बिल्ड सिस्टम के साथ सबसे पहले और सबसे अच्छी तरह सही होने चाहिए काफ़ी अहम माने जाते हैं. दिए गए सोर्स ट्री के लिए, एक जैसा बिल्ड हमेशा एक जैसा होना चाहिए. इससे कोई फ़र्क़ नहीं पड़ता कि आउटपुट ट्री कैसा दिखता है पसंद. पहले अनुमान में इसका मतलब यह हुआ कि बेज़ल को आपकी हर गतिविधि जानने की ज़रूरत है ऐसा इनपुट जो दिए गए बिल्ड स्टेप में जाता है, ताकि अगर कोई हो, तो वह उस चरण को फिर से चला सकता है के इनपुट बदल जाते हैं. लीक होने के बावजूद, बेज़ल कितना सही कॉन्टेंट निकाल सकते हैं, इसकी कुछ सीमाएं हैं बिल्ड की तारीख / समय जैसी कुछ जानकारी शामिल करता है और कुछ खास तरह के फ़ाइल विशेषताओं में परिवर्तन जैसे परिवर्तन. सैंडबॉक्सिंग इससे यह पक्का किया जाता है कि जानकारी सही है. ऐसा करने पर, ऐसी इनपुट फ़ाइलों को पढ़ने से रोका जाता है जिनका एलान नहीं किया गया है. इसके अलावा सिस्टम की आंतरिक सीमाएं हैं, तो कुछ ज्ञात समस्याएं हैं, जो सटीक होने से संबंधित हैं, इनमें से ज़्यादातर नियम, फ़ाइलसेट या C++ के नियमों से जुड़े होते हैं. ये दोनों मुश्किल समस्याएं. हम इन्हें ठीक करने के लिए लंबे समय तक काम करते रहते हैं.
बिल्ड सिस्टम का दूसरा लक्ष्य ज़्यादा डेटा इकट्ठा करना है; हम हैं मौजूदा समय में किए जा सकने वाले कामों की सीमाओं को लगातार करना रिमोट एक्ज़ीक्यूशन सेवा के लिए मशीन आवंटन. अगर रिमोट तरीके से एक्ज़ीक्यूट किया जाता है, तो सेवा ओवरलोड हो जाती है, इसलिए कोई भी काम नहीं कर सकता.
आगे, इस्तेमाल करने में आसानी होगी. एक ही तरीके के कई सही तरीकों का इस्तेमाल करके (या इसी तरह, रिमोट एक्ज़ीक्यूशन सेवा का इस्तेमाल करते समय, हम अन्य वीडियो पर नज़र रखें.
कॉन्टेंट बनाने में लगने वाले समय से लेकर, किसी प्रॉडक्ट को बनाने में लगने वाले समय का पता चलता है.
पता लगाना हो, चाहे वह किसी पास होने या फ़ेल होने की वजह से टेस्ट लॉग हो या किसी गड़बड़ी की वजह से हो
मैसेज बताता है कि BUILD फ़ाइल में टाइपिंग की गलती है.
ध्यान दें कि ये लक्ष्य अक्सर ओवरलैप होते हैं; इंतज़ार का समय उतना ही होता है जितना कि थ्रूपुट की रिमोट एक्ज़ीक्यूशन सेवा को सही तरीके से लागू करना हो.
डेटा स्टोर करने की बहुत बड़ी जगह
बिल्ड सिस्टम को बड़े स्तर पर काम करने के लिए, बड़े स्तर पर काम करने की ज़रूरत होती है.
का मतलब है कि यह एक हार्ड ड्राइव पर फ़िट नहीं होता, इसलिए इसे ठीक करना नामुमकिन है
करीब-करीब सभी डेवलपर मशीनों पर पूरा चेकआउट किया जा सकता है. मीडियम साइज़ की बिल्ड
को लाखों BUILD फ़ाइलों को पढ़ने और पार्स करने की ज़रूरत पड़ेगी. साथ ही,
लाखों ग्लॉब्स मिल जाते हैं. हालांकि, ऐसा सैद्धांतिक तौर पर किया जा सकता है कि
BUILD फ़ाइलें एक मशीन पर डाउनलोड की गई हैं, हम अब तक ऐसा करने के लिए
समय और मेमोरी को पहचानने में मदद मिलती है. इसलिए, यह ज़रूरी है कि BUILD फ़ाइलें
को अलग-अलग लोड और पार्स किया जा सकता है.
बिल्ड जैसी भाषा
इस संदर्भ में, हम एक कॉन्फ़िगरेशन भाषा को
लाइब्रेरी और बाइनरी नियमों के एलान में मौजूद, BUILD फ़ाइलों के बराबर है
और अन्य निर्भरता को शामिल किया है. BUILD फ़ाइलों को अलग-अलग पढ़ा और पार्स किया जा सकता है,
और जब भी हम संभव होता है, हम स्रोत फ़ाइलों को देखने से बचते हैं (केवल
मौजूद नहीं है).
ऐतिहासिक
Basel के अलग-अलग वर्शन में कुछ ऐसे अंतर होते हैं जिनकी वजह से चुनौतियां होती हैं. साथ ही, कुछ नीचे दिए गए सेक्शन में इनकी जानकारी दी गई है.
लोड करने, विश्लेषण करने, और एक्ज़ीक्यूशन के बीच का डेटा काफ़ी पुराना है, लेकिन एपीआई पर इसका असर अब भी दिख रहा है
तकनीकी रूप से, किसी नियम के लिए इसकी इनपुट और आउटपुट फ़ाइलों को जानना पर्याप्त है रिमोट एक्ज़ीक्यूशन के लिए कार्रवाई भेजने से ठीक पहले की कार्रवाई. हालांकि, ओरिजनल बेज़ल कोड बेस में, लोडिंग पैकेज अलग-अलग थे, फिर कॉन्फ़िगरेशन (ज़रूरी है, कमांड-लाइन फ़्लैग) का इस्तेमाल करके नियमों का विश्लेषण करना और लागू करने के लिए कहा जा सकता है. यह अंतर अब भी नियम एपीआई का हिस्सा है है, भले ही बेज़ेल की मुख्य सुविधाओं को अब इसकी ज़रूरत नहीं है (ज़्यादा जानकारी नीचे दी गई है).
इसका मतलब है कि नियम एपीआई के लिए, नियम के बारे में जानकारी देना ज़रूरी है (इसमें क्या-क्या विशेषताएं हैं, और किस तरह के एट्रिब्यूट हैं). कुछ अपवाद, जहां API कस्टम कोड को लोडिंग चरण के दौरान आउटपुट फ़ाइलों के इंप्लिसिट नामों और एट्रिब्यूट की इंप्लिसिट वैल्यू का पता लगा सकता है. इसके लिए उदाहरण के लिए, 'foo' नाम का java_library नियम है इंप्लिसिट रूप से नाम का एक आउटपुट जनरेट करता है 'libfoo.Jar' में जोड़ा गया है, जिसका रेफ़रंस बिल्ड ग्राफ़ में दिए गए अन्य नियमों में दिया जा सकता है.
इसके अलावा, किसी नियम का विश्लेषण, किसी भी सोर्स फ़ाइल को नहीं पढ़ सकता या उसकी जांच नहीं कर सकता किसी कार्रवाई का आउटपुट; इसके बजाय, इसे कुछ हद तक सीधे तौर पर चलने वाले द्विपक्षीय सोर्स की ज़रूरत होती है बिल्ड चरणों और आउटपुट फ़ाइल नामों का ग्राफ़, जिसे सिर्फ़ नियम से तय किया जाता है और उसकी डिपेंडेंसी.
मूल
कुछ स्वाभाविक प्रॉपर्टी होती हैं, जो लिखने के नियमों को मुश्किल बनाती हैं और कुछ सबसे सामान्य तरीकों के बारे में नीचे दिए गए सेक्शन में बताया गया है.
रिमोट तरीके से एक्ज़ीक्यूट करना और कैश मेमोरी में सेव करना मुश्किल होता है
रिमोट एक्ज़ीक्यूशन और कैश मेमोरी, डेटा स्टोर करने की बड़ी जगहों में बिल्ड के समय में सुधार करती है किसी एक डिवाइस पर बिल्ड की तुलना में तीव्रता के दो ऑर्डर मशीन. हालांकि, जिस स्केल पर इसे परफ़ॉर्म करने की ज़रूरत है वह चौंका देने वाला है: Google का रिमोट एक्ज़ीक्यूशन सेवा इस तरह से डिज़ाइन की गई है कि वह बड़ी संख्या में हर अनुरोध को पूरा कर सके दूसरा, और प्रोटोकॉल गै़र-ज़रूरी राउंडट्रिप से सावधानी से बचा जाता है. ज़्यादा काम करने की ज़रूरत नहीं है.
इस समय, प्रोटोकॉल के लिए यह ज़रूरी है कि बिल्ड सिस्टम को समय से पहले कार्रवाई कर दी है; इसके बाद बिल्ड सिस्टम, एक यूनीक ऐक्शन और फ़िंगरप्रिंट पर क्लिक करता है, और शेड्यूलर से कैश हिट करने के लिए कहता है. कैश मेमोरी हिट मिलने पर, शेड्यूलर, आउटपुट फ़ाइलों के ब्यौरे के साथ जवाब देता है; फ़ाइलें अपने-आप जिसे डाइजेस्ट ने बाद में इकट्ठा किया था. हालांकि, इससे बेज़ल पर प्रतिबंध लागू हो जाता है नियमों के साथ-साथ सभी इनपुट फ़ाइलों के बारे में समय से पहले बताना होगा.
सही और तेज़ इंक्रीमेंटल बिल्ड के लिए बदलाव की जानकारी का इस्तेमाल करने के लिए, कोडिंग के असामान्य पैटर्न की ज़रूरत होती है
ऊपर, हमने तर्क दिया कि सही होने के लिए, बेज़ल को सभी इनपुट जानने की ज़रूरत है ऐसी फ़ाइलें जिन्हें बिल्ड चरण में भेजा जाता है, ताकि यह पता लगाया जा सके कि वह बिल्ड स्टेप अब भी अप-टू-डेट है. यही बात पैकेज लोड होने और नियमों के विश्लेषण पर भी लागू होती है. Skyframe को इस तरह डिज़ाइन किया गया है कि किया जा सकता है. Skyframe एक ग्राफ़ लाइब्रेरी और आकलन फ़्रेमवर्क है, जो लक्ष्य नोड (जैसे कि 'build //foo' के साथ इन विकल्पों का)) और उसे इसके तहत, कॉम्पोनेंट, ज़रूरी कॉम्पोनेंट का आकलन करके, इन्हें इकट्ठा किया जाता है. नतीजा. इस प्रोसेस के तहत, SkyFrame पैकेज को पढ़ता है, नियमों का विश्लेषण करता है, और कार्रवाइयों को लागू करता है.
हर नोड पर, SkyFrame सटीक रूप से उन नोड को ट्रैक करता है जो किसी भी नोड का इस्तेमाल कंप्यूट करने के लिए करते हैं इसका अपना आउटपुट होता है, जो लक्ष्य नोड से लेकर इनपुट फ़ाइलों तक (जिसमें स्काईफ़्रेम नोड भी हैं). इस ग्राफ़ को मेमोरी में साफ़ तौर पर दिखाना बिल्ड सिस्टम को यह पता लगाने की अनुमति देता है कि दिए गए सेगमेंट से कौनसे नोड पर असर पड़ा है किसी इनपुट फ़ाइल में परिवर्तन (इसमें इनपुट फ़ाइल को बनाना या मिटाना शामिल है), और आउटपुट ट्री को उसकी मनचाही स्थिति में वापस लाने में कम मेहनत लगती है.
इसके तहत, हर नोड डिपेंडेंसी खोजने की प्रोसेस करता है. हर नोड डिपेंडेंसी के बारे में बता सकता है और फिर उन डिपेंडेंसी के कॉन्टेंट का इस्तेमाल कर सकता है और डिपेंडेंसी के तौर पर एलान किया जा सकता है. सैद्धांतिक तौर पर, यह थ्रेड-पर-नोड मॉडल. हालांकि, मीडियम साइज़ के बिल्ड में हज़ारों Skyframe नोड हैं, जो वर्तमान Java के साथ आसानी से संभव नहीं हैं (और ऐतिहासिक कारणों से, हम वर्तमान में Java के उपयोग से जुड़े हुए हैं, इसलिए कोई आसान धागा नहीं होना चाहिए और न ही किसी एलिमेंट का इस्तेमाल किया जा सकता है.
इसके बजाय, Bagel एक तय साइज़ के थ्रेड पूल का इस्तेमाल करता है. हालांकि, इसका मतलब है कि अगर कोई नोड ऐसी डिपेंडेंसी का एलान करता है जो अभी तक उपलब्ध नहीं है. हो सकता है कि हम उसे रद्द करना पड़े जांच करें और इसे (किसी दूसरे थ्रेड में) को रीस्टार्ट करें, जब डिपेंडेंसी उपलब्ध हैं. इसका मतलब है कि नोड को यह काम बहुत ज़्यादा नहीं करना चाहिए; एक वह नोड जो क्रम के हिसाब से N डिपेंडेंसी के बारे में बताता है, उसे N बार रीस्टार्ट किया जा सकता है. O(N^2) बार लागत आती है. इसके बजाय, हम पहले ही बल्क में एलान करते हैं डिपेंडेंसी के लिए कभी-कभी कोड को फिर से व्यवस्थित करने या उसे रीस्टार्ट की संख्या को सीमित करने के लिए, एक नोड को कई नोड में जोड़ देता है.
ध्यान दें कि यह तकनीक अभी नियम एपीआई में उपलब्ध नहीं है; इसके बजाय, एपीआई के नियम, लोडिंग, विश्लेषण, और और एक्ज़ीक्यूशन के चरण शामिल करें. हालांकि, एक बुनियादी बात यह है कि अन्य नोड को फ़्रेमवर्क से गुज़रना होगा. इससे यह संबंधित डिपेंडेंसी. भले ही, वह भाषा कुछ भी हो जिसमें बिल्ड सिस्टम लागू हो या जिसमें नियम लिखे गए हों (उन्हें समान), नियम के लेखकों को स्टैंडर्ड लाइब्रेरी या पैटर्न का इस्तेमाल नहीं करना चाहिए स्काईफ़्रेम. Java के लिए, इसका मतलब है java.io.File और किसी भी रूप में प्रतिबिंब और किसी भी लाइब्रेरी से भी मिल सकता है. डिपेंडेंसी के साथ काम करने वाली लाइब्रेरी इन लो-लेवल इंटरफ़ेस के इंजेक्शन को अब भी सही तरीके से सेटअप स्काईफ़्रेम.
इसका सुझाव है कि नियम लिखने वाले लोगों की जानकारी, भाषा के पूरे रनटाइम पर न दिखे पहले स्थान पर हैं. ऐसे एपीआई के गलती से इस्तेमाल का खतरा बहुत ज़्यादा है - पहले कई Basel की गड़बड़ियां, असुरक्षित एपीआई का इस्तेमाल करने वाले नियमों की वजह से हुई थीं. यहां तक कि हालांकि, ये नियम बेज़ल टीम या अन्य डोमेन विशेषज्ञों ने लिखे थे.
क्वाड्रेटिक टाइम और मेमोरी के इस्तेमाल से बचना मुश्किल है
स्थिति को और भी खराब बनाने के लिए, Skyframe की लगाई गई ज़रूरी शर्तों को छोड़कर, Java के इस्तेमाल की पुरानी पाबंदियां और नियमों के एपीआई के पुराने होने की जानकारी, गलती से द्विघात समय या मेमोरी का उपभोग शुरू हो जाना, में समस्या हो सकती है. दो ऐसे बहुत ही आम पैटर्न हैं जिनसे क्वाड्रेटिक मेमोरी के इस्तेमाल की जानकारी मिलती है. यही वजह है कि क्वाड्रेटिक टाइम कंज़म्पशन).
लाइब्रेरी के नियम - मान लीजिए कि लाइब्रेरी के नियमों की चेन में A, B, C पर निर्भर करता है, और इसी तरह. इसके बाद, हम उदाहरण के लिए, ये नियम, जैसे कि Java रनटाइम क्लासपाथ या चुनें. इसलिए, शायद हम स्टैंडर्ड सूची को लागू करें; हालांकि, इसमें पहले से ही क्वाड्रेटिक मेमोरी इस्तेमाल की सुविधा है: पहली लाइब्रेरी क्लासपाथ पर एक एंट्री, दूसरी दो, तीसरी तीन, और इसलिए है चालू, कुल 1+2+3+...+N = O(N^2) एंट्री के लिए.
एक जैसे लाइब्रेरी के नियमों के आधार पर बाइनरी नियम - ऐसा मामला देखें जिसमें एक ही लाइब्रेरी पर निर्भर बाइनरी का सेट हो नियम — जैसे कई टेस्ट नियम होने चाहिए, जो सभी एक जैसे टेस्ट करते हों लाइब्रेरी कोड. मान लें कि N नियमों में से आधे नियम बाइनरी नियम हैं, और में बताया गया है. अब मान लीजिए कि हर बाइनरी कुछ प्रॉपर्टी का आकलन, लाइब्रेरी के लिए तय समय के लिए तय किए गए समय के लिए किया जाता है, जैसे कि Java रनटाइम क्लासपाथ या C++ लिंकर कमांड लाइन का इस्तेमाल करें. उदाहरण के लिए, यह C++ लिंक कार्रवाई के कमांड लाइन स्ट्रिंग प्रज़ेंटेशन को बड़ा कर सकता है. लागू नहीं N/2 एलिमेंट की कॉपी, O(N^2) मेमोरी होती है.
क्वाड्रेटिक कॉम्प्लेक्सिटी से बचने के लिए कस्टम कलेक्शन क्लास
बेज़ल इन दोनों स्थितियों से काफ़ी प्रभावित है. इसलिए, हमने
कस्टम कलेक्शन क्लास की मदद से, मेमोरी में मौजूद जानकारी को असरदार तरीके से कंप्रेस किया जाता है
हर चरण में कॉपी से बचने के लिए. इनमें से करीब सभी डेटा स्ट्रक्चर को
सिमेंटिक्स
डिप्सेट
(इंटरनल इंप्लीमेंटेशन में NestedSet के नाम से भी जाना जाता है). इसका ज़्यादातर हिस्सा
पिछले कई सालों में Basel की मेमोरी की खपत कम करने के लिए,
पहले उपयोग की गई चीज़ों के स्थान पर Depsets का इस्तेमाल करने के लिए बदलाव.
माफ़ करें, डिप्सेट के इस्तेमाल से सभी समस्याएं अपने-आप ठीक नहीं होती हैं; खास तौर पर, हर नियम में एक सीमा तय करने पर बार-बार उसकी शुरुआत द्विघाती समय खपत. अंदरूनी तौर पर, NestedSets में भी कुछ मददगार तरीके हैं सामान्य कलेक्शन क्लास के साथ इंटरऑपरेबिलिटी को आसान बनाने के लिए; हमें अफ़सोस है, गलती से NestedSet को इनमें से किसी एक तरीके पर पास कर देने से, व्यवहार, और क्वाड्रेटिक मेमोरी इस्तेमाल की सुविधा फिर से शुरू करता है.