भारी वजन वाले कॉरपोरेट, विन्यास प्रबंधन और परीक्षण आवश्यकताओं के साथ मरकरी रिपॉजिटरी संरचना

Question

मैं अभी तक एक और तोड़फोड़ उपयोगकर्ता हूं जो वितरित संस्करण नियंत्रण के ताओ में खुद को फिर से शिक्षित करने के लिए संघर्ष कर रहा है।

तोड़फोड़ का उपयोग करते समय, मैं प्रोजेक्ट-माइनर दृष्टिकोण का एक बड़ा प्रशंसक था, और, मेरे अधिकांश पूर्व नियोक्ताओं के साथ, हम अपनी रिपॉजिटरी शाखाओं की संरचना करेंगे; टैग और ट्रंक निम्नानुसार हैं:

branches-+
         +-personal-+
         |          +-alice-+
         |          |       +-shinyNewFeature
         |          |       +-AUTOMATED-+
         |          |                   +-shinyNewFeature
         |          +-bob-+
         |                +-AUTOMATED-+
         |                            +-bespokeCustomerProject
         +-project-+
                   +-shinyNewFeature
                   +-fixStinkyBug
tags-+
     +-m20110401_releaseCandidate_0_1
     +-m20110505_release_0_1
     +-m20110602_milestone
trunk

वास्तविक स्रोत वृक्ष के भीतर, हम निम्नलिखित संरचना का उपयोग करेंगे (जैसे कुछ):

  (src)-+
        +-developmentAutomation-+
        |                       +-testAutomation
        |                       +-deploymentAutomation
        |                       +-docGeneration
        |                       +-staticAnalysis
        |                       +-systemTest
        |                       +-performanceMeasurement
        |                       +-configurationManagement
        |                       +-utilities
        +-libraries-+
        |           +-log-+
        |           |     +-build
        |           |     +-doc
        |           |     +-test
        |           +-statistics-+
        |           |            +-build
        |           |            +-doc
        |           |            +-test
        |           +-charting-+
        |           |          +-build
        |           |          +-doc
        |           |          +-test
        |           +-distributedComputing-+
        |           |                      +-build
        |           |                      +-doc
        |           |                      +-test
        |           +-widgets-+
        |                     +-build
        |                     +-doc
        |                     +-test
        +-productLines-+
        |              +-flagshipProduct-+
        |              |                 +-coolFeature
        |              |                 +-anotherCoolFeature
        |              |                 +-build
        |              |                 +-doc
        |              |                 +-test
        |              +-coolNewProduct
        +-project-+
                  +-bigImportantCustomer-+
                  |                      +-bespokeProjectOne
                  |                      +-bespokeProjectTwo
                  +-anotherImportantCustomer-+
                                             +-anotherBespokeProject

इंजीनियरिंग टीम के बीच संरचना संचार में मदद करने के लिए रिपॉजिटरी की संरचना का उपयोग करने के लिए यह विचार (और अभी भी है) था; व्यवसाय का ग्राहक-सामना करने वाला हिस्सा और विभिन्न अन्य हितधारक और डोमेन विशेषज्ञ।

बुद्धि के लिए: "प्रोजेक्ट" निर्देशिकाओं में से एक में बैठने वाले स्रोत दस्तावेज केवल एक बार उपयोग किए जाते हैं (और पैसा कमाते हैं)। "प्रोडक्टलाइन" निर्देशिकाओं में से एक में बैठने वाले दस्तावेज़ पैसे कमाते हैं जितनी बार उस विशेष लाइन से उत्पाद बेचा जाता है। दस्तावेज़ जो "पुस्तकालयों" निर्देशिकाओं में से एक में बैठते हैं, वे कई बार पैसा कमाते हैं जितना कि उन उत्पादों में से कोई भी जो उन्हें बेच देता है।

यह लागतों के परिशोधन की धारणा को स्पष्ट करता है, और व्यापार में स्रोत दस्तावेज़ पुन: उपयोग के लिए समर्थन बनाने में मदद करता है।

