सेंट्रल बैंक या कोड प्रबंधन संस्करण नियंत्रण

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

यह कागज पर चिकनी थी

हमारे Intel® Media SDK प्रोजेक्ट में डेवलपर्स को अलग-अलग अनुभव था, और परिणामस्वरूप, उनके द्वारा किए गए जोखिमों और परिणामों की अलग-अलग समझ। डेवलपर्स द्वारा कमिट का बिल्कुल भी परीक्षण नहीं किया गया था, या परीक्षण की मात्रा अपर्याप्त थी।
कुछ गलत / असामयिक तरीके से (उदाहरण के लिए, वर्तमान के लिए नहीं बल्कि उत्पाद के अगले संस्करण के लिए उन्मुख) उत्पाद की रिहाई से पहले मंच पर महत्वपूर्ण (शो स्टॉपर) त्रुटियों की उपस्थिति के लिए नेतृत्व किया। एक सीमित समय के संसाधन की स्थिति में, डेवलपर्स ने अपनी उपस्थिति के कारणों को स्थापित करने में काफी कठिनाइयों का अनुभव किया। चूंकि त्रुटियों को तुरंत ठीक नहीं किया जा सकता था, इस कारण उत्पाद की रिलीज की तारीख में बदलाव हुआ।
यह सब इस तथ्य से जटिल था कि संस्करण नियंत्रण प्रणाली में काम करने वाले हमेशा अच्छी टिप्पणी नहीं करते थे। हमारी परियोजना में इस स्थिति को बदलने का कोई भी प्रयास असफल रहा।

उपरोक्त समस्याओं के समाधान के रूप में, CCB को हमारी परियोजना में विकसित किया गया था - अपाचे, माईएसक्यूएल, पीएचपी का उपयोग कर कंट्रोल बोर्ड टूल खोलें, जो ओपन सोर्स एमर्जेनस पर्सनेल इन्फॉर्मेशन सिस्टम (ईएमपीआरआईएस) ( आर्टिस्टिक लाइसेंस के तहत वितरित ) पर आधारित है।

टूल कैसे काम करता है?

CCB उत्पाद के बीटा संस्करण की योजनाबद्ध रिलीज़ से 2-3 सप्ताह पहले "शामिल" होता है। एक विशेष स्क्रिप्ट सबवर्सन में नए कमिट्स की उपस्थिति को ट्रैक करती है और उन्हें CCB डेटाबेस में डालती है। प्रतिबद्ध लेखक को वेब फॉर्म के लिंक के साथ ई-मेल आमंत्रण मिलता है। इसे भरने के बाद, टूल में कमिट को "SUBMITTED" स्थिति में स्थानांतरित कर दिया जाता है। टूल में, सभी कमिट्स को कमिट के लेखक द्वारा काफी अच्छी तरह से वर्णित किया जाता है, जिसमें इस बारे में जानकारी शामिल है कि कमेट क्यों बनाया गया था, क्या बदला गया था, इसका परीक्षण कैसे किया गया था, उत्पाद के लिए कमिटमेंट क्या जोखिम रखता है।
सभी कमिटियों का निरीक्षण सामान्य डेवलपर्स - साथियों और प्रोजेक्ट लीडर द्वारा किया जाता है। समीक्षकों के नाम स्वचालित रूप से उपकरण द्वारा निर्दिष्ट किए जाते हैं या कमिट के लेखक द्वारा चुने जा सकते हैं। समीक्षक एक ईमेल निमंत्रण प्राप्त करता है, पत्र से लिंक का अनुसरण करता है, कमिट स्वीकार करता है या अस्वीकार करता है। यदि यह वचन स्वीकार कर लिया जाता है, तो इसे "स्वीकार" स्थिति में रखा जाता है।
केवल प्रमोटर (प्रोजेक्ट लीडर) को कमिटमेंट को एक विशेष टैग में स्थानांतरित करने के लिए अधिकृत किया जाता है, जिससे उत्पाद का स्रोत कोड अंततः नवीनतम संशोधन से लिया जाता है। प्रमोटर को प्रतिबद्ध का निरीक्षण करने के लिए एक ईमेल आमंत्रण मिलता है। अगर प्रमोटर द्वारा कमिट स्वीकार कर लिया जाता है, तो इसे "PROMOTED" स्थिति में स्थानांतरित कर दिया जाता है, और कमिट के सोर्स कोड में परिवर्तन टैग में जोड़ दिए जाते हैं।

प्रक्रिया ने परिणाम को सही ठहराया

