केवल उत्पादन कोड के लिए तोड़फोड़ / स्रोत नियंत्रण?


21

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

क्या यह एक सामान्य अभ्यास है? यह मुझे लगता है जैसे हम स्रोत नियंत्रण के बहुत सारे लाभ खो देते हैं, जिनमें शामिल हैं:

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

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


2
वह इस विचार को किस तरह से प्रेरित करता है? यदि उसने आपको कोई कारण नहीं दिया है, तो क्या आपने पूछा है?
Anto

8
"जो" ब्रांचिंग को समझता है? कुछ कोमल सवालों का पता लगाना दिलचस्प हो सकता है।
जेम्स

2
@ एंटो - मुझे लगता है कि यह "इसका उत्पादन नहीं है और इसे एक उत्पादन भंडार का हिस्सा नहीं होना चाहिए"।
श्री जेफरसन

1
@ नाम - मुझे नहीं लगता कि वह एसवीएन को सामान्य रूप से अच्छी तरह से जानता है, इसलिए नहीं, मुझे नहीं लगता कि वह ब्रांचिंग के बारे में जानता है। लेकिन नीचे दी गई प्रतिक्रियाओं को, मुझे लगता है कि इसका समाधान है।
श्री जेफरसन

4
इस सवाल को पढ़ें और मेरे सिर में एक छोटी सी आवाज़ में चिल्लाया "NOOOOOOOOOOOOOOOooooooooooooo"।
केविन डी

जवाबों:


1

यदि परियोजनाएँ अपने अनुमानित समय-सीमा के भीतर पूरी हो जाती हैं, तो क्या यह मान लेना सुरक्षित है कि ग्राहक खुश ग्राहक हैं? :)

ऐसा लगता है कि कंपनी नए प्रकार के प्रोजेक्ट्स को लेना शुरू कर रही है और कुछ बढ़ते हुए दर्द या कुछ "शिफ्टिंग पेन" से गुजर रही है। यहाँ जाने के लिए बहुत कुछ ... मेरे साथ सहन करो!

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

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

आदरणीय बनो और तुम अंत में सुना जा सकता है।

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


42

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


6
कृपया ब्रांचिंग और टैगिंग समस्या पर जोर दें। यह - मुझे लगता है - महत्वपूर्ण विशेषता जो लोगों को केवल एसवीएन में उत्पादन पर जोर देने का कारण बनती है।
एस.लूट।

3
वोडका के खिलाफ अपने पूर्वाग्रह के साथ एक उत्कृष्ट बिंदु।
कोवर

बहुत ज्यादा? मैं कहेंगे वह है मृत गलत। इसके बारे में कोई सवाल नहीं।
स्टीवन एवर्स

2
@ कोवर: मैं अपने वोदका को वरमाउथ के साथ प्रदूषित नहीं करता हूँ :)
व्याट बार्नेट

22

"वरिष्ठ" वास्तव में बहुत अकुशल है। कोई भी कोड जो संकलित किया जा सकता है (और यदि आपके पास है तो परीक्षण पास करता है) स्रोत नियंत्रण के लिए प्रतिबद्ध होना चाहिए। स्रोत नियंत्रण कोड साझा करने और वेतन वृद्धि के लिए केंद्रीय संपत्ति है।

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

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


12
लेकिन वह टीम के सदस्य के रूप में काम करने में कुशल नहीं हैं।
लादिस्लाव मृंका

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

2
@SnOrfus - जबकि मैं SCM की उपयोगिता के बारे में कुछ हद तक सहमत हूं, इस सवाल के साथ मेरा उद्देश्य जो और / या उसके कौशल को एक डेवलपर के रूप में मारना नहीं है। फिर, वह महान उत्पाद निकला, वह जानकार है, और उसने पिछले 10 वर्षों से SCM के बिना ठीक किया है। इस प्रश्न के साथ मेरा उद्देश्य यह देखना था कि क्या उनका दृष्टिकोण एक व्यापक रूप से आयोजित किया गया था जिसका मैंने सामना नहीं किया था; मैं, आखिरकार, स्कूल से बाहर हूं और इस उद्योग में अपेक्षाकृत अनुभवहीन हूं। किसी भी मामले में, मेरा मानना ​​है कि वह ईमानदारी से वर्कफ़्लो की गुणवत्ता और विश्वसनीयता सुनिश्चित करना चाहता है।
मि। जेफरसन

3
@ टॉम: मैं आपको अभी बता सकता हूं कि आप अपने काम की गुणवत्ता के बारे में जो भी सोचते हैं, वह एक कुशल डेवलपर नहीं है यदि वह नहीं जानता कि स्रोत नियंत्रण का ठीक से उपयोग कैसे किया जाए। कोई अन्य विकल्प नहीं है, इसके अलावा शायद वह एक तहखाने में अकेले काम कर रहा है। यहां तक ​​कि अपनी खुद की परियोजनाओं में जहां मैं एकमात्र डेवलपर हूं, मैं अपने पूर्ण सीमा तक स्रोत नियंत्रण का उपयोग करता हूं।
जॉर्डन

5
@SnOrfus: मैं बिना आईडीई के बहुत खुशी से काम कर सकता हूं। मैं संस्करण नियंत्रण के बिना काम नहीं करूंगा। यदि टीम इसका उपयोग नहीं कर रही है, तो मैं इसे अपने दम पर चलाऊंगा।
केविन क्लाइन