इसका मतलब यह भी है कि एक सामान्य संरचना है, जिस पर हमारे निर्माण स्वचालन उपकरण काम कर सकते हैं। (हमारी बिल्ड स्क्रिप्ट "निर्माण" फ़ोल्डरों की तलाश में स्रोत ट्री पर चलती है, जिसके भीतर वे कॉन्फ़िगरेशन फ़ाइलों को निर्दिष्ट करते हैं कि प्रत्येक घटक का निर्माण कैसे किया जाता है? प्रलेखन पीढ़ी और परीक्षण के लिए एक समान प्रक्रिया होती है)।

गौरतलब है कि जिन उत्पादों पर मैं काम करता हूं उनमें आम तौर पर प्रदर्शन माप और लक्षण वर्णन परीक्षण चलाने के लिए एक लंबा समय लगता है; 20 से 200 घंटे तक; संसाधित परीक्षण परिणामों / मध्यवर्ती डेटा के कई टीबी से कई जीबी के बीच कहीं उत्पन्न करना (जो कि एक विशेष सिस्टम कॉन्फ़िगरेशन में संग्रहीत और बंधा होना चाहिए ताकि समय के साथ प्रदर्शन में सुधार किया जा सके)। यह समस्या कॉन्फ़िगरेशन प्रबंधन को एक महत्वपूर्ण विचार बनाती है, और केंद्रीकरण के लिए कुछ आवश्यकता भी लगाती है, क्योंकि आमतौर पर प्रदर्शन मापन और लक्षण वर्णन परीक्षण चलाने के लिए आवश्यक कम्प्यूटेशनल संसाधन सीमित होते हैं; (64-128 कोर का एक छोटा समूह)।

एक अंतिम नोट के रूप में; निरंतर एकीकरण प्रणाली को पता है कि इसे एक बिल्ड को ट्रिगर करने की आवश्यकता है; स्थिर विश्लेषण; हर बार ट्रंक को संशोधित करने के लिए हर बार ट्रंक को संशोधित किया जाता है, और हर बार किसी भी "टैग" शाखा को संशोधित किया जाता है। इस तरह, व्यक्तिगत डेवलपर्स अपनी व्यक्तिगत शाखाओं, एक महत्वपूर्ण क्षमता, IMHO के साथ CI सिस्टम का उपयोग कर सकते हैं।

अब, यहाँ मेरा सवाल है: मैं उपरोक्त सभी को कैसे दोहरा सकता हूं (और यदि संभव हो तो इसे सुधारें), मर्क्यूरियल के साथ।

--edit:

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

Comments

वाह। इसका एक अच्छा जवाब मुझे लगता है कि एक बहुत लंबा निबंध होने जा रहा है।

— एड जेम्स

मुझे लगता है कि प्रमुख सवाल यह है कि कोड मर्ज कैसे और कहां हो रहे हैं जो संभवतः कम से कम प्रतिरोध के मार्ग को परिभाषित करेंगे। तो, कोड का विलय कैसे होता है?

— व्याट बार्नेट

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

— विलियम पायने

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

— विलियम पायने

Answer 1

स्पोइक का उत्तर उत्कृष्ट है, लेकिन कुछ चीजें हैं जो मुझे लगता है कि यह जोड़ने लायक होगी जो टिप्पणियों के लिए बहुत बड़ी हैं।

शाखा संगठन

मर्क्यूरियल के साथ आप अपने पहले संगठनात्मक चार्ट को खुशी से अनदेखा कर सकते हैं। जैसा कि स्पोक कहता है, प्रत्येक रिपॉजिटरी के पास टैग, शाखाएं (नाम और अनाम) का एक सेट है और इसे व्यावसायिक आवश्यकता के अनुसार आयोजित किया जा सकता है।

