समस्या और संदर्भ
इसे एक व्यस्त रिपॉजिटरी के लिए एक प्रोडक्ट निर्णय के रूप में देखें, न कि केवल एक फीचर चालू करने के अनुरोध के रूप में। GitHub एक मर्ज कतार को नवीनतम लक्ष्य ब्रांच और कतारबद्ध पुल रिक्वेस्ट्स पर एक पुल रिक्वेस्ट लागू करने, और फिर कॉन्फ़िगर किए गए स्टेटस चेक पास करने की आवश्यकता के रूप में वर्णित करता है। इसलिए, यह निर्णय फीडबैक समय, कंप्यूट लागत, रिलीज सुरक्षा और योगदानकर्ता की स्वायत्तता को प्रभावित करता है।
मान लें कि टीम ब्रांच सुरक्षा की स्वामी है, पुल-रिक्वेस्ट इवेंट्स को इंस्ट्रूमेंट कर सकती है, और उसके पास दो सप्ताह के नियंत्रित पायलट का समय है। लक्ष्य लेखकों को अनिश्चित काल तक प्रतीक्षा कराए बिना डिफ़ॉल्ट-ब्रांच के टूटे हुए बिल्ड को कम करना है।
इंटरव्यूअर क्या मूल्यांकन करते हैं
मजबूत उत्तर उपयोगकर्ता की समस्या को एक मापने योग्य हस्तक्षेप से जोड़ते हैं। वे हर विफलता को कतार की समस्या मानने के बजाय मर्ज कॉन्फ्लिक्ट्स, अस्थिर (flaky) चेक, धीमे चेक और जोखिम भरे रिलीज को अलग-अलग वर्गीकृत करते हैं। वे प्रभावित उपयोगकर्ताओं, बेसलाइन मेट्रिक्स, गार्डरेल्स, एक पायलट कोहोर्ट और एक रोलबैक ट्रिगर का उल्लेख करते हैं।
एक साधारण उत्तर में "कतार सक्षम करें और CI की निगरानी करें" की सूची होती है। एक मजबूत उत्तर बताता है कि कौन सी रिपॉजिटरी योग्य हैं, कतार बैच स्टेटस-चेक लोड को कैसे बदलते हैं, और जब कोई काल्पनिक (speculative) बैच विफल हो जाता है तो डेवलपर्स को कार्रवाई योग्य फीडबैक कैसे मिलता है।
पहले स्पष्ट करने योग्य प्रश्न
- क्या मुख्य समस्या विफल मर्ज, कॉन्फ्लिक्ट समाधान, टूटा हुआ main, या रिलीज की घटनाएं हैं? प्रत्येक एक अलग प्रोडक्ट हस्तक्षेप की ओर संकेत करता है।
- क्या आवश्यक चेक दोहराए जाने वाले कतार रनों के लिए नियतात्मक (deterministic) और पर्याप्त रूप से समानांतर हैं? अस्थिर (flaky) चेक कतार के शोर को बढ़ा सकते हैं।
- अनुमोदन (approval) से मर्ज तक का सहन करने योग्य p95 समय क्या है, और कौन सी टीमें उस देरी को स्वीकार नहीं कर सकती हैं?
- क्या हमें एक मोनोरेपो के लिए एक कतार की आवश्यकता है, या स्वतंत्र स्वामित्व वाले क्षेत्रों के लिए अलग-अलग कतारों की?
- क्या मेंटेनर्स कतार को रोक सकते हैं और एक ऑडिटेड अपवाद के तहत आपातकालीन सुधार को मर्ज कर सकते हैं?
यदि बेसलाइन से पता चलता है कि अधिकांश विफलताएं अस्थिर टेस्ट हैं, तो लॉन्च करने से पहले उन टेस्ट को स्थिर करें। यदि विफलताएं अनुमोदन और मर्ज के बीच आने वाले परिवर्तनों से होती हैं, तो एक कतार अधिक सीधे तौर पर प्रासंगिक है।
एक 30-सेकंड का उत्तर
"मैं सबसे पहले टूटे हुए main के मिनट, कॉन्फ्लिक्ट पर दोबारा काम, कतार प्रतीक्षा समय, अस्थिर-चेक दर और CI लागत को मापूँगा। मैं नियतात्मक आवश्यक जांचों वाली एक उच्च-मात्रा वाली रिपॉजिटरी का चयन करूँगा, एक p95 मर्ज-समय और विफलता-दर गार्डरेल परिभाषित करूँगा, और एक पॉज़ स्विच के साथ दो-सप्ताह का पायलट चलाऊँगा। मैं इसकी तुलना एक समान रिपॉजिटरी या पायलट-पूर्व बेसलाइन से करूँगा, परिवर्तन आकार और टीम द्वारा परिणामों को विभाजित करूँगा, और कतार को केवल तभी बनाए रखूँगा जब यह प्रतीक्षा-समय या लागत सीमाओं का उल्लंघन किए बिना एकीकरण विफलताओं को कम करती है।"
चरण-दर-चरण निर्णय
- कार्य का निदान करें। हाल के पुल रिक्वेस्ट्स से विफलता वर्गीकरण (taxonomy) बनाएं: कॉन्फ्लिक्ट, परिवर्तन के कारण टेस्ट विफलता, बेस ब्रांच के कारण टेस्ट विफलता, फ्लेक, टाइमआउट और नीति अस्वीकृति।
- एक निर्णय सीमा (threshold) निर्धारित करें। उदाहरण के लिए, टूटे हुए main के मिनटों में 30% की कमी, अनुमोदन-से-मर्ज के p95 समय में 10% से अधिक की वृद्धि न होना, और एक सीमित CI-लागत वृद्धि की आवश्यकता होना।
- पायलट डिज़ाइन करें। प्रभावों का निरीक्षण करने के लिए पर्याप्त थ्रूपुट वाली एक रिपॉजिटरी चुनें, आवश्यक चेक को पिन करें, आपातकालीन बाईपास का दस्तावेजीकरण करें, और घोषणा करें कि कतार की स्थिति और विफलताएं कैसे दिखाई जाएंगी।
- बैचिंग को मॉडल करें। GitHub की कतार नवीनतम बेस और कतारबद्ध परिवर्तनों के विरुद्ध परिवर्तनों का मूल्यांकन करती है। अतिरिक्त चेक निष्पादन, कैश हिट दर और समवर्तीता (concurrency) का अनुमान लगाएं ताकि पायलट असंबंधित बिल्ड को संसाधनों से वंचित न करे।
- फीडबैक को इंस्ट्रूमेंट करें। कतार में शामिल होने का समय, कतार से बाहर निकलने का कारण, बैच संरचना, चेक अवधि, विफलता का मालिक, पुनः प्रयास (retries) और कार्रवाई योग्य निदान का समय ट्रैक करें। एक विफल बैच को जब संभव हो तो सबसे छोटे संदिग्ध सेट की पहचान करनी चाहिए।
- समीक्षा करें और रोल बैक करें। बेसलाइन या नियंत्रण के विरुद्ध तुलना करें, टीम द्वारा आउटलेयर्स का निरीक्षण करें, और यदि प्रतीक्षा समय, फ्लेक प्रवर्धन, या आपातकालीन डिलीवरी गार्डरेल से अधिक हो जाती है तो कतार को रोक दें।
विकल्पों में बेहतर ब्रांच-अपडेट रिमाइंडर, मर्ज-कॉन्फ्लिक्ट ऑटोमेशन, तेज़ चेक, एक रिलीज़-ट्रेन ताल, या केवल ब्रांचों के एक छोटे सेट की सुरक्षा करना शामिल है। कतार तब मूल्यवान होती है जब एकीकरण का क्रम मुख्य जोखिम होता है।
उदाहरण उत्तर
"मैं इसे एक सार्वभौमिक डिफ़ॉल्ट के रूप में शिप नहीं करूँगा। मैं हमारी सबसे व्यस्त सेवा रिपॉजिटरी से शुरुआत करूँगा क्योंकि इसमें बार-बार बेस-ब्रांच रिग्रेशन होते हैं और विश्वसनीय चेक होते हैं। दो-सप्ताह के पायलट के दौरान मैं टूटे हुए main के मिनट, p95 अनुमोदन-से-मर्ज, कतार परित्याग, अस्थिर-चेक दर और चेक-कंप्यूट घंटे रिकॉर्ड करूँगा। सफलता का अर्थ होगा कम से कम 30% कम टूटे-main मिनट, 20 मिनट से कम का p95 प्रतीक्षा समय, और 15% से अधिक अतिरिक्त कंप्यूट नहीं। मैं कतार की स्थिति, विफलता का स्वामित्व और एक पॉज़ नियंत्रण को उजागर करूँगा। यदि कतार मुख्य रूप से फ्लेक्स का पुनः प्रयास करती है या तत्काल सुधारों को रोकती है, तो मैं इसे रोक दूँगा और इसके बजाय टेस्ट विश्वसनीयता या तेज़ जांच में निवेश करूँगा।"
सामान्य गलतियाँ
- त्रुटि: प्रत्येक विफल चेक को कतार के प्रमाण के रूप में मानना → यह विफल क्यों होता है: फ्लेक्स और धीमे टेस्ट मूल कारण बने रहते हैं → समाधान: विफलताओं को वर्गीकृत करें और पूर्व-शर्तें निर्धारित करें।
- त्रुटि: केवल मर्ज की शुद्धता को अनुकूलित करना → यह विफल क्यों होता है: योगदानकर्ताओं को छिपी हुई प्रतीक्षा और अस्पष्ट विफलताओं का अनुभव होता है → समाधान: p95 प्रतीक्षा और निदान-समय गार्डरेल्स शामिल करें।
- त्रुटि: बैच कंप्यूट को अनदेखा करना → यह विफल क्यों होता है: बार-बार काल्पनिक चेक रनर्स को समाप्त कर सकते हैं → समाधान: रोलआउट से पहले समवर्तीता, कैशिंग और लागत को मॉडल करें।
- त्रुटि: कोई आपातकालीन मार्ग न देना → यह विफल क्यों होता है: घटनाएं असुरक्षित बाईपास बनाती हैं → समाधान: एक ऑडिट की गई पॉज़ या अपवाद प्रक्रिया को परिभाषित करें।
फॉलो-अप प्रश्न और उत्तर
क्या होगा यदि कतार टूटे-main समय को कम करती है लेकिन CI लागत को दोगुना कर देती है?
परिणाम को सशर्त रखें। चयनात्मक कतारों, मजबूत कैशिंग, या संकीर्ण आवश्यक जांचों का परीक्षण करें, फिर बचाए गए टूटे-main मिनट के प्रति लागत की तुलना करें। पायलट को तब तक सफल न कहें जब तक कि सहमत लागत सीमा का सम्मान न किया जाए।
आप एक अस्थिर (flaky) आवश्यक चेक को कैसे संभालेंगे?
फ्लेक दर को लॉन्च गेट के रूप में चिह्नित करें, चेक को क्वारंटाइन या मरम्मत करें, और पुनः प्रयासों को दृश्यमान बनाएं। चुपचाप पुनः प्रयास करने से थ्रूपुट बना रह सकता है लेकिन संकेत में विश्वास नष्ट हो जाता है।
एक टीम का कहना है कि कतार एक तत्काल सुधार को प्रतीक्षा कराती है। क्या बदलाव होंगे?
समीक्षक अनुमोदन, ऑडिट इवेंट्स और एक फॉलो-अप मर्ज के साथ एक प्रलेखित आपातकालीन मार्ग जोड़ें। अपवाद आवृत्ति को मापें; एक उच्च दर दर्शाती है कि कतार नीति या विभाजन गलत है।
आप रोलआउट को स्थायी रूप से कब रोकेंगे?
तब रोकें जब उचित ट्यूनिंग के बाद p95 प्रतीक्षा या परित्याग गार्डरेल से ऊपर बना रहे, जब कतार विफलताओं का निदान नहीं किया जा सके, या जब तेज़ चेक और ब्रांच ऑटोमेशन के माध्यम से समान परिणाम सस्ता हो।