मेरा सहकर्मी परीक्षण किए बिना धक्का देता है और धक्का देता है


113

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

मैंने उसे कई बार कहा कि यह तरीका अच्छा काम नहीं है। मैं फिर से उसके साथ असभ्य नहीं होना चाहता और वह कंपनी में मेरे साथ एक ही स्थिति में है और उसने मुझसे कहीं अधिक काम किया है।

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

इससे पहले कि मैं शुरू करता, कंपनी एफ़टीपी जैसे एंटिक तरीकों का उपयोग करके तैनाती कर रही थी, और कोई संस्करण नियंत्रण नहीं था।

मैंने उन्हें / हमें Git, Bitbucket, Dploy.io, और HipChat का उपयोग करने के लिए मजबूर किया। तैनाती स्वचालित नहीं है, किसी को dply.io पर लॉग इन करना होगा और तैनाती बटन दबाएं।

अब, मैं उन्हें उत्पादन सर्वर पर परीक्षण न करने के लिए कैसे मजबूर कर सकता हूं? हिपचैट बॉट की तरह कुछ समझ सकते हैं कि एक ही लाइन पर बार-बार संपादन होता है और प्रोग्रामर को एक नोटिस भेजा जाता है।


1
टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।
वर्ल्ड इंजीनियर

5
चूंकि आप Git पर हैं, इसलिए मास्टर में विलय करने और उत्पादन में तैनात करने से पहले कोड समीक्षाओं को लागू करने के लिए पुल अनुरोधों का उपयोग करें। इसके अलावा, तैनाती सर्वर में लॉग इन करने के लिए उसकी साख को हटा दें। एक गैर-डेवलपर में इस प्राधिकरण को केंद्रीकृत करें। (क्रेडिट कार्ड उद्योग द्वारा लागू पीसीआई अनुपालन इस तरह से आवश्यक है।)
बरेट 14'15

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

2
क्या "केंद्रीय" रिपॉजिटरी में एक धक्का हमेशा एक उत्पादन की तैनाती को ट्रिगर करता है? यह निश्चित रूप से नहीं करना चाहिए।
jpmc26

3
मैंने सवाल पढ़ा और खुद से कहा कि आदमी को तुर्की होना चाहिए और आप वहां जाएं :) इस बात की जाँच करें भाई: nvie.com/posts/a-successful-git-branching-model । आपके पास कम से कम दो शाखाएँ होने की आवश्यकता है: मास्टर और देव जहां डेवलपर्स केवल देव को धक्का देते हैं और परीक्षण करने के बाद आपको मास्टर और परिनियोजित करते हैं।
केमरे

जवाबों:


92

आपको एक उचित गुणवत्ता आश्वासन (QA) प्रक्रिया की आवश्यकता है।

एक पेशेवर सॉफ्टवेयर विकास टीम में, आप विकास के अधिकार से उत्पादन तक नहीं धकेलते हैं। आपके पास कम से कम तीन अलग-अलग वातावरण हैं: विकास, मंचन और उत्पादन।

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

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

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


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

1
@ BillWoodger क्यों? उनके लिए यह एक 'आगामी परिवर्तन और रोलबैक' प्रणाली है। न केवल उन्हें यह देखने का लाभ मिलता है कि 'असली होने से पहले' क्या हो रहा है, इसका एक तरीका यह भी है कि अगर चीजें खराब होती हैं तो आसानी से अंतिम संस्करण में रोलबैक किया जा सकता है। स्टेजिंग एनवी अंत प्रोग्रामर परीक्षण है मत भूलना।
gbjbaanb

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

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

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

54

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

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

आप अपना परीक्षण सूट (आप उनमें से एक है, ठीक है?) शामिल हो सकते हैं एक जाँच शामिल है जो यह निर्धारित करती है कि क्या आप एक उत्पादन सर्वर पर हैं और यदि यह करता है, तो कार्यालय में सभी को एक ईमेल कहकर भेजता है Looks like $username is testing on prod, watch out। शायद सार्वजनिक रूप से अपने सहयोगी को शर्मसार करना अप्रिय होगा। या आपकी टीम आईपी पर प्रतिबंध लगाने जैसी तकनीकी पाबंदियां लगा सकती है, जो आपकी टीम को ठेस पहुंचाने से रोक सकती है (जिसे आप उठा सकते हैं लेकिन आपको सही ठहराना होगा)।

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

निश्चित रूप से आप वास्तव में जो चाहते हैं, वह इस व्यवहार को दंडित करने के लिए नहीं है, बल्कि इसे रोकने के लिए है ?

मैंने उन्हें / हमें उपयोग करने के लिए मजबूर किया [...]

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

इसलिए बातचीत से शुरुआत करें।

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

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


10
बातचीत के लिए +1। एक साझा समझ होनी चाहिए कि यह एक समस्या है और यह एक समस्या क्यों है। तभी तकनीकी समाधान से कोई सफलता मिल सकती है।
पैट्रिक

