वर्जनिंग एक ऐसी चीज है, जिसके बारे में मैं बहुत भावुक हूं और वर्जनिंग सिस्टम का उपयोग करने के लिए एक लंबा समय बिताने की कोशिश कर रहा हूं। आपने अपने प्रश्न में जो पहले ही कहा है उससे यह स्पष्ट है कि आप एक महत्वपूर्ण बिंदु को समझ गए हैं, विधानसभा संस्करण संख्याएं उत्पाद संस्करण का पर्याय नहीं हैं। एक तकनीकी रूप से संचालित है, और दूसरा व्यवसाय द्वारा संचालित है।
निम्न मानता है कि आप स्रोत नियंत्रण और बिल्ड सर्वर के कुछ रूप का उपयोग करते हैं। संदर्भ के लिए हम TeamCity और Subversion / Git का उपयोग करते हैं । TeamCity परियोजनाओं की एक छोटी (10) संख्या के लिए स्वतंत्र है और एक बहुत अच्छा बिल्ड सर्वर है, लेकिन कुछ अन्य हैं, जिनमें से कुछ पूरी तरह से स्वतंत्र हैं।
क्या एक संस्करण संख्या का मतलब है
एक संस्करण का अर्थ एक व्यक्ति से दूसरे व्यक्ति के लिए कुछ अलग हो सकता है, सामान्य संरचना प्रमुख, मामूली, स्थूल, सूक्ष्म है। जिस तरह से मैं एक संस्करण संख्या को देखता हूं, उसे दो भागों में तोड़ना है। पहली छमाही में मुख्य संस्करण (मेजर) और किसी भी प्रमुख अपडेट (माइनर) का वर्णन किया गया है। दूसरी छमाही इंगित करता है कि यह कब बनाया गया था और स्रोत कोड संस्करण क्या था। संस्करण संख्याओं का अर्थ संदर्भ के आधार पर अलग-अलग चीजें भी हैं, क्या यह एपीआई, वेब ऐप आदि है।
Major। Minor। Build।Revision
Revision यह स्रोत नियंत्रण से ली गई संख्या है जो यह पहचानने के लिए कि वास्तव में क्या बनाया गया था।Buildयह एक बढ़ती हुई संख्या है जिसका उपयोग बिल्ड सर्वर पर किसी विशेष निर्माण को खोजने के लिए किया जा सकता है। यह एक महत्वपूर्ण संख्या है क्योंकि बिल्ड सर्वर ने मापदंडों के एक अलग सेट के साथ एक ही स्रोत को दो बार बनाया हो सकता है। स्रोत संख्या के साथ संयोजन में बिल्ड नंबर का उपयोग करने से आपको यह पहचानने की अनुमति मिलती है कि क्या बनाया गया था और कैसे।Minorयह केवल तभी बदलना चाहिए जब सार्वजनिक इंटरफ़ेस में महत्वपूर्ण परिवर्तन हो। उदाहरण के लिए, यदि यह एक एपीआई है, तो क्या उपभोग कोड अभी भी संकलन करने में सक्षम होगा? मेजर नंबर बदलने पर यह संख्या शून्य पर रीसेट होनी चाहिए।Majorइंगित करता है कि आप किस उत्पाद पर हैं। उदाहरण के लिए सभी VisualStudio 2008 विधानसभाओं के मेजर 9 हैं और VisualStudio 2010 10 हैं।
नियम का अपवाद
नियम में हमेशा अपवाद होते हैं और आपको उनके अनुरूप आते ही अनुकूल बनाना होगा। मेरा मूल दृष्टिकोण तोड़फोड़ का उपयोग करने पर आधारित था लेकिन हाल ही में मैं गिट में स्थानांतरित हो गया हूं। स्रोत नियंत्रण जैसे कि तोड़फोड़ और स्रोत सुरक्षित जो केंद्रीय भंडार का उपयोग करते हैं उनके पास एक संख्या होती है जिसका उपयोग किसी निश्चित समय से स्रोतों के एक विशेष सेट की पहचान करने के लिए किया जा सकता है। यह एक वितरित स्रोत नियंत्रण जैसे कि गिट के लिए मामला नहीं है। क्योंकि Git वितरित रिपॉजिटरी का उपयोग करता है जो कि प्रत्येक विकास मशीन पर होते हैं कोई भी ऑटो इंक्रीमेंटिंग नंबर नहीं है जिसका आप उपयोग कर सकते हैं, एक हैक है जो चेक-इन की संख्या का उपयोग करता है लेकिन यह बदसूरत है। इस वजह से मुझे अपना दृष्टिकोण विकसित करना पड़ा है।
Major। Minor। Macro।Build
संशोधन संख्या अब चली गई है, बिल्ड वहां स्थानांतरित हो गया है जहां संशोधन हुआ करता था और मैक्रो डाला गया है। आप मैक्रो का उपयोग कर सकते हैं कि आप कैसे फिट दिखते हैं लेकिन ज्यादातर समय मैं इसे अकेला छोड़ देता हूं। क्योंकि हम TeamCity का उपयोग करते हैं, संशोधन संख्या से खोई जानकारी को बिल्ड में पाया जा सकता है, इसका मतलब है कि दो चरण की प्रक्रिया है लेकिन हमने कुछ भी नहीं खोया है और एक स्वीकार्य समझौता है।
क्या सेट करना है?
समझने वाली पहली बात यह है कि असेंबली संस्करण, फ़ाइल संस्करण और उत्पाद संस्करण का मिलान नहीं करना है। मैं संख्याओं के अलग-अलग सेट होने की वकालत नहीं कर रहा हूँ, लेकिन यह असेंबली में छोटे बदलाव करते समय जीवन को बहुत आसान बना देता है जो किसी भी सार्वजनिक इंटरफेस को प्रभावित नहीं करता है जो आपको निर्भर असेंबलियों को फिर से स्थापित करने के लिए मजबूर नहीं करता है। जिस तरह से मैं इससे निपटता हूं वह केवल विधानसभा संस्करण में मेजर और माइनर संख्याओं को सेट करना है, लेकिन फ़ाइल संस्करण में सभी मान सेट करना है। उदाहरण के लिए:
- 1.2.0.0 (असेंबलीवेशन)
- 1.2.3.4 (FileVersion)
यह आपको हॉट फ़िक्स को रोल आउट करने की क्षमता देता है जो मौजूदा कोड को नहीं तोड़ेगा क्योंकि असेंबली के संस्करण मेल नहीं खाते हैं लेकिन आपको इसकी फ़ाइल संस्करण संख्या को देखकर असेंबली का संशोधन / निर्माण देखने की अनुमति देता है। यह एक सामान्य दृष्टिकोण है और विधानसभा के विवरणों को देखने पर कुछ खुले स्रोत विधानसभाओं पर देखा जा सकता है।
जब कभी भी किसी ब्रेकिंग परिवर्तन की आवश्यकता होती है, तो टीम लीड के रूप में आपको मामूली संख्या को बढ़ाने के लिए जिम्मेदार होना होगा। एक इंटरफ़ेस के लिए आवश्यक परिवर्तन को बाहर करने के लिए एक समाधान लेकिन पिछले कोड को नहीं तोड़ना वर्तमान को अप्रचलित के रूप में चिह्नित करना और एक नया इंटरफ़ेस बनाना है। इसका मतलब है कि मौजूदा कोड को चेतावनी दी गई है कि यह विधि अप्रचलित है और इसे किसी भी समय हटाया जा सकता है लेकिन आपको तुरंत सब कुछ तोड़ने की आवश्यकता नहीं है। आप अप्रचलित विधि को हटा सकते हैं जब सब कुछ माइग्रेट हो गया हो।
इसे एक साथ तार कैसे करें
आप उपरोक्त सभी मैन्युअल रूप से कर सकते हैं लेकिन यह बहुत समय लेने वाला होगा, निम्नलिखित हम इस प्रक्रिया को कैसे स्वचालित करते हैं। प्रत्येक चरण चलाने योग्य है।
- निकालें
AssemblyVersionऔर AssemblyFileVersionसभी प्रोजेक्ट असेंबलीइन्फो .cs फ़ाइलों से विशेषताएँ।
- एक सामान्य असेंबली जानकारी फ़ाइल बनाएं (इसे VersionInfo.cs पर कॉल करें) और इसे अपने सभी प्रोजेक्टों से लिंक किए गए आइटम के रूप में जोड़ें।
- "0.0.0.0" के मान के साथ संस्करण में जोड़ें
AssemblyVersionऔर AssemblyFileVersionविशेषताएँ।
- एक MsBuild प्रोजेक्ट बनाएं जो आपकी समाधान फ़ाइल बनाता है।
- संस्करणइनफो.क्स को अपडेट करने वाले निर्माण से पहले एक कार्य में जोड़ें। वहाँ कई खुले स्रोत MsBuild पुस्तकालयों कि एक असेंबली शामिल हैं कार्य जो संस्करण संख्या सेट कर सकते हैं। बस इसे एक मनमानी संख्या और परीक्षण के लिए सेट करें।
- बिल्ड नंबर के प्रत्येक सेगमेंट के लिए एक संपत्ति समूह जोड़ें जिसमें एक संपत्ति हो। यह वह जगह है जहाँ आप प्रमुख और मामूली सेट करते हैं। निर्माण और संशोधन संख्या को तर्क के रूप में पारित किया जाना चाहिए।
तोड़फोड़ के साथ:
<PropertyGroup>
<Version-Major>0</Version-Major>
<Version-Minor>0</Version-Minor>
<Version-Build Condition=" '$(build_number)' == '' ">0</Version-Build>
<Version-Build Condition=" '$(build_number)' != '' ">$(build_number)</Version-Build>
<Version-Revision Condition=" '$(revision_number)' == '' ">0</Version-Revision>
<Version-Revision Condition=" '$(revision_number)' != '' ">$(revision_number)</Version-Revision>
</PropertyGroup>
उम्मीद है कि मैं स्पष्ट हूं लेकिन इसमें बहुत कुछ शामिल है। कृपया कोई प्रश्न पूछें। मैं एक और संक्षिप्त ब्लॉग पोस्ट को एक साथ रखने के लिए किसी भी प्रतिक्रिया का उपयोग करूंगा।