विभिन्न क्लाइंट और सर्वर संस्करणों का परीक्षण करने के लिए सर्वश्रेष्ठ गिट रणनीति

Question

मैं जावा क्लाइंट/सर्वर (एम्बेडेड जेट्टी का उपयोग करके) के लिए एकीकरण परीक्षण चलाने में सक्षम होना चाहता हूं। इसके अलावा मैं एकीकरण परीक्षण के दौरान विभिन्न सर्वर और क्लाइंट स्रोत कोड संस्करणों को मिश्रित और मिलान करने में सक्षम होना चाहता हूं।

मैं क्या सबसे अच्छा Git या Maven संस्करण रणनीति यह पूरा करने के सोच रहा हूँ:

1. क्लाइंट और सर्वर के लिए एक ही Git भंडार का उपयोग करना, यह विभिन्न सर्वर संस्करणों में से चेकआउट कोड करना मुश्किल होगा और विभिन्न क्लाइंट संस्करणों के कोड के खिलाफ इसका परीक्षण करें।

2. अलग गिट भंडारों (क्लाइंट स्रोत और एकीकरण परीक्षण के साथ पहला भंडार, सर्वर स्रोत के साथ दूसरा भंडार) का उपयोग करना - इसे एकीकरण परीक्षण चलाने के लिए दोनों रिपॉजिटरीज को चेकआउट करने की आवश्यकता होगी, और उनके बीच सापेक्ष पथ मानें।

3. केवल मैवेन-संस्करण सर्वर WAR के विरुद्ध क्लाइंट स्रोत कोड का परीक्षण करना, परिणामस्वरूप सर्वर के विरुद्ध परीक्षण चलाने वाले डेवलपर्स की ईमानदार गलतियों का परिणाम हो सकता है जो चेक-आउट सर्वर स्रोत कोड से मेल नहीं खाता है।

Answer 1

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

टैग का उपयोग करें ताकि आप भविष्य में फिर से अपने मैट्रिक्स में एक ही परीक्षण का पुन: उपयोग कर सकें और दोहरा सकें, खासकर बग को पहले दौर से तय करने के बाद।

संक्षेप में, मैं आपके समाधान # 2 की अनुशंसा करता हूं। सापेक्ष पथ धारणा submodules द्वारा पेश संभावित भ्रम के लिए बेहतर है।

Answer 2

मैं एक तीसरी चुनौती बताउंगा: एकीकरण परीक्षण में बग हो सकती है, ताकि आप परीक्षा संस्करण को स्वतंत्र रूप से भी नियंत्रित कर सकें।

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

जब कोई नया डेवलपर टीम में शामिल होता है, तो वे इस मूल रेपो को क्लोन कर सकते हैं, फिर क्लाइंट और सर्वर सबोड्यूल क्लोन करने के लिए git submodule update --init चलाएं। इस तरह उनके पास कोई भी रिश्तेदार पथ होगा जो हर किसी के समान ही स्थापित होगा।

हालांकि, मुझे यह कहना पसंद नहीं है कि क्लाइंट रेपो मान लेता है कि सर्वर ../server/ पर है। तो जिस तरह से मैंने इसे संभाला है, वह माता-पिता को रिपोर्डेड को किसी भी आवश्यक पथ को पारित करने देना है। उदाहरण के लिए, आप माता-पिता रेपो कि

make -C client SERVER_PATH=$(pwd)/server test 

चलाता है आपके मामले में में एक test.sh हो सकता था, आप पैरेंट रेपो में सभी परीक्षण कोड लगा सके। फिर यह submodules के सापेक्ष पथ सुरक्षित रूप से ग्रहण कर सकते हैं।

इस व्यवस्था का एक दिलचस्प साइड लाभ: आप गिट काम कर सकते हैं जो संस्करणों के विशिष्ट संयोजन रिकॉर्ड करते हैं, क्योंकि जब आप पेरेंट रेपो में प्रतिबद्ध होते हैं तो सबमिशन में चेक किया गया संस्करण रिकॉर्ड किया जाता है। आप अपने परीक्षणों को पारित करने वाले संस्करण संयोजनों के लिए शाखा बनाने या टैग का संग्रह बनाने के लिए इसका उपयोग कर सकते हैं।