स्रोत नियंत्रण के बिना कई लोगों के साथ एक एप्लिकेशन विकसित करने का सबसे प्रभावी / कुशल तरीका क्या है?


13

मेरी स्थिति का परिचय

मैं एक छोटी वेब डेवलपमेंट कंपनी के लिए काम करता हूं। हमारे पास मेरे सहित चार ASP.NET डेवलपर्स की एक टीम है। हमारी लगभग सभी परियोजनाएं (> 98%) एक-व्यक्ति परियोजनाएं हैं जिन्हें पूरा होने में लगभग 1-4 सप्ताह लगते हैं। हम स्रोत या संस्करण नियंत्रण का उपयोग नहीं करते हैं। हमारे पास एकमात्र चीज एक स्थानीय सर्वर पर एक साझा फ़ोल्डर है जिसमें सभी परियोजनाओं का नवीनतम स्रोत (== लाइव एप्लिकेशन का स्रोत) है।

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

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

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

मेरी समस्या / चिंता का स्पष्टीकरण

कुछ हफ्तों में हम अपने मानकों के लिए एक बड़ी परियोजना पर काम शुरू करने जा रहे हैं। इसे पूरा करने में शायद कुछ महीनों के लिए 2-3 डेवलपर्स लगेंगे। मैं प्रोजेक्ट लीड (प्रोजेक्ट मैनेजर और लीड डेवलपर) बनूंगा और मैं हर चीज के लिए जिम्मेदार रहूंगा। मेरे पास मेरी तुलना की तुलना में मेरी समस्याओं का हिस्सा है और मैं इस बड़ी परियोजना के साथ इस सड़क को नहीं लेना चाहता हूं जो मेरी जिम्मेदारी होगी।

चूंकि मुझे संदेह है कि हम कर पाएंगे

  • अपना स्वयं का Git सर्वर सेट करें,
  • Git और के साथ काम करने के लिए हर किसी को सिखाना
  • इस बड़ी परियोजना में सफलतापूर्वक गिट को रोजगार दें,

मुझे दिलचस्पी है अगर आप में से कोई भी स्रोत या संस्करण नियंत्रण का उपयोग किए बिना कई लोगों को एक ही परियोजना पर सहयोग करने की अनुमति देने के कुछ अच्छे तरीके जानता है।

अपडेट करें

मैं सभी को उनके जवाब और टिप्पणियों के लिए धन्यवाद देना चाहूंगा। यहाँ योजना है:

  1. यह सुनिश्चित करने के लिए डेवलपर्स के साथ बैठक करें कि सभी तकनीकी लोग स्रोत नियंत्रण को लागू करने के बारे में उसी तरह महसूस करते हैं। जब सभी इसके पीछे होंगे तो हम एक मजबूत बिंदु बनाएंगे।
  2. विचार को बॉस को प्रस्तुत करें और उसे बताएं कि हमें वास्तव में स्रोत नियंत्रण की आवश्यकता है
  3. इसे जल्द से जल्द लागू करें।

8
अपना स्वयं का गिट सर्वर क्यों सेट करें? यदि यह एक बड़ी परियोजना है, तो अपने आप को एक GitHub खाता प्राप्त करें। लगभग 5 मिनट लगते हैं :) हमारी पूरी कंपनी हाल ही में SVN से Git और GitHub में बिना किसी नए इंफ्रास्ट्रक्चर के चली गई।
फ्रेसकोमा

34
IMO, स्रोत नियंत्रण के बिना एक बड़ा (या midsize, या यहां तक ​​कि छोटे-ईश) प्रोजेक्ट करना आज की दुनिया में पागलपन है। मैं वास्तव में इसे अव्यवसायिक कहने के लिए इतनी दूर जाऊँगा (यदि आप अपना काम ठीक से करने के लिए किसी व्यक्ति द्वारा भुगतान कर रहे हैं।)
मैके

10
मुझे चिकोटी मिलती है अगर यह सिर्फ एक फ़ाइल में एक लाइन है और मेरे पास संशोधन नियंत्रण नहीं है।
आहारबुद्ध

4
संस्करण नियंत्रण से संबंधित अन्य सभी उत्तरों और टिप्पणियों के अलावा, आपके बॉस का "कुछ गलत नहीं हुआ है, लेकिन अभी तक कोई समस्या नहीं होनी चाहिए" का परिप्रेक्ष्य व्यापार में एक भयानक रवैया है।
मिशेल टिली

