जब डॉगफूडिंग एक उपकरण के अगले संशोधन का उपयोग करना शुरू करना उचित है?

Question

विशेष रूप से, मैं एक ऐसे उपकरण पर काम कर रहा हूं, जो एक DVCS और बिल्ड सिस्टम को एकीकृत करता है, लेकिन मुझे लगता है कि मैं जो चुनौती पेश कर रहा हूं, वह "मेटा" टूल (कंपाइलर, VCS, बिल्ड सिस्टम, टेस्ट रनर, आदि) विकसित करने वाले किसी भी व्यक्ति के लिए होगी। "डॉगफूडिंग" के माध्यम से विकसित करना चाहते हैं ।

मेरा सवाल यह है: एक स्क्रैम-स्टाइल रिलीज़ प्रक्रिया में ब्रांचिंग वर्कफ़्लो का उपयोग करके , किस बिंदु पर मैं टूल के विकास चक्र में टूल के नए संस्करण का उपयोग करना शुरू करूं?

मैं बीच में संतुलन बनाने के लिए एक प्रक्रिया की तलाश कर रहा हूं:

• लगातार developटूल के संस्करण का उपयोग करें : मुझे लगता है कि मैं अपना खुद का विकास तोड़ रहा हूं क्योंकि परिवर्तन शामिल हो जाते हैं।

• लगातार masterटूल के संस्करण का उपयोग करें : किसी भी मुद्दे को मैं डॉगफूडिंग के माध्यम से उजागर करता हूं वे मुद्दे हैं जो पहले ही जारी किए जा चुके हैं।

Comments

यह इस बात पर निर्भर करता है कि आप क्या हासिल करना चाहते हैं। क्या यह सिर्फ एक मास्टर संस्करण की बिक्री के लिए पर्याप्त होना चाहिए। यदि आप बग को प्रकट करना चाहते हैं, तो आपको एक रात का उपयोग करना चाहिए।

— एंडी

@ GlenH7 धन्यवाद! मैंने यहां एक शुरू किया: meta.programmers.stackexchange.com/questions/6074/…

— Jace Browning

Answer 1

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

दूसरा, आपको पिछले कार्यशील संस्करण पर वापस आने के लिए एक मृत सरल तरीके की आवश्यकता है, समस्याओं के लिए जो आपके स्वचालित परीक्षण नहीं पकड़ते हैं।

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

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

Comments

मुझे एक अलग शाखा (शायद dogfood) होने का विचार पसंद है जो "कहीं developऔर master" है। शायद releaseशाखाओं को dogfoodशाखा से आना होगा ।

— जैस ब्राउनिंग

Answer 2

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

यदि आपको आत्मविश्वास के स्तर के लिए मास्टर संस्करण की प्रतीक्षा करनी है, तो ऐसा ही हो।

Comments

क्या यह एकीकरण परीक्षण के लिए उपयोग करने के लिए "नकली" (गैर-उत्पादन) परियोजनाओं का निर्माण करता है?

— जैस ब्राउनिंग

यदि इसके द्वारा आप अंतरिम आंतरिक रिलीज का मतलब है, तो हाँ।

— रॉबर्ट हार्वे

Answer 3

गिट भी ऐसा उपकरण है और जाहिर तौर पर डॉगफूडिंग भी करता है। लेकिन यह अलग-अलग वातावरण में अलग-अलग हद तक करता है। सार्वजनिक सर्वर केवल जारी कर रहे हैं, जबकि डेवलपर्स आमतौर पर या तो काम करते हैं next(यह "विकसित" के लिए git परियोजना का नाम है) या pu(यहां तक ​​कि विकास से भी अधिक विकास)। किसी भी डेवलपर है कि कुछ समस्या से अवरुद्ध है करने के लिए वापस जा सकते हैं nextया master, या अंतिम रिलीज जब भी वे कुछ द्वारा अवरुद्ध कर रहे हैं और मुख्य भंडार प्रभावित नहीं है तो समस्याओं यह का हवाला देते हुए साफ किया जा सकता।

ब्रांचिंग मॉडल थोड़ा अलग नामों के साथ उपरोक्त के समान है। masterबड़ी रिलीज से क्या किया जाता है, maintअगली बिंदु रिलीज के लिए रिलीज शाखा है, nextथोड़े अंतर के साथ विकसित होने के समान है , जो सुविधाओं को पूरी तरह से विलय करने के बाद अलग-अलग मास्टर में विलय किया जा सकता है।

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

तो उस तरह का जवाब है। आप विकास के वातावरण में आपके पास सबसे अधिक विकास संस्करण को डॉगफूड करते हैं, लेकिन बिल्डिंग रिलीज के लिए पिछले रिलीज का उपयोग करें।

Comments

है puकुछ के लिए खड़े हो?

— जैस ब्राउनिंग

@JaceBrowning: मेरा मानना ​​है कि यह "प्रस्तावित अपडेट" के लिए है। हालांकि मेरा कोई संदर्भ नहीं है।

— जन हडेक

Answer 4

स्वीकृत उत्तर के आधार पर , मैं शाखाओं का विस्तार करने के लिए निम्नलिखित के समान शाखाओं को बनाए रखने के लिए विस्तार करने जा रहा हूं :

• master: release-*बंद होने पर विलय हो जाता है
• dogfood: से शाखाएँ master; डॉगफूडिंग के दौरान पहचाने गए सुधार शामिल हैं; मर्ज developतब होता है जब सॉफ़्टवेयर को आंतरिक उपयोग के लिए "स्थिर" माना जाता है; यदि आवश्यक हो तो इस शाखा के प्रमुख को समय पर वापस ले जाया जा सकता है
• develop: से शाखाएँ master; इसमें चल रहे परिवर्तन, बगफिक्स, dogfoodऔर feature-*शाखाओं और मर्ज शामिल हैं
• feature-*: से शाखाएँ develop; एक विशेष नई सुविधा के लिए परिवर्तन शामिल हैं
• release-*: dogfoodजब सॉफ्टवेयर बाहरी उपयोग के लिए "स्थिर" होता है, तब से शाखाएं ; मर्ज करने से पहले प्रलेखन अद्यतन और मामूली बगफिक्स शामिल हैंmaster