यदि पुस्तकालय के bespokeProjectTwoएक विशेष संस्करण की आवश्यकता है charting, तो आप शाखा देंगे charting, नई सुविधाओं को जोड़ेंगे और इसका उपयोग करेंगे bespokeProjectTwo। नई सुविधाओं (और उनके कीड़े) का उपयोग अन्य परियोजनाओं द्वारा नहीं किया जाएगा जो मानक chartingपुस्तकालय का संदर्भ देंगे । यदि मुख्य chartingपुस्तकालय में कीड़े होते हैं, तो आप उन परिवर्तनों को शाखा में विलय कर सकते हैं। यदि अन्य परियोजनाओं को भी इन सुविधाओं की आवश्यकता होती है, तो आप विशेष परियोजना का उपयोग करने के लिए उन परियोजनाओं को प्राप्त कर सकते हैं , या शाखा को मुख्य-पंक्ति में विलय कर सकते हैं और शाखा को बंद कर सकते हैं।

इसके अलावा, आपकी AUTOMATION शाखाओं जैसी विशिष्ट सुविधाएं प्रदान करने के लिए शाखा नाम रखने के लिए आपके पास एक नीति नहीं है।

निर्देशिका संगठन

ऐसा कोई कारण नहीं है कि आप अपने स्रोत निर्देशिका को ठीक वैसे ही नहीं रख सकते हैं जैसा कि Mercurial के साथ है। एकमात्र अंतर यह है कि जबकि तोड़फोड़ के साथ आपके पास एक एकल अखंड (src)भंडार है, मर्क्यूरियल के साथ आप रिपॉजिटरी में विभाजित होने से बेहतर हैं जो तार्किक रूप से समूहीकृत हैं। आपके स्रोत वृक्ष की संरचना से, मैं निम्नलिखित में से प्रत्येक को अलग-अलग रिपॉजिटरी के रूप में निकालूंगा:

src-+
      +-(developmentAutomation)
      +-libraries-+
      |           +-(log)
      |           +-(statistics)
      |           +-(charting)
      |           +-(distributedComputing)
      |           +-(widgets)
      +-productLines-+
      |              +-(flagshipProduct)
      |              +-(coolNewProduct)
      +-project-+
                +-bigImportantCustomer-+
                |                      +-(bespokeProjectOne)
                |                      +-(bespokeProjectTwo)
                +-anotherImportantCustomer-+
                                           +-(anotherBespokeProject)

यह किसी भी संशोधन पर पुस्तकालयों के किसी भी संयोजन का उपयोग करने के लिए किसी भी उत्पाद या बीस्पोक परियोजना की अनुमति देता है । किसी उत्पाद या परियोजना के किसी भी संस्करण के लिए पुस्तकालयों का उपयोग करने के प्रबंधन के आसान तरीके के लिए व्यापारिक उप-रिपॉजिटरी पर एक नज़र डालें ।

कार्यप्रवाह

स्पोइक के सुझाए गए वर्कफ़्लो का एक विकल्प (डेवलपर धन्य रेपो से स्थानीय रूप से काम करता है, एक पुल अनुरोध जारी करता है और अंत में इंटीग्रेटर उन परिवर्तनों को खींचता है और उन्हें विलय करता है) एक मध्यस्थ के रूप में निरंतर एकीकरण प्रणाली का उपयोग करना होगा।

पहले की तरह, डेवलपर धन्य रेपो से खींचता है और स्थानीय रूप से काम करता है, लेकिन जब किया जाता है, तो वे धन्य रेपो से फिर से खींचते हैं और एक निर्बाध रेपो में धकेलने से पहले खुद को विलय कर लेते हैं। अनबेल्ड रेपो में किसी भी बदलाव की समीक्षा की जाती है (या तो मैन्युअल रूप से या स्वचालित रूप से) और स्वीकृत रेपो में स्थानांतरित कर दिया जाता है, केवल तभी जब वे स्वीकृत हों।

इसका मतलब यह है कि इंटीग्रेटर केवल एक बदलाव को स्वीकार या अस्वीकार करता है, मर्ज नहीं करता है। ^{मेरे अनुभव में यह डेवलपर के लिए लगभग हमेशा बेहतर होता है जिसने इसे करने के लिए किसी और से विलय करने के लिए कोड लिखा था।}

जैसा कि व्यापारिक पुस्तक में बताया गया है, इस प्रक्रिया को स्वचालित करने के लिए हुक का उपयोग किया जा सकता है:

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

अन्य मामले