4
अपने आप से पूछने के साथ-साथ "स्रोत नियंत्रण पाने और चलाने के लिए कुछ सप्ताह का समय पर्याप्त है?", आपको शायद खुद से पूछना चाहिए "क्या मेरे लिए एक पेशेवर वेब विकास स्टूडियो के साथ एक और नौकरी खोजने के लिए कुछ सप्ताह का समय पर्याप्त है?"
कार्सन 63000

जवाबों:


53

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

इससे समय बर्बाद नहीं होगा।

बार जब आप होगा खो देते हैं जब किसी को अधिलेखित कर देता है या हटाए गए कुछ कोड आप और अधिक खर्च होंगे।

यदि आपके पास संस्करण नियंत्रण नहीं है, तो आप अपनी परियोजना का समर्थन करने और हर किसी के लिए कौन सा संस्करण है और कौन सा संस्करण सर्वर पर है आदि के बारे में चिंता करने के लिए एक विषम राशि खर्च करेगा।

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

फिर संस्करण नियंत्रण प्राप्त करने की लागत की तुलना करें - शून्य (यदि आप खुले स्रोत जाते हैं) और इसे स्थापित करना - 3 आदमी दिन।

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


7
+1 आपके शीर्षक प्रश्न का उत्तर स्रोत नियंत्रण का उपयोग शुरू करना है । प्रोग्रामर के चारों ओर एक नज़र डालें। एसई और स्टैक ओवरफ्लो; सबूत दृढ़ता से इस तर्क का समर्थन करते हैं कि यह आपके परिदृश्य में आपके द्वारा किया जा सकने वाला सबसे अच्छा काम है।
मिशेल टिली

2
@ क्रिस्तोफ़ - उसे यहाँ और एसओ के कुछ सवालों पर इंगित करें।
ChrisF

22
@ क्रिस्तोफ दावा: यदि मैं आप होता, तो मैं अपनी नौकरी छोड़ देता। गंभीरता से। कोई SCM -> बाय। यह एक गुफा की दीवार पर एक बड़ी इमारत की योजना बना रहा है, जैसे कि उंगली पर, अंधेरे में, शातिर नरभक्षी जनजातियों से घिरे ...
१k:५१ पर १k

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

10
संस्करण नियंत्रण और एक बग ट्रैकर सॉफ्टवेयर विकास है जो पैंट पहनने के बराबर है।
टिम विलिसक्रॉफ्ट

27

यदि आप स्रोत को किसी फ़ोल्डर में साझा करते हैं, तो आप रेपो को भी साझा कर सकते हैं। बॉस को इसके बारे में पता नहीं होगा सिवाय इसके कि वहाँ एक .गित फ़ोल्डर है।

आपको अपना काम ठीक से करने की अनुमति कभी नहीं मांगनी चाहिए - सेठ गोडिन।


3
+1 यदि केवल प्रशस्ति पत्र के लिए। मुझे अपना काम करने के लिए भुगतान किया जाता है, इसे ठीक से करना उस सौदे का हिस्सा है जिस पर हम दोनों ने सहमति व्यक्त की थी जब हमने अनुबंध पर हस्ताक्षर किए थे।
Matthieu M.

4
स्रोत नियंत्रण का उपयोग नहीं करने का कोई अच्छा कारण नहीं है, और इसका उपयोग करने के लिए हर कारण ।
फ्रैंक शीयर

2
आप अपने सहयोगियों को साकार किए बिना भी गिट का उपयोग कर सकते हैं।
आयुध

1
@ एलिसन: सच। यहां तक ​​कि अगर मैं टीम में दूसरों में से एक "सिर्फ" था, तो मैं मर्ज-नरक से बचने के लिए अपने कंप्यूटर पर गिट का उपयोग करता हूं और एक स्थानीय रोलबैक विकल्प होता है।
मैके

2
@ मैके हां, और जल्दी या बाद में किसी ने नोटिस किया होगा कि आपके पास मर्ज के साथ इतना बुरा समय नहीं है, और वे इसे भी उपयोग करना चाहेंगे :)
आर्मंड

7

