Zapier या Make ऑटोमेशन को नए जियोकोडिंग होस्ट पर माइग्रेट करना
जियोकोडिंग चरण पर बने नो-कोड ऑटोमेशन के लिए कस्टम कोड से अलग माइग्रेशन तरीका चाहिए। यह बदलाव कैसे संभालें, यहाँ बताया गया है।
कुछ भी माइग्रेट करने से पहले रोलबैक की योजना बनाना
रोलबैक योजना माइग्रेशन का वह हिस्सा है जिसे, अगर अच्छी तरह किया जाए, तो किसी को कभी उपयोग करने की ज़रूरत नहीं पड़ती, और ठीक इसी वजह से समय कम होने पर इसे अक्सर छोड़ दिया जाता है। इसे छोड़ना ख़ास तौर पर इसलिए ग़लती है क्योंकि रोलबैक की ज़रूरत पड़ने पर उसके न होने की कीमत, ऐसी योजना तैयार करने की कीमत से कहीं ज़्यादा है जो कभी उपयोग न हो।
एक अच्छी रोलबैक योजना की शुरुआती धारणा यह है कि नया प्रदाता कम से कम एक ऐसे तरीके से पुराने से अलग व्यवहार करेगा जिसका आपने अनुमान नहीं लगाया था, चाहे आपने पहले कितनी भी गहराई से टेस्ट किया हो। यह निराशावाद नहीं है, बल्कि बाहरी सिस्टम के साथ इंटीग्रेशन आम तौर पर कैसे चलते हैं, इसका एक ईमानदार विवरण है। इस उम्मीद के बजाय कि टेस्टिंग ने सब कुछ पकड़ लिया, इस धारणा को ध्यान में रखकर योजना बनाने से बेहतर योजना बनती है।
स्थान डेटा प्रदाता बदलने की रोलबैक योजना में ये बातें शामिल होनी चाहिए:
- तेज़ स्विच करने का तरीका। चाहे वह फ़ीचर फ़्लैग हो, एनवायरनमेंट वेरिएबल हो, या डिप्लॉय किए गए बिल्ड में जड़े जाने के बजाय अनुरोध के समय पढ़ा जाने वाला कॉन्फ़िगरेशन मान, पुराने प्रदाता के क्रेडेंशियल और एंडपॉइंट कटओवर के बाद एक तय अवधि तक वैध रहने चाहिए और कोड डिप्लॉयमेंट के बिना फिर से उपयोग के लिए तैयार रहने चाहिए
- स्पष्ट ट्रिगर शर्त। पहले से तय करें कि ठीक-ठीक किस बात पर रोलबैक उचित होगा: किसी सीमा से ऊपर की त्रुटि दर, अनुरोधों की कोई ख़ास श्रेणी विफल होना, या उपयोगकर्ता शिकायतों की एक निश्चित संख्या, बजाय इसके कि निर्णय दबाव में बिना किसी सहमत मानदंड के लिया जाए
- रोलबैक का ज़िम्मेदार। एक व्यक्ति या एक छोटा समूह जो रोलबैक का निर्णय लेने के लिए स्पष्ट रूप से ज़िम्मेदार हो, ताकि निर्णय इसलिए न अटके कि कई लोग किसी और के फ़ैसला करने का इंतज़ार कर रहे हैं
- रोलबैक अवधि की तय समाप्ति। दोनों प्रदाताओं के क्रेडेंशियल अनिश्चित काल तक सक्रिय रखना माइग्रेट करने का उद्देश्य ही ख़त्म कर देता है; एक निश्चित तारीख़ तय करें जिसके बाद पुराने प्रदाता की पहुँच हमेशा के लिए बंद कर दी जाए
क्योंकि My Geocode के कम्पैटिबिलिटी होस्ट किसी प्रदाता के अनुरोध और रिस्पॉन्स का ठीक वही ढाँचा दोहराते हैं, इसलिए कम्पैटिबिलिटी-आधारित माइग्रेशन में रोलबैक अक्सर बस पुराने होस्ट और कुंजी पर वापस जाने वाला एक कॉन्फ़िगरेशन बदलाव होता है, जिसमें अलग पार्सिंग कोड फिर से डिप्लॉय करने की ज़रूरत नहीं होती। इससे ज़रूरत पड़ने पर रोलबैक लागू करने में लगने वाला समय घट जाता है। फिर भी, यह बात दोनों तरफ़ लागू होती है: इसका मतलब यह भी है कि योजना के चरण में एक बार सोच-समझकर यह टेस्ट करना सार्थक है कि रोलबैक काम करता है, न कि बस यह मान लेना, क्योंकि बिना टेस्ट किया गया रोलबैक रास्ता रोलबैक योजना के न होने से ज़्यादा अलग नहीं है।
यह तय करना भी सार्थक है कि जिस अवधि से आप रोलबैक कर रहे हैं, उसके दौरान प्रोसेस हुए डेटा या अनुरोधों का क्या होगा। अगर कोई बैच जॉब रात भर नए प्रदाता पर चला और अगली सुबह किसी समस्या का पता चला, तो क्या उस बैच को फिर से प्रोसेस करना होगा, या यह अंतर स्वीकार्य है। किसी वास्तविक घटना के दौरान के बजाय पहले से यह तय कर लेने से पहले से ही तनावपूर्ण क्षण में एक निर्णय कम हो जाता है।
जो माइग्रेशन योजना केवल आगे बढ़ने का वर्णन करती है, वह वास्तविक अर्थ में एक अधूरी योजना है। रोलबैक वाला आधा हिस्सा ही माइग्रेशन को एकतरफ़ा दाँव से एक सोचा-समझा निर्णय बनाता है, जिसे सबूत की माँग होने पर साफ़ तरीके से पलटा जा सकता है।