git वितरित संस्करण नियंत्रण प्रणाली और उद्यम-एक अच्छा मिश्रण?




version-control mercurial (8)

मैं देख सकता हूं कि क्यों वितरित स्रोत नियंत्रण प्रणाली (डीवीसीएस - मर्कुरियल की तरह) ओपन सोर्स प्रोजेक्ट्स के लिए समझ में आता है।

लेकिन क्या वे एक उद्यम के लिए समझ में आता है? (एक केंद्रीकृत स्रोत नियंत्रण प्रणाली जैसे कि टीएफएस)

एक डीवीसीएस की कौन सी विशेषताएं कई डेवलपर्स के साथ एक उद्यम के लिए बेहतर या बदतर बनाती हैं? (एक केंद्रीकृत प्रणाली पर)


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


कम से कम टीएफएस 2013 के साथ आपके पास स्थानीय वर्कस्पेस से डिस्कनेक्ट करने की क्षमता है। वितरित बनाम केंद्रीकृत व्यापार द्वारा परिभाषित किया गया है और विकास के तहत परियोजनाओं की आवश्यकताओं और आवश्यकताओं पर निर्भर करता है।

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

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

आवेदन जीवन चक्र प्रबंधन प्रक्रिया का एक सिंहावलोकन यहां पाया जा सकता है।

http://msdn.microsoft.com/en-us/library/vstudio/fda2bad5(v=vs.110).aspx


मेरे लिए वे सबसे बड़ी चीज की पेशकश स्पीड है। वे केंद्रीकृत स्रोत नियंत्रण की तुलना में सबसे आम परिचालनों के लिए तीव्रता के आदेश हैं।

डिस्कनेक्ट काम करना भी एक बड़ा प्लस है।


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

बॉक्स के बाहर, गिट कोई अनुमति नहीं देता है - आपको अपने स्वयं के लिखने के लिए हुक मिल गया है।

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

रीड एक्सेस का समर्थन करने के बारे में मैंने जो एकमात्र रिपो मैनेजर सुना है, वह पर्सफोर्स हेलिक्स है, जो प्रतिभा बैकएंड के शीर्ष पर गिट प्रोटोकॉल को दोहराता है, लेकिन मेरे पास इसका कोई अनुभव नहीं है। यह वादा कर रहा है, लेकिन मुझे चिंता होगी कि यह "सादा" गिट के साथ कितना संगत है।


रिमोट / डिस्कनेक्ट किए गए स्थानों में बेहतर सिंक्रनाइज़ेशन।


बिल्कुल एक वितरित स्रोत मॉडल एक उद्यम में समझ में आता है, लेकिन यह आपकी टीमों की संरचना पर निर्भर करता है।

वितरित स्रोत नियंत्रण आपको अपने स्वयं के वर्कफ़्लो बनाने के लिए लचीलापन देता है।

कल्पना कीजिए, यदि आप करेंगे, तो एक बड़ी टीम, जिसमें अलग-अलग फीचर शाखाओं पर काम करने वाली छोटी टीमें होंगी।

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

ये वे चीजें हैं जिन्हें आप एक पारंपरिक केंद्रीकृत सर्वर के साथ प्राप्त कर सकते हैं , लेकिन जैसा कि @ ब्रूक बताते हैं, केंद्रीकृत मॉडल को स्केल करना पड़ता है, जबकि वितरित मॉडल पहले ही शेड किया जाता है, इसलिए कोई (या कम से कम, कम) किसी भी सर्वर को लंबवत रूप से स्केल करने की आवश्यकता नहीं होती है।


ऑफ़लाइन या धीमी नेटवर्क के लिए केंद्रीकृत सिस्टम की तुलना में डीएससीएस की एक बेहतर कहानी (आमतौर पर) है। वे तेजी से होते हैं, जो डेवलपर्स (टीडीडी का उपयोग करके) के लिए वास्तव में उल्लेखनीय है जो बहुत सारे चेक-इन करते हैं।

केंद्रीकृत सिस्टम प्रारंभिक रूप से समझने के लिए कुछ हद तक आसान होते हैं और कम अनुभवी डेवलपर्स के लिए बेहतर विकल्प हो सकते हैं। DVCSes आपको बहुत सारी मिनी-शाखाएं बनाने और कोडिंग की हरे रंग की शैली पर लाल-ग्री-रिफैक्टर चेकइन करते समय नई सुविधाओं को अलग करने की अनुमति देता है। फिर यह बहुत शक्तिशाली है लेकिन काफी समझदार विकास टीमों के लिए केवल आकर्षक है।

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

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

संक्षेप में विचार करने के लिए कुछ तकनीकी पहलू हैं लेकिन आपको अपनी टीम की परिपक्वता और एससीसीएस के आसपास उनकी वर्तमान प्रक्रिया के बारे में भी सोचना चाहिए।


