कैसे कुशल रहने के लिए जब एक निर्माण लगभग हमेशा टूट जाता है


25

मैं एक मध्यम आकार की टीम में काम करता हूं जो समान स्रोत कोड साझा करता है और जबकि जगह में एक एकीकरण जारी रहता है, लेकिन जैसा कि हम सभी को एक ही शाखा में काम करना पड़ता है, निर्माण लगभग हमेशा टूट जाता है।

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

कहा जाता है कि, एक दिन में हर किसी के पास 10-15 मिनट की खिड़कियां होती हैं, जहां हमें चेक-इन करने की अनुमति होती है।

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

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


8
क्यों तुम शाखाओं नहीं कर सकते?
Zavior

6
स्पष्ट समाधान अपनी "व्यक्तिगत" शाखा को स्थापित करना और उसमें प्रतिबद्ध होना होगा, फिर उस शाखा को एक टीम के साथ एकीकृत करना होगा जो काम करती है
gnat

@ एक शाखा होने के कारण एक अतिरिक्त जटिलता होती है और इस तरह अतिरिक्त कार्य - एक शाखा से ट्रंक में विलय हो जाता है। और यह जटिलता को भी बढ़ाता है - न केवल मुझे ट्रंक को ऊपर रखने की आवश्यकता होगी, मुझे अपनी शाखा के लिए भी ऐसा करना होगा।

6
@ स्थानीय मशीन में जमा होने वाले बदलावों से छुटकारा पाना पहली बात है, चाहे कुछ भी हो। आपके द्वारा उल्लिखित अन्य मुद्दे भी वास्तविक हैं, लेकिन यह सबसे पहले हल करना है
gnat

6
मुझे वास्तव में समझ में नहीं आता है कि अगर वे स्थानीय रूप से अपडेट नहीं हुए हैं, तो वे बदलावों को कैसे आगे बढ़ा सकते हैं, और वे सभी tbh पर टूटे हुए निर्माणों को आगे क्यों बढ़ा रहे हैं
बेकार

जवाबों:


54

इस टिप्पणी के साथ शुरू करने के लिए:

... एक शाखा होने का अर्थ है एक अतिरिक्त जटिलता और इस तरह अतिरिक्त काम ...

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

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

जब वे अंततः धक्का देते हैं, तो यह एक वास्तविक तथ्य है

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


अब, आप कहते हैं

किसी को भी चेक-इन करने की अनुमति नहीं है, जबकि निर्माण लाल है

लेकिन इस मामले में बिल्ड को कभी भी ठीक नहीं किया जा सकता है, इसलिए यह काफी सटीक नहीं हो सकता है।

सामान्य तौर पर, अगर यह स्थानीय रूप से बनाने के लिए उचित है (यानी, बिल्ड बहुत बड़ा या धीमा नहीं है), तो डेवलपर्स को वैसे भी धक्का देने से पहले ऐसा करना चाहिए।

मुझे लगता है कि यह मामला नहीं है, क्योंकि तब वे पहली बार में टूटे हुए निर्माणों को आगे नहीं बढ़ाएंगे, लेकिन यह बहुत अच्छा होगा यदि आप इस बिंदु को स्पष्ट कर सकते हैं।

के जवाब में सामान्य तौर पर

कैसे कुशल रहने के लिए जब एक निर्माण लगभग हमेशा टूट जाता है

है: बिल्ड को तोड़ना बंद करो


23
+9000 "बिल्ड तोड़ना बंद करो।" गंभीरता से। सतत एकीकरण का पूरा, पूरा बिंदु निर्माण को तोड़ने से रोकने के लिए है और, यदि टूटा हुआ है, तो इसे जितनी जल्दी हो सके और जितना संभव हो उतना ब्रेक के करीब ठीक करें।
पैट्रिक ह्यूजेस

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

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

14

डेवलपर्स ... स्थानीय रूप से उनके परिवर्तन जमा करते हैं ... आप दुष्चक्र देख सकते हैं।

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

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

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

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

कृपया ध्यान रखें कि मैं एक डेवलपर हूं, प्रबंधक नहीं हूं, और इस प्रक्रिया या अन्य लोगों के व्यवहार को नहीं बदल सकता ...

परिशुद्धता के लिए, आप वास्तव में कर सकते हैं , ये प्रभाव और संचार कौशल के मामले हैं और किसी को अपनी पसंद की चीज़ों को बदलने के लिए वास्तव में शक्ति की स्थिति में होने की ज़रूरत नहीं है ( यदि आप "प्रबंधित करें" जैसी किसी चीज़ के लिए वेब खोजें) यदि आप 'अधिक जानकारी में रुचि रखते हैं)।

हालांकि, बल्कि बोझिल और प्रयास की खपत है और मैं पूरी तरह से समझ सकता हूं कि अगर कोई बस राजनीति में थोड़ी भागीदारी के साथ कोडिंग पर ध्यान केंद्रित करना चाहता है - तो अगर आप नहीं चाहते (भले ही सिद्धांत रूप में आप कर सकते हैं ), तो यह समझ में आता है। :)


7

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

अगर कोई सर्जन गंदे स्केलपेल को साफ करने वालों के साथ रखता है तो क्या होगा? यदि एक प्लंबर ने स्थापित पाइपों का परीक्षण नहीं किया तो क्या होगा? अगर एक वायलिन वादक हमेशा आर्केस्ट्रा के साथ धुन बजाता है तो क्या होगा?

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

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


5

मुझे लगता है कि जब तक आप सोचते हैं कि आप "सिर्फ एक डेवलपर" हैं और इसलिए आप उन चीजों को नहीं बदल सकते हैं जो आप इस समस्या से पीड़ित हैं।

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

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

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


-2 और कोई नहीं क्यों साझा करना चाहता है .. हे हे
हेव

1
आप कुछ अंडे को तोड़े बिना एक आमलेट नहीं बना सकते।
विलियम पायने

2

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

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


1

CI सिस्टम में एक साधारण परिवर्तन यह करेगा: निर्माण को तोड़ने वाले किसी भी परिवर्तन को स्वचालित रूप से वापस रोल किया जाता है। इससे भी बेहतर, सीआई रिपॉजिटरी को एक मंचन क्षेत्र बनने दें, जहां परिवर्तन केवल आधिकारिक रिपॉजिटरी के माध्यम से धकेल दिए जाते हैं जब निर्माण हरा होता है। जेरिट जैसे उपकरण यहां मदद कर सकते हैं।


3
लेकिन इस कार्य को असंभव बनाने के लिए "... ध्यान रखें कि मैं एक डेवलपर हूं, प्रबंधक नहीं हूं, और इस प्रक्रिया को बदल नहीं सकता ..."
SChepurin

@SChepuriyour आपकी प्रक्रिया अक्षम है, आपने प्रक्रिया, अवधि को बदलने की कोशिश की है। एक डेवलपर के रूप में, आप बदलाव को मंजूरी देने में सक्षम नहीं हो सकते हैं, लेकिन आप हमेशा प्रक्रिया में सुधार की दिशा में काम कर सकते हैं।
oefe

1

दो अन्य चीजें यहां मदद कर सकती हैं:

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

लेकिन आपको वास्तव में शाखाओं को देखना चाहिए।

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