सेटअप स्रोत नियंत्रण, इसका उपयोग करना सीखें और अपने बॉस को न बताएं। मैं सामान्य तौर पर प्रबंधन की अवज्ञा करने की वकालत नहीं करता, लेकिन इस मामले में आपके बॉस को बेवकूफ बनाया जा रहा है। यदि आप वास्तव में सोचते हैं कि git को सीखने में बहुत लंबा समय लगेगा, तो svn जैसे अधिक सरलीकृत संस्करण नियंत्रण प्रणाली के साथ शुरू करें - यह उन सभी शांत चीजों को नहीं करता है जो git करता है, लेकिन इसकी एक बुनियादी समझ हासिल करना भी आसान है।

जब तक आप इसके बीच में न हों और कुछ को लागू करने से पहले गंभीर रूप से परेशानी में न रहें। बस करो, और काम पूरा करो।

जोड़ने के लिए संपादित: आपका प्रश्न जो वास्तव में पूछ रहा है वह है 'मैं स्रोत नियंत्रण प्रणाली का उपयोग किए बिना स्रोत नियंत्रण कैसे करूं'। आपने आवश्यकता को पहचान लिया है, और मुझे लगता है कि यहां हर कोई वास्तव में आपको एक ही बात कह रहा है: स्रोत नियंत्रण प्रणाली के बिना स्रोत नियंत्रण करने का कोई समझदार तरीका नहीं है।


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

5

मेरे पास केवल जाने के लिए आपका सारांश है, लेकिन इससे ऐसा लगता है कि आपका बॉस एक समय और धन तर्क कर रहा है, और आप एक तकनीकी श्रेष्ठता तर्क बना रहे हैं। आपको समय और धन तर्क करने की आवश्यकता है। चीजों को करने के तरीके को जानें और कुछ समय के लिए इसे बचाए रख सकते हैं, फिर अपने बॉस को लॉग इन करें जैसे कि "3/28/2011 जैसी प्रविष्टियों के साथ प्रस्तुत करें जो एक संकलित निर्माण के लिए वापस पाने के लिए 30 मिनट तक इंतजार करना पड़ा इसलिए हम एक मर्ज कर सकते हैं, उनके आखिरी कमिट के खिलाफ git मर्ज कमांड लगभग 5 सेकंड रहा होगा "सबसे नीचे एक अच्छा कुल।

यदि किसी सर्वर को प्रशिक्षण देना और स्थापित करना व्यावसायिक बाधाएँ हैं, तो एक git वर्कफ़्लो सेट करने के लिए अनंत तरीके हैं, जिसमें केवल एक टीम सदस्य वास्तव में git का उपयोग कर रहे हैं, जिसमें "सर्वर" के लिए साझा फ़ोल्डर हैं।

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

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


3

यह पागल है। यदि आप अपने दम पर काम करते हैं तो भी आपको वीसीएस का उपयोग करना चाहिए। किसी कंपनी में VCS का उपयोग नहीं करना चाहिए। बस कर दो। अभी! वास्तव में ... आपको शुरुआत से ही उन्नत सामान की आवश्यकता नहीं है। GitHub और GitLab उपयोग करने के लिए बहुत सीधे हैं, लेकिन मुझे यकीन है कि आप कुछ और विंडोज-संगत होस्टिंग सेवाएं पा सकते हैं यदि आपका बॉस जोर देता है (भले ही यह सेटअप और विंडोज पर गिट का उपयोग करने के लिए कठिन नहीं है)।


1
आपके उत्तर के पहले तीन शब्द वास्तव में पूर्ण उत्तर होने चाहिए।
gnasher729

2

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

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

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

अब, मेरे दृष्टिकोण और मेरे अपने अनुभव से, मेरे पास आपके पास मौजूद समस्या के तीन समाधान हैं:

  • एक संस्करण नियंत्रण स्थापित करें जिसका उपयोग करना आसान है । मैं SVN सर्वर के रूप में CollabNetSubversion को स्थापित करता था, यह काफी तेज़ और सेटअप करने में आसान है, अगर आपको सुरक्षा पर ध्यान नहीं है । यदि आप विज़ुअल स्टूडियो का उपयोग करते हैं, तो डेवलपर्स को विजुअल स्टूडियो के भीतर से सोर्स कोड को आसानी से अपडेट / कमिट करने में सक्षम करने के लिए, AnkhSvn स्थापित किया जा सकता है।

  • अपने बॉस को समझाएं कि जोएल परीक्षण एक ऐसे व्यक्ति द्वारा लिखा गया है जो अपनी नौकरी को अच्छी तरह से जानता है, और अगर जोएल परीक्षण एक संस्करण नियंत्रण होने का सुझाव देता है, तो इसके पीछे एक अच्छा कारण है। आखिरकार, वह यह भी तय कर सकता है कि कोड लिखने के लिए डेवलपर्स को आईडीई / सिंटैक्स हाइलाइटिंग टूल की आवश्यकता नहीं है। विंडोज नोटपैड सिर्फ ठीक है, है ना? और यह भी, क्यों इंटरनेट का उपयोग? हम सभी की जरूरत है एक बहुत, बहुत पुराने पीसी Windows 3.1 चल रहा है।

  • इस कंपनी से बाहर निकलें , क्योंकि मुझे कुछ संदेह है कि संस्करण नियंत्रण के अलावा सब कुछ सही और पेशेवर है।


