एक आधुनिक संस्करण नियंत्रण प्रणाली के लाभों को निर्धारित करना [बंद]

Question

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

जॉइनिंग के दौरान मैंने जो पहली चीजें कीं उनमें से एक मेरी टीम को गिट के साथ स्थापित करना था। सभी सहमत थे कि क्लियरकेस भयानक था और दिन-प्रतिदिन के स्रोत नियंत्रण मामलों को संभालने के लिए अव्यावहारिक था। इसलिए हमने अपने स्थानीय मशीन पर "अनऑफिशियल" रिपॉजिटरी की स्थापना की और मैंने रिलीज के समय के आसपास अपने गिट और क्लीयरकेस रिपोज को सिंक करने के लिए एक स्क्रिप्ट लिखी।

इस शब्द का अन्य टीमों में प्रसार हुआ और कई ने एक ही प्रक्रिया अपनाई। दिन की गतिविधियों के लिए "अनौपचारिक" तरीके से गिट का उपयोग करना और रिलीज के लिए क्लीयरकेस का उपयोग करके "आधिकारिक तौर पर"। मैं Git के साथ किसी भी मुद्दे के लिए आदमी को जाने की तरह हो गया हूँ।

इसलिए मैंने इस हफ्ते एसवीपी के साथ बुनियादी ढांचे में बदलाव के लिए एक बैठक की है, जो विशेष रूप से चाहते हैं कि मैं उन्हें गिट की खूबियों के बारे में समझाऊं। शब्द स्पष्ट रूप से क्लीयरकेस पर मेरे लगातार किराए के लिए उसे मिला। यदि वह मेरे तर्कों को स्वीकार करती है, तो मुझे अपने नियोक्ता को इस घृणा से छुटकारा दिलाने में मदद करने के लिए एक वास्तविक शॉट होगा।

अधिकारियों के साथ मेरा अनुभव बताता है कि वे) सब कुछ बी के लिए बहुत ही कठिन स्पष्टीकरण चाहते हैं) केवल उन तथ्यों में रुचि रखते हैं जिनमें डॉलर के आंकड़े शामिल हैं

एक डेवलपर के लिए मैं क्लीयरकेस (या उस मामले के लिए क्लीयरकेस पर कोई अन्य संस्करण नियंत्रण प्रणाली) के गुण की व्याख्या कर सकता हूं, लेकिन मैं तकनीकी पृष्ठभूमि के बिना एक तकनीकी कार्यकारी के लिए यह करने के लिए एक खाली ड्राइंग कर रहा हूं (वह एक है MBA और भूगोल में उसका स्नातक किया)।

मुझे लगता है कि मैं उससे जो भी तर्क करता हूं, वह या तो तकनीकी गिबरिश की तरह लग रहा है या मैं अपनी व्यक्तिगत वरीयताओं को प्रचारित कर रहा हूं।

मैं जो ढूंढने की कोशिश कर रहा हूं, वह ठोस तथ्य हैं जो दिखाते हैं कि डेवलपर्स Git या किसी भी आधुनिक स्रोत नियंत्रण प्रणाली के साथ अधिक प्रभावी ढंग से काम करते हैं।

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

"वास्तव में इस प्रक्रिया ने 20 वर्षों तक काम किया है, हमें इसे क्यों बदलना चाहिए?" तर्क।

Comments

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

— सूचित

अनुशंसित पढ़ने: मैं $ {कुछ} को $ {किसी} को कैसे समझाऊं?

— gnat

यह प्रदर्शित करें कि git का उपयोग करना आपको और (और टीमों को) आपके कर्तव्यों को करने में कितना प्रभावी बनाता है। इसके लिए मामले की सुनवाई किए बिना क्लीयरकेस को बदलने के लिए स्वयंसेवक न करें, लेकिन यह दिखाएं कि दिन के लाभ कहां हैं। ClearCase को ऑडिटिंग या प्रोजेक्ट वाइड इश्यू ट्रैकिंग के लिए आवश्यक किया जा सकता है, जिसमें Github मजबूत नहीं है।

