पिछले पेजों में, एक थीम बार-बार दोहराई जाती है: मैनेज करना तो आपका अपना कोड काफ़ी आसान है, लेकिन इसकी डिपेंडेंसी को मैनेज करना और मुश्किल हो जाता है. ये सभी चीज़ें निर्भर करती हैं: कभी-कभी किसी टास्क पर निर्भर हो. जैसे, “मैं रिलीज़ को इस रूप में मार्क करने से पहले दस्तावेज़ को पुश करना चाहता हूं पूरा) दिखता है, और कभी-कभी आर्टफ़ैक्ट पर निर्भरता होती है (जैसे कि “मुझे यह करना है” मेरे पास कोड बनाने के लिए, कंप्यूटर विज़न लाइब्रेरी का सबसे नया वर्शन होना चाहिए"). कभी-कभी, आपकी कोड बेस के दूसरे हिस्से पर इंटरनल डिपेंडेंसी होती हैं और कभी-कभी आपकी कंपनी अन्य टीम के मालिकाना हक वाले कोड या डेटा पर निर्भर करती है (या तो आपके संगठन में या किसी तीसरे पक्ष में). हालांकि, किसी भी मामले में, “मैं की ज़रूरत होती है, यह बात बार-बार आती रहती है और डिपेंडेंसी मैनेज करना, शायद दुनिया भर में बुनियादी काम है.
मॉड्यूल और डिपेंडेंसी चुनना
बेज़ल जैसे आर्टफ़ैक्ट पर आधारित बिल्ड सिस्टम का इस्तेमाल करने वाले प्रोजेक्ट को अलग-अलग सेट में बांटा गया है
के मॉड्यूल के साथ, ये मॉड्यूल BUILD के ज़रिए एक-दूसरे पर निर्भरता दिखाते हैं
फ़ाइलें शामिल हैं. इन मॉड्यूल और डिपेंडेंसी को सही तरीके से व्यवस्थित करने से,
इसकी वजह से बिल्ड सिस्टम की परफ़ॉर्मेंस और काम करने की क्षमता, दोनों पर असर पड़ता है
बनाए रखें.
फ़ाइन-ग्रैन्ड मॉड्यूल और 1:1:1 नियम का इस्तेमाल करना
आर्टफ़ैक्ट पर आधारित बिल्ड को तैयार करते समय सबसे ज़रूरी सवाल यह होता है कि
यह तय किया जा सकता है कि किसी मॉड्यूल में कितनी सुविधाएं होनी चाहिए. Basel में,
मॉड्यूल को टारगेट करके दिखाया जाता है. इसमें ऐसी बनाने लायक यूनिट तय की जाती है
java_library या go_binary. कम शब्दों में कहें, तो हो सकता है कि पूरा प्रोजेक्ट
रूट पर एक BUILD फ़ाइल रखकर और
उस प्रोजेक्ट की सभी सोर्स फ़ाइलों को बार-बार ग्लोब करते हुए देखते हैं. दूसरे पर
एक्सट्रीम, करीब हर सोर्स फ़ाइल को असरदार तरीके से इसके खुद के मॉड्यूल में बनाया जा सकता है
हर फ़ाइल को BUILD फ़ाइल में शामिल करने के लिए, हर दूसरी फ़ाइल पर निर्भर करता है.
ज़्यादातर प्रोजेक्ट, इन सीमाओं के बीच होते हैं और फ़ैसला लेने के लिए
परफ़ॉर्मेंस और रखरखाव के बीच संतुलन बनाना. एक मॉड्यूल का उपयोग करके
पूरे प्रोजेक्ट का मतलब यह हो सकता है कि आपको इसे छोड़कर BUILD फ़ाइल को छूना न पड़े
बाहरी डिपेंडेंसी जोड़ते समय, इसका मतलब है कि बिल्ड सिस्टम को
पूरे प्रोजेक्ट को हमेशा एक साथ बनाएं. इसका मतलब है कि यह इन सुविधाओं का इस्तेमाल नहीं कर पाएगा
बिल्ड के हिस्सों को साथ-साथ या डिस्ट्रिब्यूट नहीं करेगा. साथ ही, यह पार्ट को कैश मेमोरी में सेव भी नहीं कर पाएगा
पहले ही बन चुका है. हर फ़ाइल में एक-मॉड्यूल इसके उलट होता है: बिल्ड सिस्टम
कैश मेमोरी में सेव करने और बिल्ड के चरणों को शेड्यूल करने की सुविधा के सबसे ज़्यादा विकल्प हैं, लेकिन
कभी-कभी, इंजीनियर को डिपेंडेंसी की सूची को बनाए रखने में ज़्यादा मेहनत करनी पड़ती है.
और यह तय कर देता है कि कौनसी फ़ाइल किस फ़ॉर्मैट की है.
हालांकि, जानकारी का सटीक ब्यौरा, भाषा के हिसाब से अलग-अलग होता है. आम तौर पर,
है), तो Google किसी एक मॉड्यूल की तुलना में काफ़ी छोटे मॉड्यूल को पसंद करता है
आम तौर पर, टास्क पर आधारित बिल्ड सिस्टम में लिखा जाता है. आम तौर पर, प्रोडक्शन बाइनरी
Google अक्सर हज़ारों टारगेट पर निर्भर करता है. साथ ही, टारगेट के लिए
टीम अपने कोड बेस में सैकड़ों टारगेट अपने पास रख सकती है. इन भाषाओं के लिए
ऐसा Java जिसमें पैकेजिंग का बेहतरीन अनुभव मिलता है, हर डायरेक्ट्री आम तौर पर
इसमें एक पैकेज, टारगेट, और BUILD फ़ाइल (पैंट, दूसरा बिल्ड सिस्टम) मौजूद है
बेज़ल के आधार पर, इसे 1:1:1 नियम कहते हैं). कमज़ोर पैकेजिंग वाली भाषाएं
कन्वेंशन अक्सर हर BUILD फ़ाइल में कई टारगेट तय करते हैं.
छोटे बिल्ड टारगेट के फ़ायदे बड़े पैमाने पर दिखने लगते हैं, क्योंकि
इससे बिल्ड ज़्यादा तेज़ी से डिस्ट्रिब्यूट किए जाते हैं और टारगेट फिर से बनाने की ज़रूरत कम पड़ती है.
जब जांच के नतीजे और भी बेहतर हो जाते हैं, तो
ज़्यादा सटीक टारगेट का मतलब है कि बिल्ड सिस्टम
परीक्षणों का केवल एक सीमित सबसेट चलाना, जो किसी
बदलें. क्योंकि Google छोटे विज्ञापनों का इस्तेमाल करने से जुड़े व्यवस्थित फ़ायदों में भरोसा रखता है
हमने अपने प्रॉडक्ट और ब्रैंड के लिए,
यह टूल, BUILD फ़ाइलों को अपने-आप मैनेज करने की सुविधा देता है, ताकि डेवलपर के बोझ को कम किया जा सके.
buildifier और buildozer जैसे कुछ टूल इसके साथ उपलब्ध हैं
बेज़ल इन द
buildtools डायरेक्ट्री.
मॉड्यूल दिखने की संभावना कम करना
Basel और अन्य बिल्ड सिस्टम हर एक टारगेट को विज़िबिलिटी तय करने की अनुमति देते हैं —
प्रॉपर्टी की मदद से तय करता है कि कौनसे दूसरे टारगेट इस पर निर्भर कर सकते हैं. निजी टारगेट
का संदर्भ सिर्फ़ उसकी BUILD फ़ाइल में दिया जा सकता है. टारगेट के तहत, ज़्यादा लोगों तक पहुंचा जा सकता है
साफ़ तौर पर तय की गई BUILD फ़ाइलों की सूची के टारगेट को ऐक्सेस कर सकता है या
के मामले में हर टारगेट के लिए उपलब्ध है.
ज़्यादातर प्रोग्रामिंग भाषाओं की तरह, 'किसको दिखे' सेटिंग को आम तौर पर
जितना संभव हो सके. आम तौर पर, Google की टीमें टारगेट को सिर्फ़ तब सार्वजनिक करती हैं, जब
वे टारगेट, Google की किसी भी टीम के लिए उपलब्ध लाइब्रेरी के बारे में बताते हैं. ये लाइब्रेरी बड़े पैमाने पर इस्तेमाल की जाती हैं.
जिन टीमों को अपने कोड का इस्तेमाल करने से पहले दूसरों के साथ मिलकर काम करना होता है वे ये काम करेंगी
टारगेट की विज़िबिलिटी के तौर पर, उन लोगों या संगठनों की सूची को बनाए रखना जिन्हें अनुमति मिली हुई है. हर
टीम के आंतरिक कार्यान्वयन लक्ष्य केवल डायरेक्ट्री तक सीमित होंगे.
और ज़्यादातर BUILD फ़ाइलों का सिर्फ़ एक टारगेट होगा जो
निजी.
डिपेंडेंसी मैनेज करना
मॉड्यूल ऐसा होना चाहिए कि वे एक-दूसरे को रेफ़र कर सकें. साइट को सुरक्षित रखने के लिए,
कोड बेस के लिए एक सटीक मॉड्यूल होना चाहिए, ताकि आपको डिपेंडेंसी मैनेज करनी पड़े
में शामिल हैं (हालांकि, टूल इसे ऑटोमेट करने में मदद कर सकते हैं). इन्हें ज़ाहिर करना
आम तौर पर, डिपेंडेंसी BUILD फ़ाइल में मौजूद कॉन्टेंट का ज़्यादातर हिस्सा होती है.
इंटरनल डिपेंडेंसी
बारीक मॉड्यूल वाले किसी बड़े प्रोजेक्ट में, ज़्यादातर डिपेंडेंसी होती हैं संगठन के अंदर हो सकती है; यानी, उसी पर आधारित किसी अन्य टारगेट पर डेटा स्टोर करने की जगह. इंटरनल डिपेंडेंसी, बाहरी डिपेंडेंसी से इसमें अलग होती हैं: कि उन्हें पहले से बने आर्टफ़ैक्ट के तौर पर डाउनलोड करने के बजाय, सोर्स से बनाया गया हो बिल्ड रन करते समय. इसका मतलब यह भी है कि ऐसी किसी रणनीति के लिए “वर्शन” इंटरनल डिपेंडेंसी—टारगेट और उसकी सभी इंटरनल डिपेंडेंसी हमेशा डेटा स्टोर करने की जगह में उसी कमिट/रिविज़न के साथ बनाया जाता है. एक समस्या जो यह होनी चाहिए कि यह समझना ज़रूरी है कि आंतरिक डिपेंडेंसी का ध्यान रखते हुए कैसे काम किया जाए ट्रांज़िटिव डिपेंडेंसी (इमेज 1). मान लीजिए कि टारगेट A, टारगेट B पर निर्भर है. एक सामान्य लाइब्रेरी टारगेट C पर निर्भर होता है. क्या A को लक्षित करना चाहिए, जो क्लास का इस्तेमाल करने में सक्षम हो टारगेट C में तय किया गया है?
पहली इमेज. ट्रांज़िटिव डिपेंडेंसी
जहां तक बुनियादी टूल का सवाल है, इसमें कोई समस्या नहीं है; दोनों टारगेट A के बनने पर B और C को टारगेट A में जोड़ा जाएगा, इसलिए इनमें से कोई भी सिंबल C को A के तौर पर जाना जाता है. बेज़ल ने कई सालों तक इसकी मंज़ूरी दी, लेकिन जैसे-जैसे Google ने तरक्की की, हम में समस्याएं दिखने लगीं. मान लें कि B को इस तरह रीफ़ैक्ट किया गया था कि अब वह C पर निर्भर रहने की ज़रूरत थी. अगर C पर B की डिपेंडेंसी हटा दी गई है, तो A और अन्य B पर निर्भरता के ज़रिए C का इस्तेमाल करने वाला टारगेट काम नहीं करेगा. असरदार तरीके से, टारगेट डिपेंडेंसी उसके सार्वजनिक अनुबंध का हिस्सा बन गई और उसे कभी भी बदल दिया गया है. इसका मतलब है कि समय के साथ डिपेंडेंसी इकट्ठा होती है और Google धीमा होना शुरू हो गया है.
Google ने इस समस्या को हल करने के लिए, “स्ट्रिक्ट ट्रांज़िटिव” इस्तेमाल किया डिपेंडेंसी मोड” पर सेट करना होगा. इस मोड में, Basel को पता चलता है कि टारगेट सीधे निर्भर किए बिना किसी प्रतीक का संदर्भ देता है और, यदि है, तो इसके साथ विफल होता है और एक शेल कमांड का उपयोग किया जा सकता है, जिसका उपयोग निर्भर है. यह बदलाव Google के पूरे कोड बेस पर लागू होगा हम अपने लाखों बिल्ड टारगेट में से हर एक को ऑप्टिमाइज़ करते हैं, ताकि हम अपनी टारगेट ऑडियंस की डिपेंडेंसी के लिए कई सालों तक मेहनत करनी पड़ी, लेकिन यह मुमकिन था. हमारे बिल्ड हैं अब पहले से ज़्यादा तेज़ी से होने की वजह से, टारगेट पर ग़ैर-ज़रूरी चीज़ें कम हो गई हैं और इंजीनियर को बिना किसी चिंता के ऐसी चीज़ें हटाने की ताकत मिलती है जिनकी उन्हें ज़रूरत नहीं है जो उन टारगेट पर निर्भर हैं.
हमेशा की तरह, सख्त ट्रांज़िटिव डिपेंडेंसी लागू करने के दौरान ट्रेड-ऑफ़ हुआ. इसने बनाया
ज़्यादा जानकारी वाली फ़ाइलें बनाने की ज़रूरत होती है, क्योंकि अक्सर इस्तेमाल की जाने वाली लाइब्रेरी को अब सूची में जोड़ने की ज़रूरत होती है
कई जगहों पर हो सकता है, जबकि अचानक ऐसा नहीं हो सकता, लेकिन इंजीनियर
BUILD फ़ाइलों में डिपेंडेंसी जोड़ने में ज़्यादा मेहनत करनी पड़ी. हम तब से लेकर अब तक
हमने ऐसे टूल बनाए हैं जो किसी समस्या का पता लगाकर, उसे कम करने में मदद करते हैं.
डिपेंडेंसी और उन्हें बिना किसी डेवलपर के, BUILD फ़ाइलों में जोड़ना
मदद की जा सकती है. हालांकि, इन टूल के बिना भी, हमने तय किया है कि
कोडबेस स्केल के रूप में काम करता है: BUILD फ़ाइल पर साफ़ तौर पर डिपेंडेंसी जोड़ना
एक-बार की जाने वाली लागत है, लेकिन इंप्लिसिट ट्रांज़िटिव डिपेंडेंसी से काम करने पर
जब तक बिल्ड टारगेट मौजूद रहता है, तब तक समस्याएं बनी रहेंगी. बेज़ल
स्ट्रिक ट्रांज़िटिव डिपेंडेंसी लागू करता है
डिफ़ॉल्ट रूप से Java कोड पर सेट करें.
बाहरी डिपेंडेंसी
अगर कोई डिपेंडेंसी अंदरूनी नहीं है, तो इसे बाहरी होना चाहिए. बाहरी डिपेंडेंसी हैं उन आर्टफ़ैक्ट पर मौजूद होता है जिन्हें बिल्ड सिस्टम के बाहर बनाया और स्टोर किया जाता है. कॉन्टेंट बनाने डिपेंडेंसी को सीधे आर्टफ़ैक्ट डेटा स्टोर करने की जगह से इंपोर्ट किया जाता है (आम तौर पर, इसे ऐक्सेस किया जाता है का इस्तेमाल किया जाता है. इनमें से एक बाहरी और आंतरिक डिपेंडेंसी के बीच सबसे बड़ा अंतर यह है कि बाहरी डिपेंडेंसी के वर्शन होते हैं और वे वर्शन इनसे अलग होते हैं प्रोजेक्ट का सोर्स कोड है.
अपने-आप बनाम मैन्युअल डिपेंडेंसी मैनेजमेंट
बिल्ड सिस्टम की मदद से, बाहरी डिपेंडेंसी के वर्शन मैनेज किए जा सकते हैं
मैन्युअल तौर पर या अपने-आप. मैन्युअल रूप से मैनेज किए जाने पर, बिल्डफ़ाइल
आर्टफ़ैक्ट डेटा स्टोर करने की जगह से वह वर्शन साफ़ तौर पर डाउनलोड करता है जिसे वह डाउनलोड करना चाहता है,
अक्सर सिमेंटिक वर्शन स्ट्रिंग का इस्तेमाल किया जाता है, जैसे कि
1.1.4 के तौर पर. अपने-आप मैनेज होने पर, सोर्स फ़ाइल
की अनुमति है और बिल्ड सिस्टम हमेशा सबसे नया वर्शन डाउनलोड करता है. इसके लिए
उदाहरण के लिए, Gradle, डिपेंडेंसी वर्शन को “1.+” के तौर पर इस्तेमाल करने की अनुमति देता है, ताकि यह तय किया जा सके कि
कि किसी डिपेंडेंसी का कोई माइनर या पैच वर्शन तब तक स्वीकार किया जा सकता है, जब तक कि
मेजर वर्शन 1 है.
अपने-आप मैनेज होने वाली डिपेंडेंसी, छोटे प्रोजेक्ट के लिए आसान हो सकती हैं. हालांकि, आम तौर पर, छोटी-छोटी चीज़ों के बड़े साइज़ वाले प्रोजेक्ट की आपदा की रेसिपी है या जिस पर एक से ज़्यादा इंजीनियर काम कर रहे हैं. अपने-आप होने वाली समस्या मैनेज की जा रही डिपेंडेंसी यह है कि अपडेट किया गया. यह गारंटी देने का कोई तरीका नहीं है कि बाहरी पक्ष अपडेट (भले ही वे सिमैंटिक वर्शन के इस्तेमाल का दावा करें), इसलिए एक ऐसा बिल्ड क्या काम करती है, लेकिन अगले दिन काम करना बंद कर सकता है. साथ ही, यह पता करने का कोई आसान तरीक़ा नहीं है कि क्या बदलाव हुए हैं या उसे काम की स्थिति में वापस लाएं. अगर बिल्ड टूटता भी नहीं है, तो व्यवहार या परफ़ॉर्मेंस में ऐसे बदलाव हो सकते हैं जिन्हें ट्रैक करना नामुमकिन हो.
इसके उलट, मैन्युअल तरीके से मैनेज की जाने वाली डिपेंडेंसी के लिए सोर्स में बदलाव करना पड़ता है कंट्रोल करना मुमकिन है, तो उन्हें आसानी से खोजा और रोल बैक किया जा सकता है. साथ ही, पुरानी डिपेंडेंसी के साथ बनाने के लिए, रिपॉज़िटरी का पुराना वर्शन देखें. Basel की सभी डिपेंडेंसी के वर्शन मैन्युअल रूप से तय किए जाने चाहिए. बराबर सामान्य स्केल का इस्तेमाल करते हैं, तो मैन्युअल वर्शन मैनेजमेंट की ज़रूरत पड़ने पर, से कितनी स्थिरता मिलेगी.
एक वर्शन वाला नियम
लाइब्रेरी के अलग-अलग वर्शन को आम तौर पर, अलग-अलग आर्टफ़ैक्ट के ज़रिए दिखाया जाता है. इसलिए, यह सिद्धांत है कि एक ही बाहरी वर्शन के अलग-अलग बिल्ड सिस्टम में डिपेंडेंसी का एलान अलग-अलग नामों से नहीं किया जा सकता. इस तरह, हर टारगेट यह चुन सकता है कि वह डिपेंडेंसी का कौनसा वर्शन चाहता है इस्तेमाल करें. इस वजह से कई समस्याएं पैदा होती हैं. इसलिए, Google ने वन-वर्शन का नियम का उपयोग कर सकते हैं.
एक से ज़्यादा वर्शन की अनुमति देने में सबसे बड़ी समस्या डायमंड डिपेंडेंसी है समस्या. मान लीजिए कि टारगेट A, टारगेट B और किसी बाहरी कंपनी के v1 पर निर्भर है लाइब्रेरी. अगर टारगेट B को बाद में इसी के v2 पर डिपेंडेंसी जोड़ने के लिए रीफ़ैक्ट किया जाता है बाहरी लाइब्रेरी, लक्ष्य A ब्रेक होगा, क्योंकि अब यह स्पष्ट रूप से दो पर निर्भर है एक ही लाइब्रेरी के अलग-अलग वर्शन हैं. असरदार तरीके से, इस कस्टम फ़ाइल को जोड़ना टारगेट से कई वर्शन वाली तीसरे पक्ष की किसी लाइब्रेरी पर नई निर्भरता, क्योंकि उस टारगेट का कोई भी उपयोगकर्ता पहले से ही एक अलग वर्शन है. एक वर्शन वाले नियम का पालन करने से यह टकराव नामुमकिन हो जाता है—अगर टारगेट, किसी तीसरे पक्ष की लाइब्रेरी, किसी भी मौजूदा डिपेंडेंसी पर डिपेंडेंसी जोड़ता है पहले से ही उसी वर्शन पर हो जाएगा, ताकि वे साथ-साथ रह सकें.
ट्रांज़िटिव एक्सटर्नल डिपेंडेंसी
किसी बाहरी डिपेंडेंसी की ट्रांज़िटिव डिपेंडेंसी से निपटने में मुश्किल है. Maven सेंट्रल जैसे कई आर्टफ़ैक्ट डेटा स्टोर करने की जगहों पर, में मौजूद अन्य आर्टफ़ैक्ट के खास वर्शन की ज़रूरत के बारे में बताने के लिए आर्टफ़ैक्ट डेटा स्टोर करने की जगह. Maven या Gradle जैसे टूल बनाएं. इन्हें अक्सर बार-बार डाउनलोड किया जाता है डिफ़ॉल्ट रूप से ट्रांज़िटिव डिपेंडेंसी. इसका मतलब है कि एक डिपेंडेंसी जोड़ने पर, आपके प्रोजेक्ट की वजह से कई आर्टफ़ैक्ट डाउनलोड हो सकते हैं कुल.
यह बहुत सुविधाजनक है: किसी नई लाइब्रेरी पर निर्भरता जोड़ते समय, यह उस लाइब्रेरी की ट्रांज़िटिव डिपेंडेंसी में से हर एक को ट्रैक करने में बहुत परेशानी होती है और उन सभी को मैन्युअल तरीके से जोड़ें. लेकिन एक बहुत बड़ा नकारात्मक पहलू भी है: क्योंकि लाइब्रेरी एक ही तीसरे पक्ष की लाइब्रेरी के अलग-अलग वर्शन पर निर्भर हो सकती हैं, रणनीति से ज़रूरी तौर पर एक वर्शन के नियम का उल्लंघन होता है और यह डायमंड पर ले जाती है निर्भरता से जुड़ी समस्या. यदि आपका लक्ष्य दो ऐसी बाहरी लाइब्रेरी पर निर्भर है जो एक ही डिपेंडेंसी के अलग-अलग वर्शन हैं. इसलिए, यह नहीं बताया जा सकता कि आपको पाएं. इसका मतलब यह भी है कि किसी बाहरी डिपेंडेंसी को अपडेट करने से, ऐसा लग सकता है कि अगर कोड बेस में नए वर्शन का इसकी कुछ डिपेंडेंसी के विरोधी वर्शन.
इस वजह से, Basel, ट्रांज़िटिव डिपेंडेंसी को अपने-आप डाउनलोड नहीं करता.
अफ़सोस की बात यह है कि इस तरह के और भी कारगर तरीके नहीं हैं. इसलिए, बेज़ल का दूसरा विकल्प यह है कि
ग्लोबल फ़ाइल, जिसमें डेटा स्टोर करने की हर जगह के बाहरी हिस्से की सूची होती है
डिपेंडेंसी और उस डिपेंडेंसी के लिए इस्तेमाल किए गए एक साफ़ तौर पर दिए गए वर्शन का पूरा इस्तेमाल
डेटा स्टोर करने की जगह. अच्छी बात यह है कि Basel के टूल की मदद से,
ऐसी फ़ाइल जनरेट करें जिसमें Maven के सेट की ट्रांज़िटिव डिपेंडेंसी शामिल हो
आर्टफ़ैक्ट. शुरुआती WORKSPACE फ़ाइल जनरेट करने के लिए, इस टूल को एक बार चलाया जा सकता है
और फिर उस फ़ाइल को मैन्युअल रूप से अपडेट करके
पर लागू होती है.
एक बार फिर से बता दें कि सुविधा और बढ़ाए जा सकने की योग्यता में से एक को चुना जाएगा. छोटा ऐसा हो सकता है कि प्रोजेक्ट को ट्रांज़िटिव डिपेंडेंसी को मैनेज करने की चिंता न करनी पड़े और हो सकता है कि ऑटोमैटिक ट्रांज़िटिव का इस्तेमाल करके इस समस्या से छुटकारा मिल जाए निर्भरता. यह रणनीति, संगठन के तौर पर कम दिलचस्प होती जाती है और कोड बेस बढ़ता जाता है. साथ ही, कॉन्फ़्लिक्ट और अनचाहे नतीजे भी बढ़ता रहता है अक्सर. बड़े पैमाने पर, डिपेंडेंसी को मैन्युअल तौर पर मैनेज करने में आने वाला खर्च अपने-आप डिपेंडेंसी की वजह से होने वाली समस्याओं को हल करने में लगने वाले खर्च से कम है मैनेज करना.
एक्सटर्नल डिपेंडेंसी का इस्तेमाल करके बिल्ड के नतीजों को कैश मेमोरी में सेव करना
बाहरी डिपेंडेंसी अक्सर तीसरे पक्ष की ओर से दी जाती हैं जो बिना सोर्स कोड दिए लाइब्रेरी के स्थायी वर्शन बना सकते हैं. कुछ सूचनाएं मिल रही हैं संगठन अपने कुछ कोड इस तरह से भी उपलब्ध करा सकते हैं: इससे कोड के अन्य हिस्से, तीसरे पक्ष के तौर पर इस्तेमाल किए जा सकते हैं निर्भर नहीं करता है. यह सैद्धांतिक तौर पर उन बिल्ड की रफ़्तार को बढ़ा सकता है, बनाने में धीमी होती हैं, लेकिन तेज़ी से डाउनलोड हो जाती हैं.
हालांकि, इसकी वजह से बहुत ज़्यादा काम करना पड़ता है और समस्याएं भी पैदा होती हैं: किसी को उन सभी आर्टफ़ैक्ट को बनाने और उन्हें डेटा स्टोर करने की जगह का इस्तेमाल कर सकते हैं, और क्लाइंट को यह पक्का करना होगा कि वे सबसे नया वर्शन है. डीबग करना भी ज़्यादा मुश्किल हो जाता है, क्योंकि सिस्टम के हिस्सों को अलग-अलग पॉइंट से बनाया जाएगा. डेटा स्टोर करने की जगह है और अब सोर्स ट्री का व्यू एक जैसा नहीं है.
आर्टफ़ैक्ट बनाने में ज़्यादा समय लगने से, समस्या को हल करने का एक बेहतर तरीका यह है कि जैसा कि ऊपर बताया गया है, ऐसे बिल्ड सिस्टम का इस्तेमाल करना होगा जो रिमोट कैशिंग की सुविधा देता हो. ऐसा बिल्ड सिस्टम, हर बिल्ड से मिले आर्टफ़ैक्ट को किसी जगह पर सेव करता है जिसे कई इंजीनियर के बीच शेयर किया जाता है, इसलिए अगर डेवलपर ऐसे आर्टफ़ैक्ट पर हाल ही में किसी और ने बनाया था, तो बिल्ड सिस्टम अपने-आप उसे बनाने के बजाय उस पर सबसे ज़्यादा विचार करते हैं. इससे ऐप्लिकेशन की परफ़ॉर्मेंस के सभी फ़ायदे मिलते हैं यह सीधे तौर पर आर्टफ़ैक्ट पर निर्भर करता है. साथ ही, यह पक्का करता है कि बिल्ड जैसे कि उन्हें हमेशा एक ही सोर्स से बनाया गया हो. यह है रणनीति का इस्तेमाल Google अंदरूनी तौर पर करता है. साथ ही, Basel को रिमोट का इस्तेमाल करने के लिए कॉन्फ़िगर किया जा सकता है कैश मेमोरी.
बाहरी डिपेंडेंसी की सुरक्षा और विश्वसनीयता
तीसरे पक्ष के सोर्स से मिले आर्टफ़ैक्ट के आधार पर, इसमें नुकसान हो सकता है. कई
तीसरे पक्ष का सोर्स (जैसे, आर्टफ़ैक्ट डेटा स्टोर करने की जगह) के जाने पर उपलब्धता जोखिम
कम होता है, क्योंकि अगर आपका ऐप्लिकेशन डाउनलोड करने में असमर्थ होता है, तो आपका पूरा बिल्ड रुक सकता है
एक बाहरी डिपेंडेंसी है. सुरक्षा जोखिम भी होता है: अगर तीसरे पक्ष के सिस्टम ने
किसी हमलावर ने छेड़छाड़ की हो, तो हमलावर
अपने खुद के किसी डिज़ाइन वाले आर्टफ़ैक्ट के ज़रिए, उसे आर्बिट्रेरी कोड इंजेक्ट करने की अनुमति देता है
आपके बिल्ड में इस्तेमाल कर सकते हैं. किसी आर्टफ़ैक्ट को मिरर करके, दोनों समस्याओं को कम किया जा सकता है
यह उन सर्वर पर निर्भर करता है जिन्हें कंट्रोल किया जाता है और बिल्ड सिस्टम को ऐक्सेस करने से रोका जाता है
तीसरे पक्ष के आर्टफ़ैक्ट डेटा स्टोर करने की जगहें. जैसे, Maven सेंट्रल. समझौते की बात यह है कि
इन शीशों को बनाए रखने के लिए मेहनत और संसाधन लगते हैं. इसलिए, फ़ैसला लेने में मदद मिलती है कि
उनका इस्तेमाल अक्सर प्रोजेक्ट के साइज़ पर निर्भर करता है. सुरक्षा से जुड़ी समस्या की वजह से,
हर यूआरएल के लिए हैश की ज़रूरत करके, इसे थोड़े से ओवरहेड के साथ पूरी तरह रोका जा सकता है
तीसरे पक्ष के आर्टफ़ैक्ट को सोर्स रिपॉज़िटरी में शामिल किया जाना चाहिए. इससे
ताकि आर्टफ़ैक्ट के साथ छेड़छाड़ की जा सके. एक और विकल्प, जो पूरी तरह से
यह समस्या आपके प्रोजेक्ट की डिपेंडेंसी के लिए, वेंडर को करने में आती है. जब कोई प्रोजेक्ट
अपनी निर्भरताओं के साथ-साथ यह उन्हें सोर्स कंट्रोल में चेक इन करता है और
प्रोजेक्ट के सोर्स कोड को, सोर्स या बाइनरी के तौर पर शामिल कर सकते हैं. इसका मतलब है कि
प्रोजेक्ट की सभी एक्सटर्नल डिपेंडेंसी को इंटरनल डिपेंडेंसी में बदल दिया जाता है
निर्भरता. Google यह तरीका अंदरूनी तौर पर इस्तेमाल करता है और हर तीसरे पक्ष की जांच करता है
रूट पर एक third_party डायरेक्ट्री में पूरे Google में रेफ़र की गई लाइब्रेरी
सोर्स ट्री में रखा जा सकता है. हालांकि, यह Google में केवल इसलिए काम करता है, क्योंकि Google का
सोर्स कंट्रोल सिस्टम को इस तरह से बनाया गया है कि वह बहुत बड़े मोनो रिपॉज़िटरी को मैनेज कर सके.
हो सकता है कि वेंडरिंग की सुविधा सभी संगठनों के लिए उपलब्ध न हो.