बड़े परीक्षण डेटासेट की समस्या को उस परीक्षण डेटा को एक व्यापारिक उप-रिपॉजिटरी में डालकर भी हल किया जा सकता है । यह टेस्ट डेटा के साथ कोड रिपॉजिटरी को ब्लोट होने से रोकेगा, जबकि टेस्ट डेटा को रिविजन कंट्रोल में रखेगा।

Comments

फिर, एक और उत्कृष्ट और जानकारीपूर्ण उत्तर। धन्यवाद।

— विलियम पेने

पुन: शाखा संगठन। मैं सहमत हूं कि पहले संगठनात्मक चार्ट को खुशी से अनदेखा किया जा सकता है। यह विशेष रूप से अच्छी तरह से वर्कफ़्लो का संचार नहीं करता था, और इसलिए सम्मेलन को सुदृढ़ करने से परे कोई वास्तविक उपयोगिता प्रदान नहीं कर रहा था। मैं इसे बदलना चाहता हूं, हालांकि, कुछ ऐसा है जो दृढ़ता से एक (सरल-संभव) वर्कफ़्लो का संचार करता है, और लगातार कमिट को प्रोत्साहित करता है। शायद मुख्य "ट्रंक / विकास" शाखा को "दैनिक" कहकर ऐसा करना होगा?

— विलियम पायने

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

— विलियम पेने

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

— विलियम पायने

@WilliamPayne - धन्यवाद। हालांकि मर्क्यूरियल लचीला है, उपयुक्त रिपोजिटरी, शाखाओं और हुक के साथ आप जो भी प्रतिबंध चाहते हैं, संगठनात्मक या रिपॉजिटरी स्तर पर बना सकते हैं। व्यक्तिगत रूप से, मैं बस संगठनात्मक नियंत्रण, और कुछ CI हुक के साथ शुरू करूंगा, और भविष्य में उन नियंत्रणों का विस्तार करूंगा क्योंकि उनकी आवश्यकता स्पष्ट हो जाती है। इसके अलावा, सब-रेपो का विवेकपूर्ण उपयोग, उदाहरण के लिए, लोगों को स्थानीय रूप से उसी संरचना में चीजों की जांच करने के लिए प्रोत्साहित कर सकता है जैसे कि यह सर्वर पर है, उदाहरण के लिए productLinesया bigImportantCustomerसुपर-रिपोज के रूप में।

— मार्क बूथ

Answer 2

ठीक है, बस इसका जवाब देने की कोशिश कर रहा हूं।

आप क्या जानना चाहते है

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

• स्रोत एक रिपॉजिटरी से आते हैं, जहां उस रिपॉजिटरी को क्लोन किया जा सकता है। सभी क्लोन रिपॉजिटरी एक दूसरे के साथ सिंकिंग (पुश और पुश कमांड के साथ कोड साझा कर सकते हैं, जो कि प्रतिबंधित हो सकते हैं)।
• प्रत्येक उपयोगकर्ता जिसके पास कोड की एक प्रति है, उसके पास रिपॉजिटरी का क्लोन है। यदि वे शाखा करना चाहते हैं, तो वे इसे अपने स्थानीय क्लोन में कर सकते हैं। इसका मतलब है कि आपको यह व्यवस्थित करने की आवश्यकता नहीं है कि प्रत्येक उपयोगकर्ता को कैसे शाखा देना चाहिए। वे अपने लिए ऐसा कर सकते हैं।
• टैग एक कमिट द्वारा मर्क्यूरियल में बनाए गए हैं (जो कि गिट में हार्ड टैग के समान है)। इसका मतलब है कि आपको टैग के लिए अपनी रिपॉजिटरी संरचना के अंदर निर्देशिका की आवश्यकता नहीं है।

• लोग जो सामान्य मॉडल DVCS में काम करते हैं (जो कि github और bitbucket में नियोजित है) इसे अर्ध-केंद्रीकृत करना है।

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

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

रिपोजिटरी-प्रति-प्रोजेक्ट सेटअप

तो सामान्य सेट अप यह है कि प्रत्येक परियोजना के लिए निम्नलिखित है:

