जब आपने रात का निर्माण तोड़ दिया है तो माफी कैसे मांगें [बंद]


181

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

एक गैर-देशी अंग्रेजी वक्ता होने के नाते, मुझे सही शब्दों के साथ आने में कठिनाइयाँ हैं। क्या कोई मदद कर सकता है?


99
यदि निर्माण कभी नहीं टूटा तो मुझे एक टूटी हुई निर्माण प्रक्रिया पर संदेह करना शुरू हो जाएगा;)
लाजर

6
आपको कैसे पता चला कि निर्माण टूट गया था?

65
कैसे के बारे में: "मुझे रात के निर्माण को तोड़ने के लिए बहुत खेद है। यदि आप सजा के रूप में मेरे वेतन को वापस लेना चाहते हैं, तो मैं कंपनी को ट्रिब्यूनल में रोजगार नहीं दूंगा"। नाह, बस मजाक कर - माफी मत मांगो, इस तरह का सामान हर समय होता है। जो लोग "आप सभी" हैं, वे f.king साइको हैं, जो नहीं जानते कि सिस्टम को पूर्व स्थिति में ठीक से कैसे पुनर्स्थापित किया जाए।
जस

14
मैंने अपने पहले 10 कमिट पर निर्माण को तोड़ दिया! इसके बारे में चिंता मत करो
कोई भी

135
मेरी इच्छा है कि मैं एक रात का निर्माण करने के लिए टूट गया था ..
अधिकतम

जवाबों:


306

माफी मांगें!

  • एक नीला चाँद में एक बार निर्माण को तोड़ना कोई बड़ी बात नहीं है, और कभी भी शो-स्टॉपर नहीं होना चाहिए।
  • निरंतर, स्वचालित बिल्ड को कॉन्फ़िगर नहीं करने के लिए यह आपके प्रबंधक की गलती है।

इसके अलावा, मुझे यकीन है कि आपकी टीम 'जोएल टेस्ट' में विफल रही है और एक कदम में निर्माण नहीं कर सकती है।

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


31
+1 सहमत! माफी न मांगें। जानें कि आपने क्या गलत किया। इसे दोबारा न करें, कम से कम जल्द नहीं। विनम्र रहें जब लोग "आप सभी पर" हों। जानें कि वे क्या कहते हैं (भले ही यह सिर्फ एक चुभन हो और कौन ठीक हो)।
पीटर के।

12
ठीक है, आप अभी भी माफी मांग सकते हैं ... लेकिन मैं थोड़ा हैरान हूं कि लोग आप पर निर्भर हैं। यदि आप टीम में नए हैं, तो ऐसा आश्चर्य नहीं होना चाहिए कि आपने गलती की है। कम से कम यह दर्शाता है कि आपने कुछ किया :)
फिलिप

40
+1। एक रात का निर्माण करने का पूरा उद्देश्य समस्याओं को जल्द से जल्द पकड़ना है और इससे पहले कि वे एक रिलीज के साथ नौकायन करें। 95% डेवलपर्स ने अपने करियर के दौरान उच्च-दृश्यता की गलतियाँ की हैं। अन्य 5% झूठ बोल रहे हैं।
ब्लरफ्ल

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

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

182

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

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

मुझे सहकर्मी क्षमायाचना बहुत पसंद है। स्वादिष्ट, स्वादिष्ट माफ़ी।


83
+1 के लिए "मुझे सह-कर्मी माफी से प्यार है। स्वादिष्ट, स्वादिष्ट माफी।"
जस

32
रात्रिकालीन निर्माण को तोड़ना एक बात है लेकिन उत्पादन डेटाबेस को उड़ाना एक दूसरे स्तर पर है। अगर मैंने कभी ऐसा किया है कि मैं चाहता हूं कि ग्रिलिंग बर्गर मेरी सजा का सबसे बुरा था।
maple_shaft

20
आप अपराध बोध का लगभग स्वाद ले सकते हैं।
माइक स्पीड

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

7
drop database... ओह उन दो छोटे शब्दों की शक्ति। यह वर्षों पहले था, लेकिन मैं इसे अच्छी तरह से याद करता हूं;)
लेह

80

आपके लिए दो उद्धरण:

जो आदमी कोई गलती नहीं करता है, वह आमतौर पर कुछ भी नहीं करता है ।-- विलियम कॉनर मैगी

जो कोई भी गलती नहीं करता है वह पर्याप्त प्रयास नहीं कर रहा है। - वेस रॉबर्ट्स

मैं जिम जी के साथ सहमत हूं , माफी नहीं मांगता हूं, लेकिन इससे सीखता हूं और फिर से वही गलती नहीं करता हूं ... इसे रखो DRY);


