Zapier या Make ऑटोमेशन को नए जियोकोडिंग होस्ट पर माइग्रेट करना
जियोकोडिंग चरण पर बने नो-कोड ऑटोमेशन के लिए कस्टम कोड से अलग माइग्रेशन तरीका चाहिए। यह बदलाव कैसे संभालें, यहाँ बताया गया है।
दो प्रोवाइडर साथ-साथ चलाने के लिए एक चेकलिस्ट
एक ही समय पर दो प्रोवाइडर चलाना आमतौर पर माइग्रेशन के दौरान एक सोची-समझी, अस्थायी स्थिति होती है, कोई स्थायी आर्किटेक्चर नहीं, लेकिन इसे इतनी संरचना चाहिए कि यह कोडबेस में बिखरे कंडीशनल लॉजिक का उलझा हुआ ढेर न बन जाए। एक चेकलिस्ट इस चरण को छोटा और इसका उद्देश्य साफ़ रखने में मदद करती है।
दूसरे प्रोवाइडर को असली ट्रैफ़िक भेजना शुरू करने से पहले:
- पुष्टि करें कि दोनों प्रोवाइडर के रिस्पॉन्स की संरचना को एक साझा आंतरिक डेटा संरचना से मैप कर लिया गया है, ताकि आपका एप्लिकेशन कोड एक ही नॉर्मलाइज़्ड फ़ॉर्मेट से पढ़े, चाहे किसी अनुरोध का जवाब असल में किसी भी प्रोवाइडर ने दिया हो
- बँटवारे का लॉजिक पहले से तय करें: ट्रैफ़िक का प्रतिशत, खास एंडपॉइंट, खास ग्राहक समूह, या एक शैडो मोड जिसमें दूसरे प्रोवाइडर को कॉल किया जाता है लेकिन उसका परिणाम केवल लॉग होता है, इस्तेमाल नहीं होता
- अलग लॉगिंग या टैगिंग सेट अप करें ताकि बाद में आप बता सकें कि किसी भी अनुरोध को किस प्रोवाइडर ने संभाला, जो तब बहुत मायने रखता है जब कुछ गलत हो जाए और आपको जानना हो कि सबसे पहले कहाँ देखना है
जब दोनों प्रोवाइडर लाइव हों:
- दोनों के बीच एरर दर और रिस्पॉन्स समय की तुलना नियमित अंतराल पर करें, सिर्फ़ शुरुआत में एक बार नहीं, क्योंकि व्यवहार दिनों या हफ़्तों में ऐसे तरीकों से बदल सकता है जिन्हें एक शुरुआती टेस्ट पकड़ नहीं पाएगा
- एक ही इनपुट पर दोनों प्रोवाइडर के असली परिणामों में अंतर पर नज़र रखें, और जब वे असहमत हों तब क्या करना है, इसके लिए एक स्पष्ट निर्णय प्रक्रिया रखें, बजाय यह मान लेने के कि कोई एक बस सही है
- ऐसे हर अनुरोध पैटर्न का नोट बनाते रहें जो दोनों के बीच साफ़ तौर पर अलग व्यवहार करता है, क्योंकि ठीक यही वे मामले हैं जिन्हें पुराने प्रोवाइडर को हटाने से पहले और गहराई से टेस्ट करना चाहिए
मूल प्रोवाइडर को हटाने से पहले:
- पुष्टि करें कि पुराने प्रोवाइडर को कॉल कर सकने वाले हर कोड पाथ को नए प्रोवाइडर के साथ वाकई चलाकर देखा गया है, सिर्फ़ आम मामलों को नहीं
- ऐसे किसी भी हार्डकोडेड फ़ॉलबैक लॉजिक की जाँच करें जो मानता है कि पुराना प्रोवाइडर हमेशा उपलब्ध है, क्योंकि दो प्रोवाइडर वाली अवधि कभी-कभी ऐसा फ़ॉलबैक कोड छोड़ जाती है जिसे हटाना किसी को याद नहीं रहता
- दो प्रोवाइडर वाली अवधि को अनिश्चित काल तक खिंचने देने के बजाय पुराने प्रोवाइडर को बंद करने की एक तय तारीख रखें, क्योंकि बिना अंत वाला बदलाव अक्सर कभी पूरा नहीं होता
My Geocode के कम्पैटिबिलिटी होस्ट खास तौर पर इसलिए बनाए गए हैं कि इस प्रक्रिया का पहला आधा हिस्सा, यानी रिस्पॉन्स संरचना का नॉर्मलाइज़ेशन, ज़्यादातर गैर-ज़रूरी हो जाए, अगर जिस प्रोवाइडर से आप माइग्रेट कर रहे हैं उसके लिए पहले से मेल खाता होस्ट मौजूद है, क्योंकि संरचना मूल जैसी ही रहती है और आपका मौजूदा नॉर्मलाइज़ेशन कोड (अगर आपके पास पहले से कोई था) बिना बदलाव के काम करता रहता है। सभी 17 कम्पैटिबिलिटी होस्ट की पूरी सूची /compatibility/ पर है। हर अनुरोध के साथ कोटा हेडर भी आते हैं, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining और अन्य, जिनका दस्तावेज़ /docs/rate-limits/ पर है, और ये ऊपर बताए गए तुलनात्मक लॉगिंग चरण के लिए उपयोगी हैं, चाहे दूसरे प्रोवाइडर के रूप में किसी का भी मूल्यांकन हो रहा हो।
अच्छी तरह से चलाई गई दो प्रोवाइडर वाली अवधि छोटी होती है, अच्छी तरह मॉनिटर की जाती है और एक तय तारीख पर खत्म होती है। खराब तरीके से चलाई जाए, तो यह एक स्थायी और उलझन भरा हिस्सा बन जाती है। फ़र्क लगभग पूरी तरह इसी बात में है कि ऐसी चेकलिस्ट का पालन किया जाता है या समय के दबाव में उसे छोड़ दिया जाता है।