बैकएंड इंटरव्यू: माइक्रोसर्विस API को सुरक्षित रूप से रिलीज़ करने के लिए आप कंज्यूमर-ड्रिवन कॉन्ट्रैक्ट टेस्टिंग का उपयोग कैसे करेंगे?

प्रॉम्प्ट और दायरा

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

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

इंटरव्यूअर क्या टेस्ट कर रहा है

• क्या कंज्यूमर का व्यवहार प्रोवाइडर कार्यान्वयन की प्रतिलिपि बनने के बजाय एक न्यूनतम इंटरैक्शन कॉन्ट्रैक्ट बनता है।
• क्या आप मॉक कंज्यूमर टेस्ट्स, प्रोवाइडर वेरिफिकेशन, एक ब्रोकर और एक डिप्लॉयमेंट मैट्रिक्स को जोड़ सकते हैं।
• क्या प्रोवाइडर स्टेट्स साझा-डेटाबेस क्रम या प्रोडक्शन क्रेडेंशियल्स के बिना पूर्व-शर्तों को अलग (आइसोलेट) करते हैं।
• क्या आप एकाधिक कंज्यूमर वर्शन्स, असत्यापित कॉन्ट्रैक्ट्स, मैसेज कॉन्ट्रैक्ट्स और रोलबैक को संभालते हैं।

पहले स्पष्ट करने योग्य प्रश्न

1. क्या इंटरफ़ेस HTTP है, एसिंक्रोनस मैसेजिंग है, या दोनों? कॉन्ट्रैक्ट कैरियर अलग होता है।
2. कंज्यूमर्स वास्तव में किन फ़ील्ड्स का उपयोग करते हैं? कॉन्ट्रैक्ट में आवश्यक अनुरोधों और न्यूनतम प्रतिक्रियाओं को व्यक्त किया जाना चाहिए।
3. क्या प्रोवाइडर स्टेट्स टेस्ट डेटा बना सकते हैं, साफ़ कर सकते हैं और पैरामीटराइज़ कर सकते हैं? किन निर्भरताओं (डिपेंडेंसीज़) को स्टब करने की आवश्यकता है?
4. वर्शन्स की पहचान कैसे की जाती है, और प्रोडक्शन से पहले किन कंज्यूमर/प्रोवाइडर संयोजनों को पास होना आवश्यक है?
5. क्या कोई ब्रोकर, ब्रांच टैगिंग, पेंडिंग-पैक्ट पॉलिसी और रोलबैक रणनीति मौजूद है?

30-सेकंड उत्तर का ढांचा

कंज्यूमर्स एक Pact मॉक के विरुद्ध इंटरैक्शन टेस्ट लिखते हैं, जिससे केवल आवश्यक अनुरोध और प्रतिक्रिया असर्शन वाला एक कॉन्ट्रैक्ट तैयार होता है; वे इसे एक ब्रोकर पर पब्लिश करते हैं। एक प्रोवाइडर वेरिफ़ायर लक्षित कंज्यूमर वर्शन्स का चयन करता है, प्रोवाइडर स्टेट्स सेट करता है, एक अलग (आइसोलेटेड) वातावरण में अनुरोधों को रिप्ले करता है और परिणाम पब्लिश करता है। CI डिप्लॉयमेंट गेट वास्तविक वर्शन मैट्रिक्स की जाँच करता है; एक नया अनवेरिफ़ाइड कॉन्ट्रैक्ट पेंडिंग रह सकता है या रिलीज़ को ब्लॉक कर सकता है। कॉन्ट्रैक्ट्स मैसेज के आकार और इंटरैक्शन को साबित करते हैं, पूरी व्यावसायिक शुद्धता को नहीं। विफलता पर, डिप्लॉयमेंट रोकें, प्रोवाइडर को ठीक करें, या मैट्रिक्स पास करने वाले वर्शन पर रोलबैक करें।

चरण-दर-चरण उत्तर

1. कंज्यूमर व्यवहार से इंटरैक्शन परिभाषित करें

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

consumer test -> pact file -> broker
provider verifier + provider state -> replay -> verification result
deployment gate -> compatible version matrix -> deploy or block

2. कॉन्ट्रैक्ट को न्यूनतम और स्थिर रखें

अप्रयुक्त रिस्पॉन्स फ़ील्ड्स, रैंडम IDs, या पूरे डेटाबेस स्नैपशॉट पर असर्शन न करें। प्रकारों (types), प्रारूपों (formats) और आवश्यक संरचना के लिए मैचर्स का उपयोग करें; केवल डायनामिक टाइमस्टैम्प और UUIDs के आकार (shape) को मान्य करें। कॉन्ट्रैक्ट टेस्ट्स सामान्य प्रोवाइडर कार्यक्षमता पर नहीं, बल्कि कम्युनिकेशन मैसेजेस पर ध्यान केंद्रित करते हैं।

3. प्रोवाइडर स्टेट्स डिज़ाइन करें

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

4. ब्रोकर में वर्शन्स और वेरिफिकेशन प्रबंधित करें

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

5. रोलआउट क्रम और कम्पैटिबिलिटी विंडो चुनें

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

6. विफलता को संभालें और प्रोडक्शन का निरीक्षण करें

