क्या ऐसी गंभीर कंपनियां हैं जो संस्करण-नियंत्रण और निरंतर एकीकरण का उपयोग नहीं करते हैं? क्यों?

Question

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

क्या कोई किसी वास्तविक कंपनी (3 प्रोग्रामर से बड़ा) के बारे में जानता है , जो सॉफ्टवेयर व्यवसाय में है और इन उपकरणों का उपयोग नहीं करता है? यदि ऐसी कोई कंपनी मौजूद है, तो क्या उनके ऐसा करने का कोई अच्छा कारण है?

Comments

उन pesky सॉफ्टवेयर अभिनेताओं।

— मोनिका

क्या सॉफ्टवेयर एक्टर्स सॉफ्टवेयर डेवलपर्स से अलग हैं?

— आदित्य पी।

"मैं एक सॉफ्टवेयर नहीं हूँ, लेकिन मैं टीवी पर एक खेलता हूँ !!" -सोशल एक्टर्स।

— FrustratedWithFormsDesigner 13

वहाँ Jayne Seymour है, वह एक गंभीर सॉफ्टवेयर अभिनेत्री है .... या कम से कम उसने लाइव एंड लेट डाई :) में सोलिटेयर की भूमिका निभाई

— केविन डी

जहां मैंने दस साल पहले काम किया था, हमने सभी समर्थित प्रणालियों पर रात का निर्माण किया था। उन्हें कभी भी संकलन के लिए कहीं पास नहीं मिला। कभी।

— डेविड थॉर्नले 14

Answer 1

मुझे यकीन नहीं है कि आप उन्हें एक गंभीर कार्य कहेंगे, लेकिन माइस्पेस इस मोर्चे पर बहुत गरीब हैं: http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill- देखें myspace.html ।

Comments

+1 वे कम से कम प्रमुख लीग में हैं। मुझे नहीं लगता था कि यह संभव था। बिना संस्करण नियंत्रण वाली इतनी बड़ी कंपनी। जाओ पता लगाओ।

— दारमाकर

पागल। मुझे विश्वास नहीं होता, लेकिन यह ब्लॉग और लेख के संदर्भ सभी विश्वसनीय हैं।

— स्टीव

इसे कुत्ते पर दोष दें।

— जेएफओ

एक गैरेज में एक बैंड शुरू करने वाले किशोरों के लिए एक वेबसाइट उनके गैरेज से काम करने वाले कोडर की शैली में लिखी गई है। आंकड़े।

— मात्रा_देव

Answer 2

आपको यह देखकर आश्चर्य होगा कि वास्तविकता सामान्य ज्ञान के लिए क्या कर सकती है ;-)

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

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

Comments

क्या यह संभव है कि एक औसत सॉफ़्टवेयर डेवलपर ने संस्करण नियंत्रण सॉफ़्टवेयर के बारे में नहीं सुना हो? ये कंपनियां लोगों को कहां से नौकरी देती हैं? चंद्रमा का अंधेरा पक्ष?

— दारमाकर

@daramarak: कई (यदि अधिकांश नहीं) सॉफ्टवेयर डेवलपर्स किताबें नहीं पढ़ते हैं, तो विकास ब्लॉग ब्राउज़ नहीं करते हैं, और अन्य डेवलपर्स (उनकी कंपनी के बाहर) के साथ बिल्कुल भी संवाद नहीं करते हैं। यदि आप "21 दिनों में विज़ुअल बेसिक सीखते हैं" पुस्तकों में से किसी एक के साथ खुद को सिखाते हुए विकास में आते हैं, तो आपको संस्करण नियंत्रण के बारे में सुनने की संभावना नहीं है। वास्तव में, मुझे केवल 10 साल पहले विश्वविद्यालय में संस्करण नियंत्रण के बारे में सीखना याद नहीं है।

— जोएरी सेब्रचेट्स 13

@ ओज़री - शुक्र है कि जहां मैं काम करता हूं, सच नहीं, लेकिन मैं इसे सामान्य रूप से मान सकता हूं।

— स्टीव