9
या अधिक सामान्य उद्धरण है: "चलो वह है जो पाप के बिना पहला पत्थर डाले" यदि जो कभी भी टूटे हुए निर्माण के बारे में विलाप कर रहा है उसने निर्माण को पहले तोड़ दिया है, तो वे विलाप नहीं करना चाहिए
रिचर्ड

दूसरे की तरह !!
सूफेंडी

1
, हर ग्रैड / जूनियर मैंने कभी प्रशिक्षित किया है करने के लिए अपने आप का हवाला देते हुए "I expect you to make lots of mistakes. Own up to them, accept them, and learn from them. If you never make mistakes, you'll never really learn anything"
रॉबिन्स

"DRY" सिद्धांत का अच्छा उपयोग ... :)
जे। एलन

53

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

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

हमने एक टूटी हुई इमारत की तरह कुछ लिया और इसे टीम बिल्डिंग अभ्यास में बदल दिया।


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

यह एक तरह लगता है वास्तव में बहुत अच्छा तरीका है गलतियों को संभालने के लिए।
ट्रूफा

3
निरंतर एकीकरण डकी , हाहाहा
हल्लाबाहो

43

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

मैं इन परिस्थितियों में एक औपचारिक माफी नहीं चाहता, लेकिन अगर आपको वास्तव में लगता है कि एक अधिक औपचारिक माफी उचित है, तो आपके माफी को इन चीजों को करना चाहिए:

  • खेद अभिव्यक्त करना।
  • समस्या बतलाओ।
  • जिम्मेदारी लें।
  • सुधार करो।
  • चेहरा बचाए।

यही है, "मुझे खेद है [एक्सप्रैस क्षेत्र] कि मैंने आपको [[सुरक्षित जगह] बनाने में [[स्टेट प्रॉब्लम] को तोड़ने के लिए [सुरक्षित रूप से सुरक्षित]] ले लिया। डोनट्स मेरे लिए कल हैं। [MAKE AMENDS]"

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

अंत में, निर्माण तोड़ने पर कुछ विचार:

मैं C # / Visual Basic कंपाइलर टीम पर काम करता हूं। बेशक आज विजुअल स्टूडियो इतनी बड़ी परियोजना है कि इसके पास बुनियादी ढांचे के निर्माण के प्रबंधन के लिए अपनी खुद की एक टीम है, और अपने स्वयं के समर्पित एयर कंडीशनिंग सिस्टम के साथ एक विशाल कमरा है। 1990 के दशक के मध्य में जब मैंने इंटर्न के रूप में विजुअल बेसिक बिल्ड टीम शुरू की थी, तब मैं एक इंटर्न थी - और मशीनों से भरी एक कोठरी। समय बदल गया है!

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

यह आखिरी सा लगता है कि शायद क्रूर हो, लेकिन यह वास्तव में एक मूल्यवान उद्देश्य था। चूंकि लगभग सभी ने एक समय या किसी अन्य पर निर्माण को तोड़ दिया, अंततः पूरी टीम रात के निर्माण की पुष्टि करने के लिए प्रक्रियाओं को सीखेगी।


15

माफी न मांगें। यह आपके सहकर्मी हैं जो आपकी पहली प्रतिबद्धताओं की समीक्षा नहीं करने और निरंतर एकीकरण सर्वर की तरह निर्माण करने के लिए त्वरित प्रतिक्रिया प्रणाली नहीं होने के लिए दोषी हैं।

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

वैसे भी, माफी का एक औपचारिक मेल शायद थोड़ा बहुत है।


उत्कृष्ट बिंदु - सहकर्मी समीक्षा को यह पकड़ना चाहिए था। क्योंकि आप कर समकक्ष समीक्षा परिवर्तन से पहले वे, सही गुरु / HEAD / डिफ़ॉल्ट करने के लिए लागू कर रहे हैं?
फ्रैंक शीयर

11

एक मूलभूत नियम - जब आप गलत हों, तो ADMIT IT: - | आपको माफी मांगने की जरूरत नहीं है। गलतियां सबसे होती हैं। पेशेवरों इसे स्वीकार करते हैं। वह टीम वर्क है। टीम के अन्य सदस्यों को आपकी मदद करने के लिए एक साथ खींचना चाहिए। यदि वे मदद के लिए ए.एस. सबसे बाद में जो कहना है वह है - हम इससे क्या सीख सकते हैं?

वे कहते हैं कि एक सफल शादी तीन छोटे शब्दों पर आधारित है - "मैं गलत था"।

यदि कोई कभी-कभार गलती नहीं करता है, तो वे काम नहीं कर रहे हैं, लेकिन एक गलती जो किसी से नहीं सीखती है वह दो गलतियां हैं।


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