9
देव सर्वर / स्टेजिंग वातावरण प्राप्त करने के लिए +1। जब तक चीजों को धकेलने के लिए किसी की मशीन के बाहर एक वास्तविक स्थान नहीं है, तब तक यह व्यवहार पूरी तरह से सहकर्मी की गलती नहीं है। केवल इतना ही एक व्यक्ति अपनी मशीन पर कर सकता है, और अगर कुछ नहीं तो अतिरिक्त वातावरण अक्सर परीक्षण पर विचार प्रक्रिया / दृष्टिकोण में बदलाव के साथ मदद करता है।
जोएल कोएहॉर्न

20

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

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

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


17

मैं इसे बड़े पैमाने पर मानवीय समस्या के रूप में देखता हूं - प्रक्रिया वहां है और उपकरण वहां हैं, लेकिन प्रक्रिया का पालन नहीं किया जा रहा है।

मैं इस बात से सहमत हूं कि दूसरों ने यहां क्या कहा है, इस संभावना के बारे में कि यह संभव है कि प्रश्न में डेवलपर बस एसवीएन मानसिकता में फंस गया है , और अच्छी तरह से सोच सकता है कि वह प्रक्रिया का पालन ​​कर रहा है।

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

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

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


1
मैं वास्तव में स्पष्ट नहीं हूं कि "प्रतिबद्ध / धक्का, उत्पादन के लिए तुरंत कैसे तैनात किया जाए, और अपने परिवर्तनों का परीक्षण करें और कहीं और नहीं" एक एसवीएन मानसिकता है ... उस प्रक्रिया का एकमात्र हिस्सा जिसमें एसवीएन शामिल है, वह प्रतिबद्ध है। यहां तक ​​कि एक एकल शाखा मॉडल या स्रोत नियंत्रण के साथ, एक प्रतिबद्ध जरूरी एक उत्पादन तैनात नहीं करता है। या कम से कम, यह नहीं होना चाहिए।
jpmc26

@ jpmc26: Git / SVN लौ युद्ध के जोखिम में: हमें अपने "विरासत" कोड के लिए एक SVN प्रणाली विरासत में मिली है लेकिन अपने नए काम के लिए Git का उपयोग कर रहे हैं। मैं लगभग गारंटी दे सकता हूं कि हमारे पास SVN सेटअप सही नहीं था और / या इसे सही उपयोग नहीं कर रहा था, लेकिन Git की शाखाओं को संभालने के साथ काम करना बहुत आसान लगता है। मुझे 100% यकीन है कि एसवीएन उचित तैनाती से निपटने में सक्षम है, लेकिन मैं यह भी देख सकता हूं (अपने अपूर्ण अनुभव से) कि कैसे एसवीएन आपको सही काम करने से "कम" मना कर सकता है। किसी भी मामले में, यह केवल एक योगदान कारक होगा और उपयोगकर्ता की शिक्षा अधिक महत्वपूर्ण है।
ट्रिपहाउंड

1
@TripeHound आपके द्वारा कोड परिवर्तन को प्रबंधित करने के लिए git सिस्टम के बारे में कोई तर्क बेहतर नहीं है। (Git के साथ मेरी आपत्तियों का आम तौर पर उच्च शिक्षण वक्र के साथ क्या करना है।) मेरी बात और है कि जबकि git में आपकी रिलीज़ प्रक्रिया को प्रबंधित करने में मदद करने के लिए अधिक क्षमताएं हो सकती हैं, जिस तरह से आपने अपनी बिल्ड इन्फ्रास्ट्रक्चर की स्थापना की है वह अभी भी आपके लिए मुख्य कारक है। स्रोत नियंत्रण का विकल्प। मेरे पास काफी सफल निर्माण और रिलीज ऑटोमेशन है जो काफी समय से एसवीएन में चल रहा है, इसलिए मैं वास्तव में स्पष्ट नहीं हूं कि "एसवीएन मानसिकता" क्या है या यह आपकी रिहाई पर नकारात्मक प्रभाव डालती है।
jpmc26

2
सिर्फ इसलिए कि आप मास्टर के लिए आ रहे हैं इसका मतलब यह नहीं है कि आपको उत्पादन के लिए तैनात करना चाहिए। यहां तक ​​कि अगर आपके मूल रेपो / svn रेपो को ठेस सर्वर पर होस्ट किया जाता है, तो यह इस तरह की बात नहीं करता है।
vonPetrushev

12

यह असामान्य नहीं है , खासकर छोटी टीमों में। इसके बारे में एक बड़ा सौदा न करें, लेकिन एक अनौपचारिक नियम बनाएं:

निर्माण तोड़ो, डोनट्स में लाओ।

या तो 1) आपको सप्ताह में दो बार डोनट्स मिलेंगे या 2) वे मानक का पालन करेंगे।

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

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