@perdian - आप कहते हैं, "काफी कुछ कंपनियां" लेकिन कोई भी विवरण नहीं देते हैं ... क्या आपके पास लेखों, ब्लॉगों आदि के नामकरण और छायांकन के लिए कोई लिंक है? मैं यह नहीं कह रहा हूं कि मैं आप पर विश्वास नहीं करता (वास्तव में मैं आप पर विश्वास करता हूं), लेकिन डेटा हमेशा अच्छा होता है ...

— स्टीव

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

— perdian

Answer 3

मेरे उद्योग की प्रत्येक कंपनी (बैंकिंग) के बारे में वर्तमान में संस्करण नियंत्रण का उपयोग किया जाता है। लेकिन संस्करण नियंत्रण के बिना सॉफ़्टवेयर को सफलतापूर्वक विकसित करना निश्चित रूप से संभव है। 20-30 साल पहले। हमने ठीक वैसा ही किया।

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

Comments

मैं इस बात से सहमत नहीं हूं कि यह "उस सड़क को जारी रखने" के लिए पूरी तरह तर्कसंगत है। हां, पिछले X वर्षों के दौरान सॉफ्टवेयर वितरित करने का मतलब यह नहीं है कि यह अगले Y वर्षों में बिना किसी बदलाव के काम नहीं करेगा। हालांकि, सीआई को मौजूदा (और काफी परिपक्व) सॉफ्टवेयर उत्पादों में पेश करने के बाद हमेशा इससे कुछ हासिल होता है।

— पेर्डियन

@perdian: बहुत सारी पहल से हमेशा कुछ हासिल होता है। तो आपको सब कुछ के खिलाफ CI को संतुलित करना होगा। आप बस यह दावा नहीं कर सकते हैं कि CI आपको हर चीज से ज्यादा लाभ देता है। आपको अवसर लागतों को भी मापना होगा।

— रोडवेयर

@ एसके-तर्क: यूके बैंकिंग उद्योग में उस समय आरसीएस पूरी तरह से अज्ञात था। और हमने बिना किसी स्रोत नियंत्रण के कुछ बहुत बड़े और मजबूत सिस्टम विकसित किए।

— रोडवायर

-1: "बस हर कंपनी के बारे में" यह एक बहुत व्यापक कथन है जो गलत है। मैंने पिछले वर्ष कुछ कंपनियों को देखा है जो किसी भी संस्करण नियंत्रण उपकरण का उपयोग नहीं करते हैं, एक साझा निर्देशिका पर संस्करण प्रतियों पर भरोसा करते हैं। हां, इसने मुझे रुला दिया। उन्होंने कहा कि "svn का उपयोग करना बहुत कठिन है"। हे भगवान। लेकिन मुझे अभी भी कुछ ऐसी कंपनियां मिली हैं जो इस तरह हैं। सामान्य मत करो, उद्योग में हर कोई नहीं जानता कि स्रोत नियंत्रण प्रणाली क्या है, न ही ऑनलाइन कुछ भी सीखता है, और न ही यह जानता है कि एक निरंतर एकीकरण क्या है। (मैं सहमत हूँ कि नरक है। अब वहाँ नहीं होने के लिए खुश)।

— Klaim

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

— रूक

Answer 4

बस @ रोडवार्इयर के जवाब के लिए एक काउंटर पॉइंट बाहर रखना है:

मैं एक बैंक के लिए काम करता हूं। मैंने पिछले 3 वर्षों को संस्करण नियंत्रण को लागू करने में बिताया है और अब इसे हमारे कोडबेस के लगभग 20% पर लाने में कामयाब रहा है (जो कि काफी बड़ा है, हमारे पास लगभग 20 डेवलपर्स हैं और> 16 वर्षों के लिए हमारे सिस्टम को विकसित किया है)

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

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

Comments

मेरी संवेदना। उद्योग के कम से कम कुछ हिस्सों की तरह लगता है गंभीरता से उपकरण की कमी है। मुझे लगता है कि यह फिर से बच्चों के बारे में कहानी है। क्या मैं पूछ सकता हूं कि एक पागल व्यक्ति संस्करण नियंत्रण को क्या कहेगा?

— दारमाकर 12

आप इसे संपादित करने से पहले मैन्युअल रूप से कोड की एक प्रति ले रहे हैं। जैसे, MyProg -> MyProd.old4

— Dan McGrath

अफसोस की बात है कि यह प्रथा लोगों के सोचने से ज्यादा आम है

