मैं स्थानीय रूप से/आधार पर एक एज़ूर कार्यकर्ता की भूमिका कैसे होस्ट करूं?

Question

कुछ पृष्ठभूमि ....

हम पहली बार के लिए Azure में venturing रहे हैं और बच्चे के चरणों में यह करने के लिए कोशिश कर रहे हैं। अभी के लिए, हमारे पहले ऐप्स अनुरोधों को संसाधित करने के लिए कतारों की निगरानी करने वाले कार्यकर्ता भूमिका निभाने जा रहे हैं (जैसे ईमेल भेजना या कुछ स्क्रीन स्क्रैपिंग करना) और हम अपने ऑन-प्रिमाइसेस एमवीसी ऐप और डब्ल्यूसीएफ सेवाओं से कतारों में शामिल होंगे। हम बाद में एमवीसी ऐप और डब्ल्यूसीएफ सेवाओं को Azure में ले जाएंगे।

हमारी विकास कार्यप्रवाह अनिवार्य रूप से इस (कुछ महत्वहीन तरीकों से संशोधित) प्रकार है:

1. स्थानीय स्तर पर विकास करना और कुछ साझा सर्वर पर। स्रोत नियंत्रण में जांचें।
2. हर 15 मिनट, सर्वर बनाता है और एक "विकास" पर्यावरण के लिए तैनात निर्माण (सीआई के रूप में दोगुना हो जाता है और मामले में शामिल किया गया है हम स्थानीय के अलावा किसी अन्य "विकास" पर्यावरण को हिट करने की जरूरत है)
3. तकनीकी परीक्षक मैन्युअल सर्वर का निर्माण तैनात करने के लिए गति प्रदान आखिरी सफल "देव" टेस्ट पर्यावरण (या वैकल्पिक रूप से, पूर्व-तैनात टेस्ट बिल्ड, डेटाबेस सहित/छोड़कर) में निर्मित है।
4. तकनीकी परीक्षकों और व्यावसायिक परीक्षकों ने क्यूए पर्यावरण में अंतिम सफल "टेस्ट" निर्माण (या वैकल्पिक रूप से, पूर्व-तैनात परीक्षण निर्माण, डेटाबेस सहित/छोड़कर) को तैनात करने के लिए मैन्युअल रूप से बिल्ड सर्वर को ट्रिगर किया।
5. किसी बिंदु पर हम परिवर्तन को विलय करते हैं जो क्यूए तैनाती के लिए अनुमोदित करता है।
6. बाद में हमारे उत्पादन निर्माण सर्वर इस संस्करण को स्टेजिंग के लिए तैनात करते हैं और बाद में हमारे उत्पादन वातावरण में (हम इसे समांतर/स्वतंत्र वातावरण में एन बार होस्ट करते हैं)।

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

तो हम अपने कार्यकर्ता भूमिकाओं को ऑन-प्रिमाइज़ पर उचित तरीके से होस्ट कैसे कर सकते हैं, जहां हम वास्तव में उस कोड का परीक्षण कर रहे हैं जो Azure पर तैनात हो जाता है?

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

यह जहां हम एक दूसरे आवरण/मुखौटा आवेदन बनाने के समान कुछ करने के लिए है कि के बजाय वर्ग पुस्तकालय बुला कि यह वास्तव में संदर्भ संभव है और कार्यकर्ता की भूमिका में Run() फ़ंक्शन को कॉल?

Answer 1

क्या आपको लगता है कि Azure emulator आपकी मदद कर सकता है? वास्तविक Azure प्रदाता और एमुलेटर के बीच ये differences हैं।

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

उपयोग PowerShell अपने भूमिकाओं और whatnot कॉन्फ़िगर करने के लिए। अपने Azure एमुलेटर को this जैसे कॉन्फ़िगर करें।

Answer 2

मुखौटा दृष्टिकोण सबसे अच्छा एक को अपनाने के लिए, ईमानदार होना है।

आप तैनाती अंततः समर्थन बुनियादी ढांचे पर निर्भरता है कि उपलब्ध हो तो उसे असाधारण मुश्किल है पूरी तरह से परीक्षण जब तक आप एक समान, या तुलनीय, बुनियादी सुविधाओं के लिए तैनात करने के लिए। यह निश्चित रूप से एक Azure श्रमिक भूमिका के साथ मामला है।

बुनियादी सुविधाओं स्पर्श-बिंदुओं से अपने आवेदन के कार्यात्मक पहलुओं decoupling करके, आप यह सुनिश्चित करना कि अपने कोड एकदम सही ढंग से बर्ताव करता है आपके प्रयास खर्च कर सकते हैं साबित होता है कि मुखौटा बर्ताव करता है के रूप में यह होना चाहिए, तो आत्मविश्वास परीक्षण अंतिम संयोजन

वहाँ हमेशा इस आशय का समझौता के कुछ तत्व है जब तक आपके परीक्षण वातावरण अपने उत्पादन वातावरण के समान हैं।

और यह है कि एज़ूर स्टेजिंग परिनियोजन क्या है; उत्पादन में स्विच करने से पहले आत्मविश्वास परीक्षण का अंतिम स्तर।

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

अन्त में, और मुखौटा पैटर्न एक उदाहरण है, testability के लिए डिजाइन है। तैनाती से पहले परीक्षण की जा सकने वाली राशि को अधिकतम करने के लिए अपने कोड को फैक्टर करें और परीक्षण के बाद के चरणों में आप अपने जोखिम को कम करें।