6

सबसे अच्छा माफी जल्दी से विराम को ठीक कर रहा है


5

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

यदि आपके सहकर्मी उनके परिवर्तनों का परीक्षण करते हैं और रात्रि निर्माण पर विराम खोजने की अपेक्षा करते हैं, तो (C) आपके पास एक भंगुर प्रक्रिया है (और आपको चरम प्रोग्रामिंग में पाए गए परीक्षण की तरह परिचय देना होगा)।

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

आपके और आपकी कंपनी के परीक्षण के आधार पर, मैं केस-दर-मामला आधार पर माफी चाहूंगा:

  • (ए) मैं निर्माण परीक्षण में विफल रहा लेकिन मेरे परिवर्तनों में जाँच की। क्षमा करें, मैं अपनी प्रक्रिया बदल रहा हूं इसलिए मैं इसे दोबारा नहीं करूंगा।
  • (बी) मैंने फिर से होने की संभावना को कम करने के लिए बिल्ड टेस्ट पास किया और जुनाइट टेस्ट XYZtest.java को जोड़ा।
  • (ग) चूंकि हमारे पास एक निर्माण परीक्षण प्रक्रिया नहीं है, इसलिए मैं अपने परिवर्तनों के लिए एक निर्माण कर रहा हूं। मैं आपके साथ साझा करना चाहता हूं कि हम अपनी निर्माण प्रक्रिया को कैसे बेहतर बना सकते हैं।
  • (डी) मैं पुन: होने की संभावना को कम करने के लिए एक JUnit परीक्षण XYZtest.java लिखने के लिए बिल के साथ काम करूंगा।

मुझे यकीन है कि वहाँ एक (ई) है कि मैं के बारे में सोचा नहीं है।

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


2

माफी न मांगें। आप इंसान हैं और आप गलतियाँ करेंगे। हर कोई कभी-कभी बिल्ड को तोड़ देगा, कुंजी बस इसे जल्दी से ठीक करने के लिए है।

के रूप में लोगों के लिए आप पर कूद ... अच्छी तरह से मैं के रूप में अगर वे कभी एक बग में लिखा है उत्सुक हूँ।


2

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

किसी भी मामले में, इस तरह के एक गॉफ को किसी तरह के पोस्टमार्टम के साथ ए) यह पता लगाना चाहिए कि यह कैसे हुआ और बी) फिर से होने की संभावना को कैसे कम किया जाए।

मैं आपकी संरचना से परिचित नहीं हूं (मैं बहुत अलग माहौल में काम करता हूं) लेकिन आखिरकार, वास्तविकता यह है कि कभी-कभी लोग गलती करते हैं, और चीजें टूट जाती हैं। आप अनुभव से सीखते हैं और आगे बढ़ते हैं।


2

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

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


2

उम। आपको टूटा हुआ टोकन मिलता है । अगले भाग्यशाली प्राप्तकर्ता को रेबीज पास करें। हमेशा होता है। गुणवत्ता महत्वपूर्ण है, लेकिन गलतियाँ अपरिहार्य हैं। उन्हें ठीक करें। आगे बढ़ो। शर्म करो अगले गरीब।


1
मैंने इसे बहुत देखा है। दूसरे को आप रात के निर्माण के बाद "देखने के लिए" प्राप्त करते हैं जब तक कि कोई और इसे नहीं तोड़ता। इसका मतलब यह नहीं है कि इसे ठीक करना, लेकिन यह पता लगाना क्यों और किसे ठीक करना चाहिए।
स्टीफन डार्लिंगटन

1

एक सामान्य नियम के रूप में, मैं कहूंगा:

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

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


1

टीम विफल हो गई।

आपकी कंपनी को पहली बार निर्माण करने वाले देव पर अधिक कोड समीक्षा की आवश्यकता है।

मैं अभी यह नहीं देखता कि कोई टीम इस बात की अनुमति कैसे दे सकती है कि वे उनके बिना समीक्षा करें और इस तरह से कुछ आश्वासन पेश करें कि आप चीजों को सही तरीके से कर रहे हैं।

रिलीज के समय के करीब होना कोई बहाना नहीं है, बल्कि नए कोड को दोबारा जांचने का एक बेहतर कारण है।

यदि आपकी रिहाई आसानी से पूर्ववत नहीं की जा सकती है, तो इस समूह के साथ और भी बड़ी समस्याएं हैं।


0

मुझे समझ नहीं आ रहा है कि लोग आपके ऊपर क्यों हैं। यदि सिस्टम अच्छी तरह से सेटअप है, तो उन्हें आपके परिवर्तनों को छेड़ने / उन्हें बहुत जल्दी ठीक करने में सक्षम होना चाहिए।

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