विफल इंटरैक्शन, प्रोवाइडर स्टेट, वर्शन्स, कमिट SHA और एनवायरनमेंट को रिकॉर्ड करें। डिप्लॉयमेंट को ब्लॉक करें और मैट्रिक्स पास करने वाले अंतिम वर्शन पर रोलबैक करें; रिलीज़ के बाद, 4xx/5xx, डीसैरियलाइज़ेशन एरर्स, डेड लेटर्स और व्यावसायिक मेट्रिक्स पर नज़र रखें। ग्रीन कॉन्ट्रैक्ट टेस्ट्स प्रोडक्शन की शुद्धता साबित नहीं करते हैं, इसलिए रनटाइम सुरक्षा बनाए रखें।

उच्च-गुणवत्ता वाला नमूना उत्तर

प्रत्येक कंज्यूमर एक Pact मॉक के विरुद्ध वास्तविक इंटरैक्शन लिखेगा, जिससे केवल आवश्यक अनुरोधों और न्यूनतम प्रतिक्रियाओं वाला एक कॉन्ट्रैक्ट तैयार होगा और इसे एक ब्रोकर पर पब्लिश किया जाएगा। प्रोवाइडर वेरिफ़ायर कंज्यूमर वर्शन्स का चयन करता है, आइसोलेशन में दोहराए जाने योग्य (रिपीटेबल) प्रोवाइडर स्टेट्स चलाता है, अनुरोधों को रिप्ले करता है, और प्रोवाइडर वर्शन और कमिट SHA के साथ परिणाम पब्लिश करता है। CI गेट जाँच करता है कि क्या एक साथ चलने वाले कंज्यूमर/प्रोवाइडर वर्शन्स के पास वेरिफिकेशन का प्रमाण है; पेंडिंग पैक्ट्स पुराने प्रोवाइडर को तुरंत तोड़े बिना एक नए कॉन्ट्रैक्ट को वेरिफ़ाई करने की अनुमति देते हैं।

कॉन्ट्रैक्ट कम्युनिकेशन के आकार और उपयोग किए गए फ़ील्ड्स को कवर करता है, सभी यूनिट, इंटीग्रेशन, एंड-टू-एंड या व्यावसायिक टेस्ट्स को नहीं। राइटर्स को ब्रेक करने से पहले रीडर्स को रोल आउट करें: प्रोवाइडर को पुराने अनुरोधों और प्रतिक्रियाओं के साथ संगत रखें, फिर कंज्यूमर्स को माइग्रेट करें; ब्रेकिंग बदलावों के लिए वर्शन्ड पाथ्स या डुअल-राइट विंडो का उपयोग करें। विफलता पर, रिलीज़ को ब्लॉक करें और रनटाइम एरर, डेड-लेटर और व्यावसायिक मेट्रिक्स को बनाए रखते हुए अंतिम पासिंग मैट्रिक्स पर वापस लौटें। मैसेज पैक्ट्स मैसेज सामग्री को कवर करते हैं, जबकि मैसेज ब्रोकर सेमांटिक्स के लिए अलग टेस्ट्स की आवश्यकता होती है।

सामान्य विफलता मोड (गलतियाँ)

• कॉन्ट्रैक्ट को एक पूर्ण प्रोवाइडर रिस्पॉन्स स्नैपशॉट बनाना ताकि असंबंधित फ़ील्ड्स रिलीज़ को ब्लॉक कर दें।
• केवल कंज्यूमर मॉक्स चलाना और प्रोवाइडर के विरुद्ध कॉन्ट्रैक्ट को कभी रिप्ले न करना।
• प्रोवाइडर स्टेट्स को साझा डेटाबेस क्रम, रैंडम डेटा या प्रोडक्शन क्रेडेंशियल्स पर निर्भर बनाना।
• केवल नवीनतम (latest) वर्शन की जाँच करना और वास्तविक डिप्लॉयमेंट मैट्रिक्स और लॉन्ग-टेल क्लाइंट्स को छोड़ देना।
• Pact को एंड-टू-एंड टेस्टिंग मानना और वास्तविक ब्रोकर, ऑथराइजेशन, परफॉर्मेंस और व्यावसायिक नियमों की अनदेखी करना।
• वेरिफिकेशन विफलता के बाद डिप्लॉय करना या वेरिफ़िएबल रोलबैक वर्शन का अभाव होना।

फ़ॉलो-अप प्रश्न और संदर्भ उत्तर

रिस्पॉन्स अपेक्षाओं को न्यूनतम क्यों रखें?

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

प्रोवाइडर स्टेट एक टेस्ट फिक्सचर से किस प्रकार भिन्न है?

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

पेंडिंग पैक्ट किस समस्या का समाधान करता है?

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

आप कॉन्ट्रैक्ट के अनियंत्रित फैलाव (sprawl) को कैसे रोकते हैं?

वास्तविक कंज्यूमर इंटरैक्शन को डुप्लीकेट होने से बचाएं, पुराने वर्शन्स को रिटायर करें, रैंडम फ़ील्ड्स और पूर्ण स्नैपशॉट्स को सीमित करें, और ब्रोकर में ओनर, वर्शन और अंतिम वेरिफिकेशन समय रिकॉर्ड करें।

कंज्यूमर वर्शन का चयन क्यों मायने रखता है?

गेट को उन वर्शन्स को वेरिफ़ाई करना चाहिए जो एक साथ चलेंगे। केवल main या latest की जाँच करने से कोई पुराना मोबाइल या ब्रांच वर्शन छूट सकता है जो अभी भी प्रोडक्शन में है।

क्या Pact प्रोवाइडर की व्यावसायिक शुद्धता साबित कर सकता है?

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