2012-04-02 10 views
10

आप अपने वीआईपी को स्वैप करके Azure प्रबंधन पोर्टल में स्टेजिंग और उत्पादन पर्यावरण के बीच दो तैनाती आसानी से बदल सकते हैं। सेवाओं के एक स्टेजिंग संस्करण पर काम करते समय हम एक स्टेजिंग डेटाबेस का भी उपयोग करना चाहते हैं, इसलिए हम वास्तविक ग्राहक डेटा को क्लॉबरिंग करने का जोखिम नहीं उठाते हैं। हालांकि, स्टेजिंग और उत्पादन सेवाओं को स्वैप करने के बाद अब उत्पादन (और पूर्व स्टेजिंग) परिनियोजन स्पष्ट रूप से उत्पादन डेटाबेस पर काम करना चाहिए।Azure में तैनाती कैसे सेट करें ताकि वे पर्यावरण के आधार पर विभिन्न डेटाबेस का उपयोग कर सकें?

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

+0

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

उत्तर

11

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

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

हालांकि, जैसा कि मैंने पहले अनुच्छेद में उल्लिखित किया है, मुझे लगता है कि चीजों को करने का एक बेहतर तरीका है। :)

+0

+1 "स्टेजिंग स्लॉट" का विस्तार विस्तारित परीक्षण के लिए नहीं किया जाना चाहिए। यदि कोई एप्लिकेशन SSL का उपयोग करता है, तो ऐसी कुछ चीजें हो सकती हैं जो "स्टेजिंग स्लॉट" में टेस्ट करने योग्य नहीं हैं क्योंकि स्टेजिंग यूआरएल SSL प्रमाणपत्र को अमान्य बनाता है। –

2

पुन: "सेवाओं के एक स्टेजिंग संस्करण पर काम करते समय हम एक स्टेजिंग डेटाबेस का उपयोग करना चाहते हैं, इसलिए हम वास्तविक ग्राहक डेटा को पकड़ने का जोखिम नहीं उठाते हैं।" ऐसा करने के लिए एक अंतर्निहित तरीका नहीं है।

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

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

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

6

अज़ूर वेबसाइटों की हालिया रिलीज में, यहां कहानी बदल गई है। अब आप निर्दिष्ट कर सकते हैं कि कोई ऐप सेटिंग या कनेक्शन स्ट्रिंग एक "स्लॉट सेटिंग" है, जो इसे विशेष स्लॉट पर पिन कर रही है। अपनी समस्या को हल करने के लिए, आप बस प्रत्येक स्लॉट में कनेक्शन स्ट्रिंग सेट करेंगे और 'स्लॉट सेटिंग' की जांच करने के लिए सावधानी बरतेंगी।

यदि मैं अब एक सलाह देने योग्य दृष्टिकोण हूं तो मैं कम स्पष्ट हूं। डेटाबेस स्कीमा माइग्रेशन और रोलबैक बेक नहीं किया गया है, और मुझे यकीन है कि इसे सही तरीके से कैसे संभालना है। इसके अलावा केवल ऐप सेटिंग्स और कनेक्शन स्ट्रिंग इस तरह से काम करते हैं, उदाहरण के लिए, system.net।मेल सेटिंग्स को स्लॉट पर पिन नहीं किया जा सकता है। इसके लिए, आपको ऐप सेटिंग्स से मेल सर्वर जानकारी आदि प्राप्त करने के लिए कोड बदलना होगा या फिर किसी अन्य दृष्टिकोण का उपयोग करना होगा।

+0

मुझे लगता है कि यहां मिस-बेचना सिर्फ कुछ स्वैप करने की अवधारणा है यदि कुछ सही काम नहीं करता है। सबसे अच्छा यह रोलबैक स्क्रिप्ट चला रहा है, और सबसे खराब यह डेटाबेस की बहाली है। आपको स्लॉट से क्या मिल रहा है, यह आपकी सभी वेबसाइटों और वेबबॉज का एक बार अपडेट है। यदि आपके पास बहुत सारे उदाहरण हैं, तो यह एक महत्वपूर्ण तैनाती का समय हो सकता है। कोर्स, यदि आपके पास डीबी परिवर्तन नहीं है तो यह आसान है ... लेकिन यह कितनी बार होता है? – Kinetic

संबंधित मुद्दे

 संबंधित मुद्दे