गिट-बिसेक्ट, लेकिन एन रेपोस के लिए

Question

हमारा सॉफ्टवेयर मॉड्यूलर है और मेरे पास एक प्रोजेक्ट में लगभग 20 गिट रेपो हैं।

यदि कोई परीक्षण विफल रहता है, तो कभी-कभी मेलिंग प्रतिबद्धता को ढूंढना कठिन होता है क्योंकि कई डेवलपर्स इन 20 रेपो पर काम करते हैं।

मुझे पता है कि कल कल परीक्षण किया गया था और आज अपमानजनक विफल रहता है।

कभी-कभी मैं गिट-बिसेक का उपयोग करता हूं, लेकिन यह केवल एक गिट रेपो के लिए काम करता है।

अक्सर दो गिट रेपो में परिवर्तन एक परीक्षण विफल हो जाते हैं।

मैं एक गंदे लिपि लिख सकता हूं जो मेरे एन गिट रेपो पर खुद को लूप्स करता है, लेकिन ऐसा करने से पहले, मैं जानना चाहता हूं कि विशेषज्ञ इसका समाधान कैसे करेंगे।

मैं पाइथन, डीजेगो और पायस्टेस्ट का उपयोग करता हूं, लेकिन AFAIK इससे इस प्रश्न के लिए कोई फर्क नहीं पड़ता।

Answer 1

जटिल परियोजनाओं को प्रबंधित करने के लिए मैं व्यक्तिगत रूप से repo tool का उपयोग करना पसंद करता हूं। Manifest.xml में उन 20 रिपोज़ को रखें और प्रत्येक बार जब निर्माण शुरू होता है तो पैच मैनिफेस्ट बनाते हैं यदि बिल्ड विफल रहता है तो यह देखने के लिए कि क्या बदला गया था और कहां है।

Answer 2

"रिवर्स निर्भरता" सीआई निर्माण के लिए क्यूए उपकरण की श्रेणी है। इसलिए जब भी निम्न स्तर में परिवर्तन किया जाता है तो आपकी उच्च स्तरीय परियोजनाओं का पुनर्निर्माण किया जाता है। पैमाने पर यह संसाधन गहन हो सकता है।

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

गिट submodules व्यक्तिगत प्रतिबद्धताओं के लिए ट्रैकिंग को पूरा करते हैं, तो आप फिर से तय करते हैं कि निचले स्तर से परिवर्तन कब शामिल करें। (विशेष रूप से, यह रिलीज़ संस्करणों की तरह भी इस्तेमाल किया जा सकता है यदि आप कभी भी टैग की गई रिलीज कमेट्स को अपडेट करते हैं।)