यह निश्चित रूप से असंभव नहीं है। आपको क्या लगता है कि स्रोत नियंत्रण सामान्य स्थान से पहले सॉफ़्टवेयर विकसित किया गया था?
ग्रैंडमास्टरबी

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

2

किसी भी बड़ी परियोजना पर VCS का उपयोग नहीं करना क्योंकि आप एक सेट करने के समय का निवेश नहीं करना चाहते हैं, एक लंबी यात्रा नंगे पांव लेने की तरह है, क्योंकि आप जूते डालने का समय निवेश नहीं करना चाहते हैं।

कोई भी वीसीएस परिमाण के आदेशों से बेहतर है कि उनमें से कोई भी न हो।

VCS स्थापित करने का एक आसान आसान तरीका यह है कि TortoiseSVN प्राप्त करें (क्योंकि आप C # का उपयोग करते हुए प्रतीत होते हैं, मुझे लगता है कि आप Windows पर हैं)। आप अपने द्वारा चुने गए स्थानीय फ़ोल्डर में एक रिपॉजिटरी बनाते हैं (इसे नेविगेट करें, राइट क्लिक करें> TortoiseSVN> रिपोजिटरी यहां बनाएं)। इस फ़ोल्डर को अपने नेटवर्क में साझा करें (यह अधिमानतः एक मशीन पर होना चाहिए, जो हमेशा उपलब्ध है) और url के साथ चेकआउट करें file://computername/path/to/that/repository। बहिष्कृत डाउनलोड करें, इसे सेट होने में एक मिनट से अधिक नहीं लगता है।


1

आपका उत्तर आपके बॉस के लिए एक सरल लिंक है ... इस पृष्ठ को उसे / उसे मेल करें और पेशेवरों से "छोड़ें" शब्दों की संख्या को उजागर करें।

जबकि "गूंगा" शब्द संभवतः कई बार दिखाई देता है, मुझे यकीन है कि आपका बॉस नहीं है। यह उसके लिए पूर्ण मूल्य नहीं है। उससे यह पूछने के लिए कि व्यवसाय से संबंधित प्रश्न क्या है उसी प्रतिक्रिया में परिणाम होगा (शायद एक लेखाकार का सुझाव है "बल्कि इस इमारत का बीमा न करें कि आप अधिकतम पर बंधे हैं यह आपको कुछ डॉलर बचाएगा!")।


1

स्रोत नियंत्रण केवल आवश्यक है जहां एक परियोजना पर डेवलपर्स की संख्या> 0 है। मैं यह सोचना शुरू कर रहा हूं कि कोई निरंतर एकीकरण के बारे में एक ही कह सकता है ...

(-:

जैसा कि आप ASP.NET डेवलपर्स हैं, मैं आपको सुझाव दूंगा कि आप सबवर्सन, टीएफएस या मर्क्यूरियल में से एक के साथ जाना चाहते हैं - लेकिन ईमानदारी से कहें तो यह कोई मायने नहीं रखता है कि जब तक आप किसी चीज के साथ चलते हैं। संस्करण नियंत्रण के बिना विकसित करने का कोई मतलब नहीं है - यहां तक ​​कि तब भी जब उपकरण अधिक या कम मुक्त तैनात करने के लिए और उन्हें उपयोग करने के लिए ओवरहेड न्यूनतम है।

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

अगर मैं खरोंच से शुरू कर रहा था तो यह लगभग निश्चित रूप से मर्क्यूरियल के साथ होगा।

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

अपने शुरुआती बिंदु पर वापस आने के लिए:

मैं प्रोजेक्ट लीड (प्रोजेक्ट मैनेजर और लीड डेवलपर) बनूंगा और मैं हर चीज के लिए जिम्मेदार रहूंगा

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


0

जैसा कि ऊपर उल्लेख किया गया है, आप पहले से ही साझा किए गए फ़ोल्डर पर एक रिपॉजिटरी डाल सकते हैं। यदि आप किसी वितरित स्रोत नियंत्रण प्रणाली का उपयोग करते हैं, तो Git, Mercurial या बाज़ार जैसे सर्वर को कॉन्फ़िगर करने में आपको समय बिताने की आवश्यकता नहीं है।

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

यदि भविष्य में आपका बॉस आपको टीएफएस पर स्विच करने के लिए कहेगा, तो यह अभी भी किसी भी संस्करण नियंत्रण से बेहतर है।


0

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

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


0

मान लें कि आप अपनी टीम को संस्करण नियंत्रण अपनाने के लिए मना नहीं कर सकते हैं या आपके बॉस को उप-केंद्र की हवा मिलती है और जोर देते हैं कि टीम बंद हो जाती है, तो कम-से-इष्टतम दृष्टिकोण है जिसे आप ले सकते हैं।

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

DVCS का उपयोग यह सुनिश्चित करता है कि सर्वर की आवश्यकता नहीं है और कोई जटिल सेटअप प्रक्रिया नहीं है। मर्क्यूरियल को स्थापित करना और मूल चीजों के साथ उठना और चलना लगभग 30 मिनट से अधिक नहीं होना चाहिए।

यह एक आदर्श समाधान नहीं है, लेकिन यह कुछ भी नहीं से बेहतर है।


0

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

तो अपने बॉस को पूरी तरह से आश्वस्त करना कि उस संस्करण नियंत्रण पर आपके तर्क को "बेहतर प्रक्रिया" कहा जाएगा, काफी व्यर्थ है। हालाँकि, आपको पहले स्थान पर संस्करण या स्रोत नियंत्रण का उपयोग करने की आवश्यकता पर एक और अधिक महत्वपूर्ण तर्क है, जिसे आसानी से पैसे की गणना की जा सकती है। और यह है:

जोखिम

मुद्दा यह नहीं है कि स्रोत नियंत्रण का उपयोग करने से आपकी विकास प्रक्रिया बेहतर होती है। यदि आपके पास स्रोत नियंत्रण नहीं है तो यह एक समस्या है। उसके खतरे क्या हैं?

यह कहें कि कोई गलती से कोड या पूरी फ़ाइल में कोई फ़ंक्शन हटा देता है? मरम्मत की लागत कितनी होगी? उम्मीद है कि किसी ने इसे कवर किया है, इसलिए फिक्स सीमांत है।

लेकिन अगर किसी निकाय के पास खोई हुई फ़ाइल का बैकअप न हो तो क्या होगा? कितना आदमी घंटे तय करने के लिए खर्च होगा? यह शायद दिन लगेंगे, और यह आसानी से औसत आदमी घंटे में गणना की जाती है। क्या यह कंपनी के लिए बहुत ज्यादा होगा? यह किसी भी तरह तेजी से remedied किया जा सकता है?

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

जब तक आप व्यावसायिक कारण दिखा सकते हैं कि स्रोत नियंत्रण करना क्यों उपयोगी है, और जोखिम प्रबंधन एक ऐसा विशाल कारक होगा, जो अधिकांश मालिकों को समझाएगा।


0

डिस्ट्रीब्यूटेड वर्जन कंट्रोल सिस्टम का उपयोग करें जैसे git और रेफरेंस रिपॉजिटरी को स्टोर करने के लिए अपने शेयर्ड फोल्डर मशीन का उपयोग करें। यहाँ पर क्यों:

प्रत्येक क्लोन एक बैकअप है

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

आम संदर्भ

एक मुख्य शाखा के साथ मुख्य भंडार होने से अंतिम शब्द वाले संस्करण को जानने की अनुमति मिलती है। यह "आपने फ्रेंक के संस्करण के खिलाफ अपने परिवर्तनों का परीक्षण किया है, लेकिन क्या आपके पास जॉन के भी हैं? और उन्हें कैसे मिला दिया?"

अधिक आराम से वितरित करें

ग्राहक आज एक अल्फा संस्करण चाहता है? ठीक है, आप परीक्षण कर सकते हैं कि क्या मास्टर पर्याप्त स्थिर है और जहाज। यदि यह नहीं है और आपके पास इसे ठीक करने का समय नहीं है, तो बस समय पर वापस जाएं और एक पुराना लेकिन अधिक स्थिर संस्करण प्राप्त करें। आप ऐसा नहीं कर सकते यदि आपके पास केवल नवीनतम संस्करण है।

समय पर वापस जाएं और अपनी गलतियों को ठीक करें

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

अधिक आसानी से बग का पता लगाएं

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

प्रत्येक डेवलपर अपने काम के लिए जिम्मेदार है

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

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

अंतर यह है कि मर्ज उस व्यक्ति द्वारा किया जाता है जिसने परिवर्तन किए, जो उस कोड को सबसे अच्छी तरह से जानता है क्योंकि उसने इसे लिखा है।

उस कोड को किसने लिखा था?

यहाँ वह बग है, लेकिन कोड की उस विशेष पंक्ति को किसने लिखा है? यह याद रखना मुश्किल है, खासकर अगर परियोजना sevral महीने तक चलती है। git blameआपको बताया होगा कि उस लाइन को किसने और कब लिखा था, इसलिए आप सही व्यक्ति से पूछ सकते हैं, और कोई भी "मुझे यह लिखना याद नहीं है"।

प्रोजेक्ट बड़ा हो रहा है

ग्राहक अधिक सुविधाएँ चाहता है और आप एक टीम बहुत छोटे हैं, आपको एक और डेवलपर की आवश्यकता होगी। VSC के बिना आप बढ़ी हुई मर्ज जटिलता का प्रबंधन कैसे करते हैं?

तत्काल परिवर्तन

ग्राहक ने कॉल किया और उत्पादन के लिए एक महत्वपूर्ण बग फिक्स के लिए कहा, लेकिन आप वर्तमान में एक नई सुविधा पर काम कर रहे थे। बस git stashअपने परिवर्तनों को एक तरफ रखने के लिए, या उन्हें एक नई शाखा में लागू करें और परिवर्तनों को धक्का दें और आप अपने लंबित काम को खोने के डर के बिना, तत्काल सुधार पर काम शुरू करने के लिए तैयार हैं।

10 मिनट पहले काम किया था

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

VCS के साथ, आप अभी कुछ ऐसा ही करते हैं git diff, और जिस कोड पर आप आधारित हैं, उसके सही संस्करण की तुलना में आपका परिवर्तन हुआ है।

मुझे अपने डिबग लॉग को रखना होगा

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

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

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

मिट्टी का बड़ा गोला

वीसीएस के बिना, लोग अपने पक्ष में काम करते हैं, और आपको कभी-कभी असंबंधित परिवर्तनों का एक गुच्छा देते हैं। जब जाँच करने के लिए बहुत अधिक कोड होता है, तो बग ढूंढना कठिन होता है।

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

यदि मैं आपको 100 आलू 1 से 1 देता हूं, और एक सड़ा हुआ है, तो आप तुरंत इसे पा लेंगे। अब अगर मैं आपके सामने 100 आलू डंप करूं और आपको सड़े हुए को खोजने के लिए कहूं, तो यह एक ही काम नहीं है।

खरोज

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

आप प्रोजेक्ट लीडर हैं

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


-6

ड्रॉपबॉक्स का उपयोग करें, इसमें स्वचालित संस्करण इतिहास है। आप कई उपयोगकर्ताओं के बीच ड्रॉपबॉक्स-फ़ोल्डर साझा कर सकते हैं।

संपादित करें

आप TortoiseSVN- क्लाइंट को भी डाउनलोड कर सकते हैं, और नेटवर्क ड्राइव पर "स्थानीय रिपॉजिटरी" बना सकते हैं। फिर लोग नेटवर्क फ़ोल्डर स्थान द्वारा स्रोत कोड की जांच कर सकते हैं।


1
लेकिन विलय ?

वैसे आप सभी स्रोत कोड की स्थानीय प्रति रख सकते हैं, और एक बार में उन्हें एक बार मर्ज करने के साथ ड्रॉपबॉक्स फ़ोल्डर के साथ मर्ज कर सकते हैं।
आरेप

क्या आपने वास्तव में एक वास्तविक परियोजना के लिए यह कोशिश की है? मुझे भंगुर लगता है ...

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

2
मुझे लगता है कि आपको दूसरों की सिफारिश करने से पहले इसे आज़माना चाहिए!
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.