और हाँ - माफी नहीं माँगता। बस अपने प्रबंधक के साथ एक चैट करें और उसे समझाएं कि आपने जो किया है, उससे सीखा है।


0

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

यदि बिल्ड ब्रेकिंग एक बड़ी बात है, तो इसका मतलब है कि आपकी प्रक्रिया टूट गई है।

आपको लगातार बिल्ड करना चाहिए, न कि रात में बिल्ड करना।


+1 के लिए "यदि एक बिल्ड ब्रेकिंग एक बड़ा सौदा है, तो इसका मतलब है कि आपकी प्रक्रिया टूट गई है।" दूसरी ओर, आपको अभी भी टूटी हुई प्रक्रिया से निपटना होगा, और इसका मतलब है कि जब तक प्रक्रिया में सुधार नहीं किया जाता तब तक आप रात के निर्माण से बचने के लिए क्या कर सकते हैं।
कालेब

0

बेहतर देर से जवाब कभी नहीं ...

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

निजी तौर पर, मैं एक टूटे हुए निर्माण को एक अवसर के रूप में देखता हूं।

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

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


-1

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

लेकिन हाँ, इसे ठीक करना सुनिश्चित करें। कोई बड़ी बात नहीं। यह उत्पादन में नहीं है। बस एक बेकार रात।


-2

मेरी कंपनी में एक सामान्य अभ्यास है:

  • चिल्ला "यह मुझे नहीं था!" (आमतौर पर सीवीएस / एसवीएन साक्ष्य अन्यथा)
  • एक टी-शर्ट पहने हुए कहा कि "माय-यूज़लोइन इज़ शुल्ड!" (हाँ, हमारे डेवलपर की 50% ऐसी शर्ट है)
  • यह दावा करते हुए कि यह स्थानीय Sendbox में काम करता है और सभी परीक्षण ठीक पारित हुए

मेरी कंपनी के पास इस तरह की "घटना" को संभालने का एक अच्छा तरीका है:


-2
  • मैं माफी नहीं मांगूंगा।

  • मैं मुझे टूटे हुए निर्माण की अनुमति देने के लिए CI नेतृत्व को दोषी ठहराऊंगा।

  • डेवलपर्स को टूटे हुए कोड को कम करने से रोकने के लिए CI प्रक्रिया होनी चाहिए।

  • यदि स्थानीय बिल्ड विफल हो जाता है, तो उसे बिल्ड सर्वर में प्रवेश करने की अनुमति नहीं दी जानी चाहिए।


1) निरंतर एकीकरण करने के लिए सभी परियोजनाएं स्थापित नहीं की जाती हैं। यह होना अच्छा है, और ओपी जैसी स्थितियों के साथ मदद कर सकता है, लेकिन यह किसी दिए गए से बहुत दूर है। 2) यह कभी नहीं माफी माँगता है जब भी यह वास्तव में एक बड़ी बात नहीं है, तब भी जब ऐसे उपकरण होते हैं जो समस्या को रोक सकते थे। 3) किसी अन्य व्यक्ति को आपकी समस्या के लिए दोष देना , चाहे वह वास्तव में आपकी गलती हो या न हो, एक घटिया विचार है।
कालेब

यहां दो समस्याएं हैं: 1 - स्थानीय मशीन पर टूटा हुआ कोड। एक बिल्ड सर्वर पर 2 - टूटा हुआ कोड। पहली समस्या बहुत मामूली है क्योंकि सभी डेवलपर्स गलतियाँ करते हैं। परिवर्तन पूर्ववत किया जा सकता है और सिस्टम या विभाग पर कोई प्रभाव नहीं पड़ेगा। दूसरी समस्या से सिस्टम और विभाग पर बहुत अधिक नकारात्मक प्रभाव पड़ने की संभावना है।
कोडार्ट

-2

जबकि मुझे लगता है कि किसी तरह की माफी हो सकती है, कृपया यह न कहें: "मैं यह सुनिश्चित करूंगा कि यह दोबारा न हो।" क्योंकि यह होगा। और अगर यह करता है तो यह आपको काटेगा।


-2

यदि आप एक ओपन सोर्स प्रोजेक्ट पर काम कर रहे हैं,

बस कहना है "क्षमा करें, मैंने निर्माण तोड़ दिया है। हो सकता है कि मैं बहुत नींद में था!"

और इसे जीथब टिप्पणी के रूप में जोड़ें।

ऐसा इसलिए है क्योंकि कई ओपन सोर्स डेवलपर्स आधी रात के दौरान कोड लिखते हैं।

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