— क्रेग टी

Answer 5

संस्करण नियंत्रण: मेरी पहली नौकरी में 25 साल पहले इस तरह का कोई संस्करण नियंत्रण प्रणाली नहीं थी, लेकिन यह पीडीपी -11 s पर RSX11 था। हालांकि, डिजाइन और कोड (यह परमाणु उद्योग में था) की औपचारिक समीक्षा के साथ गुणवत्ता नियंत्रण का बहुत उच्च स्तर था।

तब से हर काम में SCCS, PVCS, क्लियरकेस, cv और perforce सहित संस्करण नियंत्रण प्रणालियों का उपयोग किया गया है।

इसलिए मेरे अनुभव में गंभीर सॉफ़्टवेयर विकास में संस्करण नियंत्रण का उपयोग बहुत अधिक सार्वभौमिक है।

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

मैंने एक जगह (एक बड़े बैंक) में काम किया है, जिसमें कुछ परियोजनाओं के लिए CI था, और हमने अपने प्रोजेक्ट पर एक तरह का CI सिस्टम लागू किया, जिससे चीजें बहुत आसान हो गईं, लेकिन इसे करने में लगभग 6 महीने लग गए।

Comments

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

— डमरक

Answer 6

मुझे लगता है कि MOST कंपनियां इन चीजों का उपयोग नहीं करती हैं, क्योंकि वे लाभों को नहीं समझती हैं और उनके डेवलपर्स या तो सीखना नहीं चाहते हैं या वे "बर्तन को हिला" करने से डरते हैं कि वे कैसे अलग हैं। पहले किया।

Comments

पूर्ण रूप से! मैंने जवाब सुना है (या शायद हमें इसे लंगड़ा बहाना कहना चाहिए) "हमने अब तक इसका इस्तेमाल नहीं किया है और चूंकि यह काम किया है (किसी तरह) हमें इसकी आवश्यकता नहीं है"। यह शर्म की बात है कि लोग अपने उपकरणों को बदलने के खिलाफ कितने दृढ़ हैं।

— 17

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

— वेन मोलिना

Answer 7

हालाँकि मैं अब एक कर्मचारी हूँ, मैं एक डेटाबेस सलाहकार के रूप में स्व-नियोजित हुआ करता था। उन कई, कई वर्षों के दौरान, मैं माँ और पॉप स्तर से लेकर फॉर्च्यून 100 तक 800 और 1000 कंपनियों के बीच कहीं था।

मैंने अपेक्षाकृत कुछ स्थानों को देखा, जिन्होंने निरंतर एकीकरण किया, लेकिन मुझे कभी भी ऐसी कंपनी को देखकर याद नहीं किया जो संस्करण नियंत्रण का उपयोग नहीं करती थी। मैंने कुछ देखा, जहाँ संस्करण-नियंत्रित कोड के लिए कोई केंद्रीकृत भंडार नहीं था। व्यक्तिगत प्रोग्रामर ने अपने कंप्यूटर पर या तो संस्करण नियंत्रण का उपयोग किया या सर्वर पर अपने होम डायरेक्टरी के नीचे संस्करण-नियंत्रित कोड रखा।

मुझे नहीं लगता कि इनमें से कोई भी कंपनी सॉफ्टवेयर व्यवसाय में थी, लेकिन उनके प्रोग्रामर निश्चित रूप से थे।

Answer 8

मेरा एक सहकर्मी इस धारणा के तहत था कि हमारा सॉफ्टवेयर विभाग अत्यधिक उन्नत था क्योंकि हमने निरंतर एकीकरण के साथ एक बिल्ड सर्वर और एक संस्करण नियंत्रण सॉफ्टवेयर दोनों का उपयोग किया था।

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

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

मैंने इसके लिए सबसे बड़े कारण देखे हैं:

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

2. प्रबंधक गैर-आईटी लोग हैं, और यहां वे सभी हैं कि आप किसी ऐसी चीज पर पैसा खर्च करना चाहते हैं जिसकी पहले जरूरत नहीं है।

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

Comments

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

— डमरक

Answer 9

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

लगातार मेल जोल? जरूरत पड़ने पर ही इसका इस्तेमाल करें। मेरे लिए, बस दो सॉफ्टवेयर इंजीनियर हैं इसलिए हम निरंतर एकीकरण से लाभ नहीं लेंगे क्योंकि हम अपने स्वयं के सॉफ्टवेयर पर काम कर रहे हैं।