— केविन

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

— 17 की 26

"मुख्य रूप से राय-आधारित के रूप में पकड़ पर" मैं इससे बहुत असहमत हूं। मेरे सवाल से "मैं जो खोजने की कोशिश कर रहा हूं वह ठोस तथ्य हैं जो डेवलपर्स को गिट के साथ अधिक प्रभावी ढंग से काम करते हैं।" उस बारे में क्या राय है?

— माइक

Answer 1

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

आप कहते हैं "इस प्रक्रिया ने 20 वर्षों तक काम किया है", लेकिन क्या यह वास्तव में है? "हमारी उत्पादन रिलीज प्रक्रिया एक दुःस्वप्न है" इसका मतलब क्या है, इसकी रूपरेखा तैयार करके शुरू करें। वर्तमान प्रक्रिया / उपकरण के साथ मुद्दों की एक सूची बनाएं जो कि ClearCase के अज्ञेय के रूप में संभव है।

फिर, प्रक्रिया / उपकरण "समाधान" की एक सूची बनाएं जो संभव के रूप में गिट के अज्ञेयवादी हैं (हालांकि गिट या किसी भी आधुनिक डीवीसीएस बिल को बिल्कुल फिट करना चाहेंगे)। यह बताते हुए कि Git ClearCase से बेहतर क्यों है इसका मतलब गैर-उपयोगकर्ताओं के लिए कुछ भी नहीं है।

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

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

सौभाग्य!

Comments

नोट: ClearCase 20 साल पुराना नहीं है।

— Jan Hudec

मुझे नहीं लगता कि आपको कुछ भी मिलेगा जो ClearCase के साथ नहीं किया जा सकता है। लेकिन कई चीजें क्लियरकेस के साथ बहुत अधिक जटिल होंगी और अधिक महत्वपूर्ण रूप से गुड़ के रूप में धीमी होंगी । सौभाग्य से तेजी से काम को पूरा करने के लिए तर्क सबसे प्रबंधकों है जाएगा स्वीकार करते हैं।

— Jan Hudec

@JanHudec 1992 में तर्कसंगत क्लीयरकेस की प्रारंभिक रिलीज़ हुई, जिससे यह 22 साल का हो गया।

— Private_meta

@ प्रेफरेंट_मेटा: हम्म, पता नहीं क्यों मुझे 1998 याद है।

— जान हुडेक

Answer 2

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

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

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

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

---

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

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

Comments

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

— Jan Hudec

@JanHudec मुझे क्लियरकेस याद है ... यह इतना धीमा नहीं था जहां मैंने काम किया था, लेकिन शायद इसके उन उत्पादों में से एक है, जहां रेपो सुरक्षा के कई परतों से घिरे एक दूर के कॉर्पोरेट डाटाकेंटर में एक सर्वर पर रखा जाता है। मुझे लगता है कि ओपी के पास एसवीएन या टीएफएस के साथ बेहतर मौका होगा।

— gbjbaanb

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

— Jan Hudec

+1 यह इंगित करने के लिए कि यह प्रौद्योगिकी समस्या के बजाय "लोगों" की समस्या है।

— kdgregory

मेरे पास सबसे बड़ा दुःस्वप्न था, सीवीएस की तरह, यह केवल व्यक्तिगत फ़ाइल स्तर पर संस्करणित था; अर्थ मर्ज की समस्याएं / आदि के परिणामस्वरूप CC का नवीनतम संस्करण टूटे हुए बिल्ड बन जाएगा और एक संपूर्ण कोडबेस को एक मनमाने तिथि / समय पर वापस करने में असमर्थता हो जाएगी। वर्चुअल नेटवर्क ड्राइव के बजाय स्थानीय दृश्य करने के विकल्प का उपयोग करने से IO विलंबता से बहुत कम दर्द होता है।

