एक वितरित वास्तुकला में, संस्करणों का प्रबंधन करना मुश्किल क्यों है?

Question

मैं इस बार और समय फिर से देखता हूं। यूएटी टेस्ट मैनेजर चाहता है कि नया निर्माण शुक्रवार तक परीक्षण के लिए तैयार हो। पूर्व-परीक्षण मीटिंग में पूछे गए पहले प्रश्नों में से एक है, "मैं किस संस्करण का परीक्षण करूँगा?" (जो पूछने के लिए एक उचित सवाल है)। कमरा चुप हो जाता है, तो कोई वापस आ जाएगा, "सभी असेंबली के पास अपना स्वयं का संस्करण है, बस राइट-क्लिक करें और गुणों को देखें ..."।

परीक्षण प्रबंधकों के दृष्टिकोण से, इसका कोई उपयोग नहीं है। वे सब कुछ पर एक संस्करण/लेबल/टैग चाहते हैं जो उन्हें बताता है कि वे क्या काम कर रहे हैं। वे यह जानकारी आसानी से avaialble चाहते हैं।

मैंने समाधान देखा है जहां एक डेटास्टोर में एक सिस्टम के अलग-अलग क्षेत्रों का संस्करण संग्रहीत किया जा रहा है, फिर मुख्य एप्लिकेशन के बारे में बॉक्स पर दिखाया गया है। समस्या यह है कि इसे बनाए रखने की जरूरत है।

क्या समस्याएं आपने देखी हैं जो समस्या के चलते इसके आसपास हो जाती हैं?

संपादित करें। वितरित प्रणाली में वीबी 6, क्लासिक एएसपी, वीबी नेट, सी #, वेब सर्विसेज (विभागों में, हम किस संस्करण का उपयोग कर रहे हैं?), एसक्यूएल सर्वर 2005.

Answer 1

मुझे लगता है कि समस्या यह है कि आप और आपका परीक्षण प्रबंधक दो अलग-अलग चीजों के बारे में बात कर रहे हैं। असेंबली संस्करण असेंबली के लिए बहुत अच्छे हैं, लेकिन यदि आपका टेस्ट मैनेजर एक उच्च स्तरीय संस्करण, एक "सिस्टम संस्करण" के बारे में बात कर रहा है, तो आप करेंगे। कम से कम यह आपकी पोस्ट का मेरा पठन है।

आपको ऐसी परिस्थितियों में क्या करना है, यह आपके सभी अलग-अलग घटक असेंबली को सिस्टम संस्करण में मैप करना है। आप सिस्टम के संस्करण 1.5 की पंक्तियों के साथ कुछ कहते हैं Foo.Bar.dll v1.4.6 और Baz.Qux.dll v2.6.7 और (आदि) से बना है। नरक, एक वितरित प्रणाली में, आप अपनी प्रत्येक सेवाओं के लिए अलग-अलग संस्करण चाहते हैं, जो कि स्वयं के और अपने आप में हो सकते हैं, डीडीएस के विभिन्न संस्करणों से बना हो सकते हैं। आप कह सकते हैं, उदाहरण के लिए: "सिस्टम का संस्करण 1.5 Foo सेवा v1.3 से बना है, जो Foo.dll v1.9.3 और Bar.dll v1.6.9, और बार सेवा v1.9 से बना है, जो कि Baz.dll v1.8.2 और Qux.dll v1.5.2 और (आदि) से बना है "।

इस तरह की चीजें करना आम तौर पर आपके संगठन में सॉफ़्टवेयर आर्किटेक्ट और/या बिल्ड मैनेजर का काम है।

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

Answer 2

this page पर एक नज़र डालना चाहता है जो कुछ तरीकों से बताता है अपनी निर्माण प्रक्रिया में लगातार संस्करण को एकीकृत करने के लिए।

Answer 3

आंतरिक संदर्भों के अलावा किसी भी चीज़ के लिए बिल्ड आधारित संस्करण संख्या का उपयोग नहीं कर रहा है। जब यूएटी प्रबंधक सवाल पूछता है तो आप "शुक्रवार * * कहते हैं।

एकमात्र चाल यह सुनिश्चित करना है कि लेबलिंग आपके स्रोत नियंत्रण में विश्वसनीय रूप से हो।

* सम्मिलित उचित डेटस्टैम्प/लेबल यहाँ

Answer 4

हम नेट और सबवर्सन का उपयोग करें। हमारे सभी एप्लिकेशन असेंबली एक संस्करण संख्या साझा करते हैं, जो मैन्युअल रूप से अपडेट किए गए प्रमुख और मामूली संशोधन संख्या और सबवर्जन संशोधन संख्या (<major>.<minor>.<revision>) से ली गई है। हमारे पास एक प्रीबिल्ड कार्य है जो साझा संस्करण VersionInfo.vb फ़ाइल में इस संस्करण संख्या को अद्यतन करता है। फिर जब परीक्षक संस्करण संख्या के लिए पूछते हैं, तो हम उन्हें पूर्ण 3-भाग संख्या या केवल उपversण संशोधन दे सकते हैं। जिन पुस्तकालयों का हम उपभोग करते हैं वे बदल नहीं रहे हैं या परिवर्तन परीक्षक के लिए प्रासंगिक नहीं है।

Answer 5

समस्या में योगदान देने वाली कई अलग-अलग चीजें हैं। मेरे सिर के ऊपर से, यहां एक है:

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

फिर भी, यह एक उचित सवाल है, लेकिन एक जिसके लिए एक गैर-मामूली उत्तर सार्थक होने की आवश्यकता है।