Comments

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

— दारमाकर

@ ददारामक: यदि दो इंजीनियर दो अलग-अलग उत्पादों पर स्वतंत्र रूप से काम कर रहे हैं जो एकीकृत नहीं हैं।

— ब्रायन

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

— माइकल के

एक स्वचालित निर्माण के साथ आप वहां आधे रास्ते पर हैं। बस यह जानकर कि

— कंपाइल

Answer 10

हा, आपको लगता है कि आप उन्नत हैं क्योंकि आपके पास SCM और CI सिस्टम है? आपको बता दें कि यह शौकिया घंटे है जब यह नीचे आता है।

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

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

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

Comments

जबरदस्त हंसी ! हस्ताक्षरित: एक पेशेवर।

— deadalnix

मैं मानता हूं, SCM और बग ट्रैकर काम करने के लिए पैंट पहनने के बराबर विकास है। CI एक महत्वपूर्ण कार्य का मूल स्वचालन है। स्वचालित बैकअप की तरह लेकिन रिलीज़ के लिए। आह, CCB की बैठकें। हर हफ्ते, घड़ी की कल की तरह।

— टिम विलक्रॉफ्ट

Answer 11

यहां तक ​​कि दो प्रोग्रामर के साथ जब आपका जटिल अनुप्रयोगों और कार्यों की सूची पर काम करना एक दूसरे के परिवर्तनों को हथौड़ा नहीं करना मुश्किल हो सकता है।

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

मुझे सीआई से कई लाभ मिलते हैं, लेकिन मैं सोच भी नहीं सकता कि कोई भी कंपनी संस्करण नियंत्रण सॉफ्टवेयर का उपयोग क्यों नहीं करेगी।

Answer 12

आखिरी काम मैंने बिना संस्करण नियंत्रण के 2006 में किया था (मैं एक वेब डेवलपर, एफडब्ल्यूआईडब्ल्यू) हूं। मुझे नियुक्त करने से पहले कंपनी के पास केवल 2 या 3 डेवलपर्स थे, लेकिन मैं 10 में से पहला था या डेवलपर्स ने सिर्फ कुछ महीनों में काम पर रखा था। किराए पर लेते समय मैंने जो पहला काम किया था, वह था संस्करण नियंत्रण (सीवीएस, क्योंकि मैं उस समय नहीं जानता था कि यह कितनी बुरी तरह से चूसा है!), लेकिन कई डेवलपर्स ने मुझे काम पर रखने के बाद काम पर नहीं रखा। वातावरण, इसलिए इसका उपयोग नहीं किया। ओह, क्या मैंने उल्लेख किया है कि उनके पास आवेदन के स्थानीय उदाहरण भी नहीं हैं? उन्होंने सर्वर पर कोड हैक किया। और कोई स्वचालित परीक्षण नहीं। जब मुझे लगता है कि मैं उस पर वापस आ गया हूं।

इससे पहले, मैंने संस्करण नियंत्रण के बिना कुछ एएस / 400 प्रोग्रामिंग काम किया था। मुझे नहीं पता कि उस माहौल के लिए एक अच्छा VCS भी उपलब्ध था।

अब मैं अपने सभी वन-मैन प्रोजेक्ट्स के लिए Git का उपयोग करता हूं, और मेरी पिछली कई नौकरियों ने भी इसका उपयोग किया है।

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

Comments

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

— सिलिकॉनट्रस्टस्टार

और आप शायद क्यूए, या कुछ और के बारे में चिंता करना शुरू करने से पहले एक अच्छे परीक्षण सूट पर ध्यान केंद्रित करना चाहते हैं।

— मर्नेन लाईबो-कोसर 23

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

— सिलिकॉनट्रस्ट

@siliconrockstar मैं अपने खुद के कोड के लिए एक अच्छा परीक्षण सूट होने के बारे में बात कर रहा था; पुस्तकालय कोड के लिए परीक्षण का उपयुक्त स्तर काफी अलग मामला है।

— मार्नेन लाइबो-कोसर

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

— 13:22 बजे मार्नेन लाइबो-कोसर

Answer 13

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