— डैन नीली

Answer 3

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

यदि आप इन उदाहरणों के लिए विशिष्ट समय-सीमा और तिथियां संलग्न कर सकते हैं तो बेहतर होगा। हो सकता है कि आप उस कार्य X को दिखाते हुए इसे भी बंद कर सकें, जो आप बहुत कुछ करते हैं और क्लीयरकेस में Y मिनट और Git में Z मिनट लेते हैं।

याद रखें कि समय पैसा है इसलिए यदि आप दिखा सकते हैं कि Git के साथ काम करना जल्दी है तो आप दिखा सकते हैं कि यह वित्तीय समझ भी बनाएगा।

Answer 4

यहाँ एक कोशिश है कि मैं कैसे कोशिश करूँगा।

एक डेवलपर के लिए यह बेवकूफी भरा लग सकता है, लेकिन प्रबंधन के लिए, तकनीकी परिवर्तन जोखिम भरे हैं।

"अगर जादू वाली चीज़ पहले से ही काम करती है, तो इसे तोड़ने का जोखिम क्यों उठाएं?"

इस प्रकार, आपको तालिका को चालू करना होगा। यह अधिक जोखिम भरा बनाओ नहीं git करने के लिए स्विच करने के लिए। हर कीमत पर, ऐसा मत करो कि यह एक नया खिलौना है।

मैं यह कहकर शुरू करूंगा कि git अब व्यापक रूप से उपयोग किया जाता है। संख्याओं का उपयोग करें, जैसे: http://ianskerrett.wordpress.com/2014/06/23/eclipse-community-survey-2014-results/

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

साथ ही मुख्यधारा की चीजों का पालन करने के लिए एक प्रबंधक को वास्तव में दोषी नहीं ठहराया जा सकता है, क्या वे? इसके विपरीत, यहाँ $ other_cv का उपयोग कौन करता है?

इस बात पर जोर दें कि बड़ी परियोजनाएं इसका उपयोग कैसे कर रही हैं, क्योंकि यह सरल, तेज, लचीला, शक्तिशाली है ... बड़ी परियोजनाओं को ढूंढें जिनके साथ बड़े नाम जुड़े हैं (GNU / Linux, Google, Microsoft ...) जो git का उपयोग करते हैं।

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

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

मैं यह भी कहूंगा कि यदि बैठक के बाद एक लिखित ई-मेल में उचित चीज़ को शामिल किया जाए (सही व्यक्तियों को शामिल करें)।

Comments

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

— gbjbaanb

@gbjbaanb अच्छी बात है, हालांकि मैंने यह नहीं देखा कि एक प्रबंधक के साथ चर्चा में कैसे तर्क दिया जाए जब एक और CVS पहले से ही उपयोग किया जाता है।

— न्हा

Answer 5

"वास्तव में इस प्रक्रिया ने 20 वर्षों तक काम किया है, हमें इसे क्यों बदलना चाहिए?" तर्क।

यह एक अमान्य तर्क है (घोड़े द्वारा तैयार की गई गाड़ियों ने "सदियों से काम किया है", लेकिन आप शायद इसके बजाय कार खरीदना चाहते हैं)।

मैंने svn बनाम मर्क्यूरियल के बारे में एक ही तर्क सुना है (मैं अपने विकास प्रणाली पर व्यापारिक उपयोग कर रहा था)।

यह समस्या काम करने के स्थान के बारे में नहीं है; इसे इस तरह से उद्धृत करने की कोशिश न करें, और यदि यह सवाल है कि आपको "हार" की आवश्यकता है, तो आपको यह इंगित करके शुरू करना चाहिए कि यह क्या काम करता है या नहीं - लेकिन यह बात नहीं है कि आपके पास क्या फायदे हैं , जब दोनों काम करते हैं (और git बेहतर काम क्यों करता है)।

Git का उपयोग करने के लिए अच्छे तर्क:

