इबर एक बड़े संगठन में Mercurial का उपयोग करना




साइबर सुरक्षा क्या और क्यों (3)

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

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

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

किसी के पास इसका अनुभव है, या सलाह?

संबंधित सवाल:


सबसे पहले, विशाल परियोजनाओं में एक डीवीसीएस का उपयोग करने पर हालिया चर्चा प्रासंगिक है:

बड़ी परियोजनाओं के लिए वितरित संस्करण नियंत्रण - क्या यह व्यवहार्य है?

Mercurial के साथ एक शिकन यह है कि यह "परियोजना" प्रति एक एकल भंडार रखने के विचार के आसपास डिजाइन किया गया प्रतीत होता है।

हां, जबकि सबवर्सन के साथ मानक एक बहुविकल्पीय भंडार है जिसमें कई परियोजनाएं हैं, एक डीवीसीएस के साथ एक प्रति घटक के साथ, अधिक बारीक भंडार रखने के लिए बेहतर है। सबवर्सन में svn:externals चेकआउट समय पर एकाधिक स्रोत पेड़ों को एकत्रित करने की सुविधा है (जिसमें इसकी अपनी तार्किक और तकनीकी समस्याएं हैं)। Mercurial और Git दोनों में एक समान सुविधा है, जिसे hg में subrepos कहा जाता है।

Subrepos के साथ विचार है कि आपके पास प्रति घटक एक रेपो है, और एक रिलीज करने योग्य उत्पाद (एकाधिक पुन: प्रयोज्य घटकों को शामिल करना) बस इसके आश्रित प्रतिनिधि को संदर्भित करेगा। जब आप उत्पाद रेपो क्लोन करते हैं, तो यह आवश्यक घटकों के साथ लाता है।

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

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

एक चेतावनी यह है कि सबप्रो समर्थन एक अपेक्षाकृत हालिया विशेषता है, और यह अन्य सुविधाओं के रूप में पूरी तरह से नहीं है। विशेष रूप से, सभी एचजी कमांड subrepos के बारे में नहीं जानते हैं, हालांकि सबसे महत्वपूर्ण लोग करते हैं।

मेरा सुझाव है कि आप एक परीक्षण रूपांतरण करते हैं, और उपरोक्त समर्थन के साथ प्रयोग, उत्पादों और आश्रित घटकों का आयोजन आदि। मैं एक ही काम करने की प्रक्रिया में हूं, और ऐसा लगता है कि यह जाने का तरीका है।


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

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

एक उद्यम संदर्भ में DVCS बनाम सीवीसीएस:

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

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

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

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

वर्कफ़्लो:

लैरी ओस्टर्मन (विंडोज टीम पर काम कर रहे एक माइक्रोसॉफ्ट देव) के पास विंडोज टीम में कार्यरत वर्कफ़्लो के बारे में एक महान ब्लॉग पोस्ट है । सबसे विशेष रूप से उनके पास है:

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

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

(तस्वीर जोएल hginit.com के hginit.com से चोरी हो गई है।)

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

एक उद्यम संदर्भ में Mercurial:

मैं यहां एक गिट बनाम एचजी फ्लेमियर शुरू नहीं करना चाहता हूं, आप DVCS पर स्विच करने पर विचार करके पहले से ही सही रास्ते पर हैं। गिट के बजाय Mercurial का उपयोग करने के कुछ कारण यहां दिए गए हैं:

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

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

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


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

प्रोवर्बियल बिल्ली को त्वचा के कई तरीके हैं जो आपको बैठने और अपने वर्कफ़्लो के बारे में सावधानी से सोचने के लिए भुगतान करेंगे। अपने वर्तमान प्रथाओं और शक्ति के बारे में सोचें जो लगभग मुक्त क्लोनिंग और ब्रांचिंग आपको देता है। ऐसा लगता है कि वर्तमान में जो कुछ आप करते हैं वह सीवीएस-प्रकार मॉडल की सीमाओं के आसपास काम करने के लिए विकसित होगा; मोल्ड तोड़ने के लिए तैयार रहें। आपको संक्रमण के माध्यम से सभी को आराम करने के लिए शायद एक चैंपियन या दो नियुक्त करने की आवश्यकता होगी; एक बड़ी टीम के साथ आप शायद आशीर्वाद तक पहुंच पहुंच प्रतिबंधित करने के बारे में सोचना चाहते हैं।

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

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

मुझे लगता है कि आप इसे पहले ही जानते हैं, लेकिन यदि आप सीवीएस से दूर जाने पर विचार कर रहे हैं, तो आप एसवीएन से बहुत बेहतर कर सकते हैं ...

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

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

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

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





dvcs