मैंने अभी एक बड़ी बैंकिंग कंपनी में एक डीवीसीएस (इस मामले में गिट) पेश किया है, जहां पर्सफोर्स, एसवीएन या क्लीयरकेस विकल्प के केंद्रीकृत वीसीएस थे:
मुझे पहले से ही चुनौतियों का पता था (मेरा पिछला जवाब देखें " क्या हम अंततः कॉर्पोरेट सॉफ्टवेयर में डीवीसीएस में जा सकते हैं? क्या एसवीएन अभी भी विकास के लिए 'होना चाहिए'? )

मुझे तीन मोर्चों पर चुनौती दी गई है:

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

  • प्रमाणीकरण : एक डीवीसीएस आपको अपने कोड को "साइन-ऑफ" (प्रतिबद्ध) करने की अनुमति देता है ... बहुत ज्यादा कोई भी (लेखक " foo ", ईमेल " [email protected] ")।
    आप एक git config user.name foo , या git config user.name whateverNameIFeelToHave कर सकते हैं, और इसमें आपके सभी कामों को फर्जी नाम के साथ कर सकते हैं।
    यह बड़े उद्यमों द्वारा उपयोग की जाने वाली अद्वितीय केंद्रीकृत "सक्रिय निर्देशिका" उपयोगकर्ता रेफरेंसियल के साथ अच्छी तरह से मिश्रण नहीं करता है।

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

उत्तर (एक गिट सेटअप के लिए) था:

  • केंद्रीकरण : किसी भी भंडार के लिए सभी उपयोगकर्ताओं द्वारा सुलभ होने के लिए एक अद्वितीय सर्वर स्थापित किया गया है।
    बैकअप का ख्याल रखा जा रहा है (हर दिन बढ़ती है, हर सप्ताह पूर्ण)।
    डीआरपी (आपदा रिकवरी प्लान) को दूसरी साइट पर दूसरे सर्वर के साथ, और SRDF माध्यम से रीयल-टाइम डेटा प्रतिकृति के साथ कार्यान्वित किया गया है।
    यह सेटअप स्वयं में रेफरेंसियल या टूल के प्रकार से स्वतंत्र है (डीवीसीएस, या नेक्सस रेपो, या मुख्य हडसन शेड्यूलर, या ...): किसी भी उपकरण जो उत्पादन में रिलीज के लिए महत्वपूर्ण हो सकता है सर्वर पर स्थापित करने की आवश्यकता है बैकअप और डीआर के साथ।

  • प्रमाणीकरण : केवल दो प्रोटोकॉल उपयोगकर्ताओं को मुख्य प्रतिनिधि तक पहुंचने की अनुमति देते हैं:
    • एसएसएच आधारित, सार्वजनिक / निजी कुंजी के साथ:
      • संगठन के बाहर उपयोगकर्ताओं के लिए उपयोगी (जैसे किनारे के विकास),
      • और जेनेरिक खातों के लिए उपयोगी है कि सक्रिय निर्देशिका प्रबंधक बनाना नहीं चाहता (क्योंकि यह एक "अज्ञात" खाता होगा): उस वास्तविक व्यक्ति के लिए एक वास्तविक व्यक्ति को ज़िम्मेदार होना चाहिए, और वह निजी कुंजी का मालिक होगा
    • https-आधारित, एक अपाचे के साथ जो एलडीएपी सेटिंग के माध्यम से उपयोगकर्ताओं को प्रमाणित करता है: इस तरह, उन रिपो पर किसी भी गिट ऑपरेशन के लिए एक वास्तविक लॉगिन प्रदान किया जाना चाहिए।
      गिट इसे अपने स्मार्ट http प्रोटोकॉल के साथ प्रदान करता है, जो केवल http के माध्यम से pull नहीं सकता है, बल्कि http के माध्यम से push (लिखना) भी देता है।

प्रमाणीकरण भाग को गिट लेवल पर एक post-receive हुक द्वारा भी मजबूत किया जाता है जो सुनिश्चित करता है कि कम से कम एक जो आप रेपो को दबा रहे हैं, में "कमिटर नाम" शाह या http प्रोटोकॉल के माध्यम से उपयोगकर्ता नाम के बराबर होता है।
दूसरे शब्दों में, आपको अपने git config user.name सही तरीके से सेट करने की आवश्यकता है, या कोई भी पुश जिसे आप केंद्रीय रिपो में बनाना चाहते हैं, को खारिज कर दिया जाएगा।

  • प्रमाणीकरण : पिछली सेटिंग्स (एसएसएच या https) दोनों को पैरामीटर स्क्रिप्ट के समान सेट को कॉल करने के लिए वायर्ड किया गया है, जिसका नाम gitolite , पैरामीटर के साथ:
    • उन दो प्रोटोकॉल द्वारा पता चला वास्तविक उपयोगकर्ता नाम
    • गिट कमांड (क्लोन, पुश या पुल) जो उपयोगकर्ता करना चाहता है

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

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

फिर, और केवल तब, एक डीवीसीएस (गिट, Mercurial, ...) के कारण मूल्य जोड़ सकते हैं:

  • एकाधिक साइटों के बीच डेटा एक्सचेंज : जबकि उन सभी उपयोगकर्ताओं को एक ही सक्रिय निर्देशिका के माध्यम से प्रमाणित किया जाता है, वे दुनिया भर में स्थित हो सकते हैं (जिन कंपनियों के लिए मैंने काम किया है, वे आम तौर पर दो या तीन देशों में टीमों के बीच विकास करते हैं)। एक वितरित टीमों के बीच कुशलतापूर्वक डेटा का आदान-प्रदान करने के लिए एक डीवीसीएस स्वाभाविक रूप से बनाया जाता है।

  • वातावरण में प्रतिकृति : प्रमाणीकरण / प्राधिकरण की देखभाल करने वाली सेटिंग अन्य समर्पित सर्वरों (एकीकरण परीक्षण, यूएटी परीक्षण, पूर्व-उत्पादन और पूर्व-तैनाती के उद्देश्यों के लिए) पर उन रिपॉजिटरीज को क्लोन करने की अनुमति देती है।

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

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

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




dvcs