• फ़ाइल सेंट्रिक के बजाय git परिवर्तनशील केंद्रित है। इसका मतलब यह है कि परिवर्तन एक्सीस फाइल को ट्रैक करना आसान है (प्रोजेक्ट के पार ट्रैक करने योग्य एक्सीलेंस)।

• केंद्रीकृत के बजाय गिट वितरित किया जाता है; इसका मतलब है कि सामान की जांच नेटवर्क की गति से सीमित नहीं है - बहुत समय की बचत, फिर से। इसका मतलब यह भी है कि आपके ClearCase सर्वर के डाउन होने की स्थिति में आपके पास एक भी विफलता नहीं है।

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

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

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

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

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

Comments

गैर-तकनीकी प्रबंधन शायद इन तर्कों की परवाह नहीं करेंगे।

— jcm

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

— kdgregory

@kdgregory हर असंतुष्ट कर्मचारी के पास कोड की कई ज़िप फाइलें और व्यक्तिगत रिपॉजिटरी भी होती हैं क्योंकि 100% समय में काम करने के लिए ClearCase बहुत धीमा और बोझिल होता है। :-)

— जैस ब्राउनिंग

@kdory से निकला?"

— gbjbaanb

Answer 6

"वास्तव में इस प्रक्रिया ने 20 वर्षों तक काम किया है, हमें इसे क्यों बदलना चाहिए?" तर्क।

यह वास्तव में न्याय करना मुश्किल है कि दृश्य का गवाह न होकर एक अच्छा तर्क क्या होगा। लेकिन मैं आपके तर्कों को फ्रेम करने में आपकी मदद करने की कोशिश करूँगा ताकि उन्हें सुना जा सके।

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

• यह कौन सी नई क्षमताएं लाएगा? क्या ऐसा कुछ है जो हम वर्तमान में नहीं कर सकते हैं, कि हम क्या करना चाहते हैं, और यह नई चीज हमें अनुमति देगी? सकारात्मक नोट पर शुरू करें।

• रिलीज़ शेड्यूल पर क्या प्रभाव पड़ता है? तुरंत अगली रिलीज़ की दिशा में इस बदलाव को लागू करने की लागत क्या है? निम्नलिखित रिलीज के लिए लागत और लाभ क्या हैं?

• क्या इससे प्रक्रिया में बदलाव आएगा? रिलीज शेड्यूल से अलग, क्या इस बदलाव के लिए जरूरी होगा कि रिलीज प्रक्रिया में लोग अपने तरीके बदलें? क्या यह उनके लिए पारदर्शी होगा, या उन्हें अनुकूलन करने की आवश्यकता होगी? क्या आपको अन्य विभागों के साथ सहयोग करने की आवश्यकता होगी? लोग परिवर्तन के प्रतिरोधी हैं।

• क्या मौजूदा व्यवस्था से चिपके हुए आसन्न खतरे हैं? क्या वर्तमान प्रक्रिया में सॉफ़्टवेयर या हार्डवेयर निर्भरताएँ हैं जो जल्द ही समाप्त हो गई हैं या जीवन का अंत हो जाएगा? क्या यह उन व्यक्तियों से विशेष ज्ञान पर निर्भर करता है जो किराए पर लेने की लागत को बढ़ाते हैं? क्या इसमें एक संभावित सुरक्षा छेद है कि नई प्रणाली प्लग (बोनस अंक अगर यह छेद कानूनी कार्रवाई का कारण बन सकता है)? हैंड-वेव या 'हो सकता है ’या the शायद’ यह मत करो: भाव यह है कि इसने 20 वर्षों तक अच्छा काम किया है, इसलिए परिवर्तन के पैरोकार पर सबूत का बोझ है।

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

आप पा सकते हैं इस सवाल का जवाब करने के लिए संस्करण नियंत्रण को लागू करने के लिए कंपनी मैं काम मनाओ? उपयोगी।