जब आपके पास बड़ा कोड बेस होता है, तो डिपेंडेंसी की चेन बहुत गहरी हो सकती है. यहां तक कि सिंपल बाइनरी भी अक्सर लाखों बिल्ड टारगेट पर निर्भर हो सकती हैं. पर इसलिए, एक बिल्ड को वाजिब कीमत में पूरा करना नामुमकिन है समय की बचत होती है: कोई भी बिल्ड सिस्टम बुनियादी ज़रूरतों को पूरा नहीं कर सकता मशीन के हार्डवेयर पर लगाए गए भौतिकी के नियम. इसे ठीक करने का यही एक तरीका है एक ऐसे बिल्ड सिस्टम के साथ है जो डिस्ट्रिब्यूटेड बिल्ड में काम करता है जिसमें सिस्टम के काम करने के तरीके को आर्बिट्रेरी और स्केलेबल प्रोसेस के ज़रिए, मशीनों की संख्या. मान लें कि हमने सिस्टम के काम को छोटे स्तर पर यूनिट (इसके बारे में बाद में और जानकारी दी गई है), तो इससे हमें किसी भी बिल्ड को पूरा करने में मदद मिलेगी भुगतान करने के लिए तैयार हो जाता है. बड़े स्तर पर इस्तेमाल की जा सकने वाली यह क्षमता ही हमारे लिए सबसे अहम है हम आर्टफ़ैक्ट-आधारित बिल्ड सिस्टम को परिभाषित करने की दिशा में काम कर रहे हैं.
रिमोट कैशिंग
डिस्ट्रिब्यूटेड बिल्ड का सबसे आसान टाइप, वह है जो सिर्फ़ रिमोट कैश मेमोरी में सेव करना, जिसे पहली इमेज में दिखाया गया है.
पहली इमेज. रिमोट कैश मेमोरी दिखाने वाला डिस्ट्रिब्यूटेड बिल्ड
बिल्ड करने वाला हर सिस्टम, जिसमें डेवलपर वर्कस्टेशन और कंटिन्यूअस इंटिग्रेशन सिस्टम, सामान्य रिमोट कैश का रेफ़रंस शेयर करता है सेवा. यह सेवा कम समय के लिए इस्तेमाल किया जाने वाला तेज़ स्टोरेज सिस्टम हो सकती है, जैसे कि Redis या Google Cloud Storage जैसी क्लाउड सेवा. जब किसी उपयोगकर्ता को ज़रूरत हो सीधे तौर पर या किसी डिपेंडेंसी के तौर पर कोई आर्टफ़ैक्ट बनाते हैं, तो सिस्टम सबसे पहले रिमोट कैश की मदद से देख सकता है कि वह आर्टफ़ैक्ट वहां पहले से मौजूद है या नहीं. अगर ऐसा है, तो आर्टफ़ैक्ट बनाने के बजाय उसे डाउनलोड कर सकता है. अगर ऐसा नहीं होता है, तो सिस्टम और नतीजे को वापस कैश मेमोरी में अपलोड कर देता है. इसका मतलब है कि लो-लेवल डिपेंडेंसी जो अक्सर नहीं बदलतीं उन्हें एक बार बनाया और शेयर किया जा सकता है उसे दोबारा बनाने की ज़रूरत नहीं है. Google में कई आर्टफ़ैक्ट को शुरुआत से बनाने के बजाय, कैश मेमोरी से दिखाया जाता है इससे हमारे बिल्ड सिस्टम को चलाने की लागत कम हो जाती है.
रिमोट कैशिंग सिस्टम तभी काम करेगा, जब बिल्ड सिस्टम इस बात की गारंटी देगा कि पूरी तरह से दोबारा पैदा की जा सकती हैं. इसका मतलब है कि किसी भी बिल्ड टारगेट के लिए, यह मुमकिन होना चाहिए कि उस लक्ष्य के इनपुट का सेट ऐसे तय करें कि इनपुट का समान सेट किसी भी मशीन पर बिलकुल वैसा ही आउटपुट देगा. सिर्फ़ इस तरीके से पक्का करें कि आर्टफ़ैक्ट डाउनलोड करने के नतीजे वही हैं जो हम खुद उसे तैयार कर सकते हैं. ध्यान दें कि इसके लिए यह ज़रूरी है कि कैश मेमोरी में मौजूद हर आर्टफ़ैक्ट उसके टारगेट और इसके इनपुट के हैश, दोनों पर एक-दूसरे से जुड़ी होनी चाहिए. इस तरह, अलग-अलग इंजीनियर एक ही समय में, एक ही टारगेट में अलग-अलग बदलाव कर सकते थे समय हो सकता है और रिमोट कैश मेमोरी उन सभी आर्टफ़ैक्ट को सेव कर लेगी जो बिना किसी टकराव के सही तरीके से उनका इस्तेमाल कर सकते हैं.
हालांकि, रिमोट कैश से फ़ायदा पाने के लिए, आर्टफ़ैक्ट को बनाने की तुलना में ज़्यादा तेज़ होना चाहिए. हमेशा ऐसा नहीं होता, खास तौर पर तब, जब कैश सर्वर, बिल्ड करने वाली मशीन से दूर हो. Google की बिल्ड को फटाफट शेयर करने के लिए, नेटवर्क और बिल्ड सिस्टम को ध्यान से तैयार किया गया है नतीजे.
रिमोट तरीके से एक्ज़ीक्यूट करें
रिमोट कैशिंग, डिस्ट्रिब्यूटेड बिल्ड नहीं होती है. अगर कैश मेमोरी मिट जाती है या एक निम्न-स्तरीय बदलाव करें जिसके लिए सब कुछ फिर से बनाने की आवश्यकता होती है, फिर भी आपको पूरी बिल्ड को आपकी मशीन पर पूरा करने के लिए. असल मकसद आपकी मदद करना है रिमोट एक्ज़ीक्यूशन, जिसमें बिल्ड करने के असल काम का बंटवारा किया जा सकता है काम कर रहे हैं. दूसरी इमेज में रिमोट एक्ज़ीक्यूशन सिस्टम दिखाया गया है.
दूसरी इमेज. रिमोट एक्ज़ीक्यूशन सिस्टम
हर उपयोगकर्ता की मशीन पर चलने वाला बिल्ड टूल (जहां उपयोगकर्ता या तो मानव होते हैं) इंजीनियर या स्वचालित बिल्ड सिस्टम) किसी केंद्रीय बिल्ड मास्टर को अनुरोध भेजते हैं. बिल्ड मास्टर, अनुरोधों को कॉम्पोनेंट कार्रवाइयों और शेड्यूल में बांटता है बड़े स्तर पर काम करने वाले वर्कर पर उन कार्रवाइयों को लागू करना. हर कर्मचारी उपयोगकर्ता के बताए गए इनपुट के साथ, उससे जुड़ी कार्रवाइयां करता है और इससे बनने वाले आर्टफ़ैक्ट को लिखता है. ये आर्टफ़ैक्ट एक-दूसरे के साथ शेयर किए जाते हैं ये मशीन ऐसी कार्रवाइयों को करती हैं जिनकी उन्हें फ़ाइनल आउटपुट होने तक ज़रूरत होती है उपयोगकर्ता को भेजा और भेजा जाता है.
इस तरह के सिस्टम को लागू करने का सबसे मुश्किल काम, कम्यूनिकेशन को मैनेज करना है कर्मचारी, मास्टर, और उपयोगकर्ता की लोकल मशीन के बीच में. कर्मचारी यह कर सकते थे दूसरे कर्मचारियों के बनाए हुए इंटरमीडिएट आर्टफ़ैक्ट के आधार पर और आखिरी नतीजों पर उपयोगकर्ता के कंप्यूटर पर वापस भेजना ज़रूरी होता है. ऐसा करने के लिए, हम ऊपर बताए गए डिस्ट्रीब्यूटेड कैश मेमोरी के सबसे ऊपर वाले हिस्से को सेव करके रखें. इसके नतीजे, कैश मेमोरी से इसकी डिपेंडेंसी के बारे में बताते हैं. मास्टर ब्लॉक काम करने वाले को आगे बढ़ना है, जब तक कि जिस पर वे निर्भर करती हैं वह खत्म न हो जाए, जिसमें केस के साथ वे कैश मेमोरी से अपने इनपुट पढ़ सकेंगे. फ़ाइनल प्रॉडक्ट है भी कैश मेमोरी में सेव किया जाता है, ताकि लोकल मशीन उसे डाउनलोड कर सके. ध्यान दें कि हमें उपयोगकर्ता के सोर्स ट्री में मौजूद स्थानीय बदलावों को एक्सपोर्ट करने के अलग-अलग तरीकों को कर्मचारी, बिल्डिंग बनाने से पहले उन बदलावों को लागू कर सकते हैं.
इसके काम करने के लिए, आर्टफ़ैक्ट-आधारित बिल्ड सिस्टम के उन सभी हिस्सों के बारे में बताया गया है पहले साथ आने की ज़रूरत है. बिल्ड एनवायरमेंट पूरी तरह से होने चाहिए समय पर काम करते हैं. इससे हम बिना किसी व्यक्ति के दख़लअंदाज़ी के कर्मचारियों को जोड़ सकते हैं. बिल्ड पूरी तरह अपने-आप में पूरी होनी चाहिए, क्योंकि हर चरण में उसे किसी दूसरे मशीन पर एक्ज़ीक्यूट किया जा सकता है. आउटपुट पूरी तरह से सारणिक होने चाहिए, कि हर कर्मचारी दूसरे वर्कर से मिलने वाले नतीजों पर भरोसा कर सके. इस तरह टास्क पर आधारित सिस्टम के लिए, गारंटी देना बहुत मुश्किल है. दूर से काम करने के लिए भरोसेमंद सिस्टम बनाना नामुमकिन है. एक.
Google पर डिस्ट्रिब्यूट किए गए बिल्ड
Google साल 2008 से, डिस्ट्रिब्यूटेड बिल्ड सिस्टम का इस्तेमाल कर रहा है. इसमें, रिमोट कैशिंग और रिमोट एक्ज़ीक्यूशन, जिसे इमेज 3 में दिखाया गया है.
तीसरी इमेज. Google का डिस्ट्रिब्यूटेड बिल्ड सिस्टम
Google की रिमोट कैश मेमोरी को ऑब्जेएफ़एस कहा जाता है. इसमें एक बैकएंड होता है, जो हमारे प्रोडक्शन बेड़े में डिस्ट्रिब्यूट किए गए Bigtables में आउटपुट पाएं और एक फ़्रंटएंड FUSE डीमन होता है. इसे objfsd कहा जाता है, जो हर डेवलपर के डिवाइस पर चलता है मशीन. FUSE डीमन की मदद से इंजीनियर, बिल्ड आउटपुट को इस तरह ब्राउज़ कर सकते हैं जैसे कि वे वर्कस्टेशन में सेव की गई सामान्य फ़ाइलें थीं, लेकिन फ़ाइल के कॉन्टेंट के साथ सिर्फ़ उन फ़ाइलों के लिए मांग पर डाउनलोड की जाती हैं जिनका अनुरोध सीधे तौर पर उपयोगकर्ता. मांग पर फ़ाइल का कॉन्टेंट दिखाने की सुविधा, नेटवर्क और डिस्क, दोनों के लिए काफ़ी कम है है. साथ ही, सिस्टम इसे सेव करने की तुलना में दोगुनी तेज़ी से बना सकता है सभी बिल्ड आउटपुट को डेवलपर की लोकल डिस्क पर सेव किया जाता है.
Google के रिमोट एक्ज़ीक्यूशन सिस्टम को Forge कहा जाता है. Blaze में शामिल एक फ़ोर्ज क्लाइंट (बेज़ल का आंतरिक समतुल्य) को कॉल किया गया डिस्ट्रिब्यूटर हर कार्रवाई के लिए, हमारी डेटासेंटर को शेड्यूलर कहा जाता है. शेड्यूलर, कैश मेमोरी में सेव की गई कार्रवाई को बनाए रखता है इससे नतीजे के तौर पर, अगर कार्रवाई पहले ही की जा चुकी है, तो जिन्हें सिस्टम के किसी दूसरे उपयोगकर्ता ने बनाया हो. अगर नहीं, तो यह कार्रवाई सूची में रखें. एक्ज़िक्यूटर जॉब का एक बड़ा पूल इस सूची की कार्रवाइयों को लगातार पढ़ता है, उन्हें एक्ज़ीक्यूट करें और नतीजों को सीधे ObjFS Bigtables में स्टोर करें. ये नतीजे, मैनेजर को आने वाले समय में की जाने वाली कार्रवाइयों के लिए उपलब्ध होंगे या उन्हें डाउनलोड भी किया जा सकेगा objfsd के ज़रिए असली उपयोगकर्ता ने भेजा है.
आखिरी नतीजा एक ऐसा सिस्टम है जो सभी बिल्ड को बेहतर तरीके से इस्तेमाल कर सकता है ने Google पर काम किया. Google ने कई तरह की सुविधाएं जोड़ी हैं. जैसे: Google करोड़ों टेस्ट केस लागू करके और पेटाबाइट बनाने के लिए, लाखों बिल्ड प्रोसेस करती हैं से हर दिन सोर्स कोड की करोड़ों लाइन के बिल्ड आउटपुट मिलते हैं. न सिर्फ़ इस तरह के सिस्टम से हमारे इंजीनियर, तेज़ी से जटिल कोडबेस बना पाते हैं. यह सिस्टम को हम बड़ी संख्या में ऐसे ऑटोमेटेड टूल और सिस्टम लागू करना चाहते हैं जो हमारी बिल्ड.