2
यह केवल एक कार्यालय के साथ काम करता है। जब आपके पास घर से काम करने वाले दूरस्थ डेवलपर्स की एक वितरित टीम है, तो इसके लिए समान अवधारणा क्या है?
एरोथ

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

8

अब, मैं उन्हें कैसे मजबूर कर सकता हूं ...

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

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

यह लाइव सर्वर पर समस्याओं के साथ आपके लिए दर्द क्यों है, लेकिन इस लड़के के लिए नहीं? क्या आपको कुछ पता है जो वह नहीं करता है? आप उसे चीजों को देखने के लिए क्या कर सकते हैं?

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

सामान्य तौर पर, प्रक्रियाओं को समझने की बजाय उन समस्याओं को हल करने के लिए लोगों के साथ मिलकर काम करने की कोशिश करें जो समझ में नहीं आती हैं।


6

सबसे बुरा क्या हो सकता है? क्या आपके पास बैकअप हैं जो पर्याप्त अच्छे हैं ताकि एक पुराने संस्करण को पुनर्स्थापित करके आपके डेटाबेस में यादृच्छिक रिकॉर्ड्स को ठीक किया जा सके?

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

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


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

न केवल आपके पास बैकअप है, बल्कि एक बहाली होने पर आपका व्यवसाय डाउनटाइम का खर्च भी उठा सकता है? और क्या यह मिनट, घंटे या जानकारी के दिन भी खो सकता है क्योंकि डेटाबेस का एक रोलबैक प्रदर्शन करना था? मैं लगभग सभी nontrivial मामलों में कहूंगा, इसका उत्तर एक शानदार 'नहीं' है। और यहां तक ​​कि तुच्छ मामलों में, आप 'बैकअप को पुनर्स्थापित' नहीं करना चाहते हैं कि आप अनटाइटेड कोड से निपटने के तरीके की जांच करते हैं। कुछ ऐसा होना चाहिए जो यह सुनिश्चित करता है कि जब कोड चेक किया जाता है और जब यह उत्पादन तक पहुंचता है, तो इसके बीच परीक्षण होता है।
Aroth

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

3

आप विभिन्न संभावित प्रक्रिया और तकनीकी समाधानों को स्पष्ट रूप से समझते हैं। मुद्दा यह है कि सहकर्मी को कैसे प्रबंधित किया जाए।

यह अनिवार्य रूप से एक परिवर्तन प्रबंधन अभ्यास है।

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

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

सेटअप नियमित (उदाहरण के लिए साप्ताहिक) प्रक्रिया पूर्वव्यापी। पूरी टीम है:

  • समस्याओं को पहचानें
  • कार्य प्रथाओं में सुधार के लिए स्वयंसेवी विचार
  • उन प्रथाओं को लागू करने में संलग्न हैं

यह स्वाभाविक रूप से पालन करना चाहिए कि पूरी टीम तब बेहतर प्रथाओं के अनुपालन को सुनिश्चित करने में भी मदद करती है।


एक पूर्वव्यापी पते को संबोधित करने और रचनात्मक तरीके से इस तरह के व्यवहार को बदलने का एक शानदार तरीका है!
ग्रीनस्कॉकॉक

1

मुझे लगता है कि आपने कुछ समस्याओं की पहचान की है:

  1. यह किसी भी कोड की तरह लगता है जिसे चेक किया जाता है, उसे किसी भी व्यक्ति द्वारा उत्पादन के लिए तुच्छ रूप से धकेला जा सकता है, जिसके पास कोड में जांच करने का अधिकार है।

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

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

आपके सहकर्मी ने पहले परीक्षण किए बिना कोड में जाँच के संदर्भ में एक बड़ी गलती की है। आपके संगठन ने तैनाती प्रक्रिया को अपनाते हुए एक बड़ी गलती को पागल कर दिया है, जो किसी भी परिस्थिति में उत्पादन तक पहुँचने के लिए अप्रयुक्त कोड की अनुमति देता है।

इसलिए व्यवसाय का पहला आदेश तैनाती प्रक्रिया को ठीक करना है। या तो सीमा जो उत्पादन को धक्का दे सकती है, या अपनी स्वचालित तैनाती प्रक्रिया में परीक्षण की उचित मात्रा को शामिल कर सकती है, या दोनों।

  1. ऐसा लगता है कि आपने कोई स्पष्ट रूप से परिभाषित विकास मानक / सिद्धांत निर्धारित नहीं किए होंगे।

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

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


0

आपको कंपनी में एक सतत एकीकरण + सहकर्मी समीक्षा प्रक्रिया को एकीकृत करना चाहिए। Bitbucket इसे आसान बनाता है।

और अन्य उपयोगकर्ताओं द्वारा सुझाए गए देव सर्वर के लिए +1।

उसके साथ असभ्य मत बनो, यह केवल आपके कार्य संबंध को चोट पहुंचाएगा।

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