12

इस सवाल को एक तरफ रखते हुए कि जो सही है या गलत (वह गलत है, वैसे), यह मुझे लगता है कि यदि आप एक वितरित संस्करण नियंत्रण प्रणाली जैसे Git या Mercurial का उपयोग करते हैं तो एक समझौता किया जा सकता है ।

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


1
मैंने इस बारे में सोचा है और थोड़ी-बहुत खोजबीन की है (और अच्छी बातें सुनी हैं), लेकिन मेरी झिझक इस बात में है कि हमने पहले ही VisualSVN सर्वर खरीद लिया और स्थापित कर लिया है, और हम में से किसी को भी Git या Mercurial का कोई अनुभव नहीं है । अगर मैं हर किसी को और अधिक सॉफ्टवेयर खरीदने और / या मौजूदा निवेश को फेंकने की जरूरत है, तो यह एक कठिन लड़ाई से भी अधिक होगा। लेकिन अच्छी बात है।
श्री जेफरसन

3
@ टोम: यदि इसे पिछले छोर पर तोड़फोड़ करनी है, तो आप Git या Mercurial की Subversion इंटरऑपरेबिलिटी लेयर का उपयोग उस सामान के लिए कर सकते हैं जो तैयार नहीं है, और तैयार होने पर काम को तोड़फोड़ में धकेल दें।
केन ब्लूम

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

1
@ टोम हैमिंग: एक व्यक्तिगत डेवलपर के रूप में, आप नियमित रूप git pushसे कुछ अन्य मशीन (बैकअप के रूप में) में अपने बदलाव चुन सकते हैं । यह "मास्टर" भंडार होना जरूरी नहीं है।
ग्रेग हेविगिल

1
@ टोम हैमिंग: एसवीएन के साथ चिपका क्योंकि आपने एसवीएन सर्वर खरीदा और स्थापित किया है, यह वास्तव में एक धँसा लागत गिरावट है। Git और Mercurial दोनों मुफ्त हैं, और VisualSVN की लागत पहले ही भुगतान की जा चुकी है, इसलिए अपने विकल्पों को देखें क्योंकि आगे जाने पर प्रत्येक की (शून्य) प्रारंभिक सेटअप लागत समान है।
Cercerilla

7

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


5

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

कभी "क्यों इस कोड लाइन को जोड़ा गया था" माना जाता है? इसे लागू करने वाली कमेटी का पता लगाएँ, और उसकी टिप्पणी देखें। यदि आप केवल उत्पादन में जाते हैं, तो टिप्पणियां आपके लिए उपयोगी होने के लिए पर्याप्त नहीं होंगी।

मैं यह भी सुझाव दूंगा कि आप SVN से अधिक शक्तिशाली उपकरण का उपयोग करें। आप जोएल स्पोल्स्की द्वारा http://hginit.com/ पर संभावनाओं पर एक अच्छा परिचय देख सकते हैं ।

वह भाड़े का उपयोग करता है, और इन दिनों कई दावेदार हैं। Git को बहुत शक्तिशाली माना जाता है, और https://github.com/ के पास कुछ बहुत, बहुत उपयोगी टूलिंग हैं और मुफ्त स्टार्टर खाते प्रदान करता है ताकि आप इसे असली के लिए आज़मा सकें।


3

जो SVN के बारे में जानने की तरह नहीं दिखता है, शाखाओं, टैग और ट्रंक के बारे में जानने की कोशिश करें ... टैग जो चाहता है उसके अनुरूप है। एसवीएन सर्वोत्तम प्रथाओं पर कुछ पढ़ने से चोट नहीं पहुंचेगी


2

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


एसवीएन भी ऐसा कर सकता है।
फिल लेलो

2

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

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

कुछ ही समय में मुझे उम्मीद है कि जो आप कैसे काम करेंगे, उस पर गौर करेंगे और वही करना शुरू करेंगे। एक या दो साल में, SVN सर्वर Git repo बन जाएगा।


svn सर्वर में डॉलर का निवेश एक git रेपो सर्वर में डॉलर के निवेश से अधिक नहीं होगा ...
TZHX

2

आप उपरोक्त तर्कों के साथ जो को समझाने की कोशिश कर सकते हैं। यदि यह आपके स्वयं के विकास कार्यों के लिए स्थानीय रूप से SVN का उपयोग करने में सफल नहीं होता है और आशा है कि इसे जो द्वारा उठाया जाएगा। यदि आप उन्हें तर्कों के साथ मना नहीं सकते हैं तो वह काम करें जो आपके कायल हैं और उन्हें यह दिखाता है कि यह काम करता है। वितरित दृष्टिकोण की तरह लेकिन मौजूदा टूलींग के साथ।


2

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


1

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


0

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

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


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

बायनेरिज़ को शामिल किया गया था क्योंकि किसी रिलीज़ के स्रोतों को मज़बूती से पुनर्प्राप्त करना असंभव था। इसलिए बायनेरिज़ को स्टोर किया जाता था, जब उन्हें एक सर्वर को एक पुराने रिलीज पर पुनर्स्थापित करने की आवश्यकता होती थी ... पहले से किए गए बुरे निर्णयों पर आधारित समझौता।
jwenting
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.