यद्यपि CCB उत्पाद में त्रुटियों को ठीक नहीं करता है, लेकिन उपकरण उस प्रतिबद्ध को स्थानीय बनाने की प्रक्रिया को बहुत सरल करता है जिससे पता चला त्रुटियों की घटना हुई। CCB का उपयोग करना, आवागमन के बारे में अधिक जानकारी प्राप्त करना सुविधाजनक है। अनुरोध पर किए गए कमिट का चयन करने के लिए उपकरण में एक सुविधाजनक खोज इंजन है:

• समय की एक निश्चित अवधि में;
• एक विशिष्ट घटक में;
• विशिष्ट डेवलपर;
• एक विशिष्ट त्रुटि के लिए;
• एक विशिष्ट घटक के लिए;
• एक विशिष्ट मंच के लिए।

CCB एक प्रभावी "प्रशासनिक संसाधन" का एक अच्छा उदाहरण बन गया जब किसी परियोजना में कोड कमिट की संस्कृति को बढ़ाने के अन्य तरीके काम नहीं करते थे। वास्तव में, यहां तक ​​कि जब डेवलपर किसी भी त्रुटि का पता लगाता है, तो इस कार्य को पूरा करने के लिए, यह उसके लिए पर्याप्त नहीं है कि वह केवल सबवर्सन में अपने बदलावों के लिए प्रतिबद्ध है, इस प्रतिबद्धता को CCB में सभी निरीक्षण चरणों से गुजरना होगा। यदि उपकरण में पूरी निरीक्षण प्रक्रिया के माध्यम से प्रतिबद्ध नहीं होता है, तो यह उत्पाद में नहीं मिलेगा। केवल प्रोजेक्ट लीडर द्वारा आवश्यक कमिट टैग में आते हैं।
इस प्रकार, CCB कमिट के लिए लेखकों की जिम्मेदारी को काफी बढ़ा देता है। CCB एक सहकर्मी कोड समीक्षा के रूप में भी कार्य करता है और लॉग और संकेतक बनाने के लिए एक उपकरण के रूप में कार्य करता है।

जटिल करना सरल है, सरल करना कठिन है

हमारी परियोजना में 4 वर्षों के लिए CCB का उपयोग किया गया है और इस समय के दौरान उपयोगकर्ताओं से बहुत प्रतिक्रिया मिली है और, तदनुसार, कार्यक्षमता में सुधार। मैं उनमें से कुछ को सबसे ज्यादा याद किया जाता हूं।

उपयोगकर्ताओं से प्रतिक्रिया प्राप्त करने के बाद जोड़े गए कार्य (वे प्राप्त किए गए क्रम में):

1. CCB टेम्पलेट (तोड़फोड़ में एक टिप्पणी में मुद्रित) के अनुसार प्रतिबद्ध। यह टूल में प्रवेश करने और वेब फ़ॉर्म में फ़ील्ड भरने का एक विकल्प है।

CCB टेम्पलेट:

summary:          [ ] bug:   [ ] what changed:       [ ] how tested:       [ ] reviewer: email  [ ] comments:   [ ] 

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

3. व्यक्तिगत आवागमन के लिए सरलीकृत निरीक्षण। यदि लेखक, किसी वैध कारण के लिए, CCB को अपनी प्रतिबद्धता का विवरण नहीं देता है, इसलिए, उसने निरीक्षण के लिए एक प्रतिबद्ध नहीं भेजा (उदाहरण के लिए, वह अनुपस्थित था)। अनुस्मारक मदद नहीं करता है, और प्रतिबद्ध को तत्काल सुरक्षित करने की आवश्यकता है। वह प्रोजेक्ट लीडर किसी भी कमिट की स्थिति को बदल सकता है।

4. समान अधिकारों वाले कई प्रवर्तक। यदि किसी कारण से परियोजना के नेता को कमिट नहीं मिल सकता है, तो अन्य नियुक्त प्रमोटर इसे कर सकते हैं।

5. कई चयनित टैग में प्रचार करें। दो परियोजनाएं प्रोग्राम कोड की एक ही शाखा का उपयोग कर सकती हैं और कुछ सीमित सेटों में भिन्न हो सकती हैं। ऐसी परियोजनाओं के लिए, विभिन्न टैग का उपयोग करना सुविधाजनक है। फिर, डिफ़ॉल्ट रूप से, कोड को एक ही बार में दोनों टैग को बढ़ावा दिया जाएगा, और व्यक्तिगत कमिट के लिए, प्रमोटर की पसंद पर, केवल एक टैग।

अभी तक जोड़ा समारोह नहीं:

व्यक्तिगत घटकों के लिए निरीक्षण निरीक्षण को सरल बनाएं। यदि घटक विशेष रूप से महत्वपूर्ण नहीं है, तो समय बचाने के लिए इस घटक में कमिटों को सीधे टैग किए बिना उन्हें स्थानांतरित करना बेहतर होगा।

आप किन उपकरणों का उपयोग करते हैं?