• एक सार्वजनिक रीड-ओनली रिपॉजिटरी जिसे इंटीग्रेटर जिम्मेदार है। यह "धन्य" है।

  यानी सभी उपयोगकर्ता सामग्री को खींच सकते हैं / ले जा सकते हैं लेकिन उसे धक्का देने की कोई पहुँच नहीं है।

• प्रत्येक उपयोगकर्ता के पास रिपॉजिटरी का अपना सार्वजनिक क्लोन हो सकता है।

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

• प्रत्येक उपयोगकर्ता के पास रिपॉजिटरी के अपने निजी क्लोन हो सकते हैं।

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

स्रोत कोड संगठन

जैसे कि प्रोजेक्ट स्रोत को कैसे व्यवस्थित करना है, कुछ ऐसा है जिसके बारे में आपको सोचने की जरूरत है। यदि किसी कलाकृति को स्रोत नियंत्रित करने की आवश्यकता है तो उसे स्रोत नियंत्रण में रखें। व्यक्तिगत रूप से मुझे उन कलाकृतियों में जाँच करने का विचार पसंद नहीं है जो बायनेरिज़ या लॉग फ़ाइलों जैसे बिल्ड या रनटाइम (इस प्रकार की कलाकृतियों पर मर्ज संघर्ष के उच्च जोखिम के कारण) हैं।

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

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

मुझे उम्मीद है कि यह सब समझ में आता है। कृपया नीचे टिप्पणी करें यदि मुझे कुछ विस्तार याद आया या यदि कुछ और समझाने की आवश्यकता है और मैं संपादित करने का प्रयास करूंगा।

Comments

कई बहुत उपयोगी बिंदुओं के साथ बहुत अच्छी प्रतिक्रिया के लिए +1। आपके जवाब के पहले खंड के जवाब में, मैंने प्रत्येक उपयोगकर्ता के अपने सार्वजनिक भंडार होने के महत्व को नहीं समझा था। शायद मुझे यह सोचने की ज़रूरत है कि पीयर-टू-पीयर वर्कफ़्लोज़ कैसे व्यवस्थित किया जा सकता है।

— विलियम पेने

आपके उत्तर के दूसरे खंड के जवाब में, पूरे बिंदु (मेरे दिमाग में) पूरे संगठन के लिए एक एकल रिपॉजिटरी होने का मतलब है कि कैसे काम की संरचना के लिए एक साझा मानसिक छवि बनाना है, और उन घटकों को ढूंढना आसान बनाना है जो कर सकते हैं फिर से उपयोग किया जाए। (बाज़ार के बजाय कैथेड्रल बहुत, लेकिन वह वातावरण जिसमें मैं काम करता हूं)। मैं वास्तव में जानना चाहूंगा कि डीसीवीएस के साथ संरचित संगठन (फाइलिंग सिस्टम) की समान भावना कैसे प्राप्त की जाए।

— विलियम पायने

आपके उत्तर के तीसरे खंड के जवाब में: मैं पूरे दिल से मानता हूं कि स्रोत नियंत्रण प्रणाली स्रोत दस्तावेजों के लिए है, और व्युत्पन्न कलाकृतियाँ वहां से संबंधित नहीं हैं। मैं यह भी मानता हूं कि वीसीएस में किसी भी विवरण के बड़े बायनेरिज़ को स्टोर करना अव्यावहारिक है। हालांकि, मेरा मानना ​​है कि आप एक सहमति वाले नेटवर्क स्थान में बड़े बायनेरिज़ को एक परिभाषित नाम के साथ स्टोर कर सकते हैं, और उन्हें वीसीएस के भीतर से संदर्भित कर सकते हैं। उदाहरण के लिए, बिल्ड वातावरण (s) को VM डिस्क छवियों के रूप में संग्रहीत किया जा सकता है, और विभिन्न बिल्ड स्क्रिप्ट से संदर्भित किया जा सकता है। (उदाहरण: मुझे build_env_A पर बनाएँ)। यही बात टेस्ट डेटा के लिए भी है।

— विलियम पायने

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

— विलियम पायने