Zapier या Make ऑटोमेशन को नए जियोकोडिंग होस्ट पर माइग्रेट करना
जियोकोडिंग चरण पर बने नो-कोड ऑटोमेशन के लिए कस्टम कोड से अलग माइग्रेशन तरीका चाहिए। यह बदलाव कैसे संभालें, यहाँ बताया गया है।
माइग्रेशन के दौरान रिस्पॉन्स स्कीमा के अंतरों को संभालना
सबसे सावधानी से चुना गया वैकल्पिक प्रोवाइडर भी मूल प्रोवाइडर से कम से कम कुछ छोटी बातों में अलग होगा, और इन अंतरों को प्रोडक्शन में सामने आने से पहले खोजना, किसी ग्राहक के कुछ गलत होने की शिकायत के बाद उन्हें खोजने से बिल्कुल अलग काम है। स्कीमा की तुलना का एक व्यवस्थित तरीका इनमें से ज़्यादातर अंतरों को जल्दी, सस्ते में और बिना किसी हंगामे के पकड़ लेता है।
शुरुआत के लिए उपयोगी बात है अंतर की तीन श्रेणियों में फ़र्क करना, क्योंकि हर एक के लिए अलग प्रतिक्रिया चाहिए:
फ़ील्ड की मौजूदगी के अंतर। जो फ़ील्ड आपका कोड पढ़ता है, वह एक प्रोवाइडर के रिस्पॉन्स में मौजूद हो सकता है और दूसरे में गायब, या सिर्फ़ कुछ शर्तों में मौजूद। स्टैटिक तुलना से पकड़ने में यह सबसे आसान श्रेणी है: एक ही इनपुट के लिए हर प्रोवाइडर से एक सैंपल रिस्पॉन्स लें और फ़ील्ड की सूचियों का सीधे diff करें।
फ़ील्ड के प्रकार या फ़ॉर्मैट के अंतर। एक ही वैचारिक वैल्यू अलग तरह से दर्शाई जा सकती है, जैसे निर्देशांक दो अलग संख्यात्मक फ़ील्ड के रूप में बनाम एक संयुक्त स्ट्रिंग, कॉन्फ़िडेंस स्कोर 0 और 1 के बीच की संख्या के रूप में बनाम एक श्रेणी ("high", "medium", "low"), या टाइमस्टैम्प पूरी तरह अलग फ़ॉर्मैट में। इन्हें पकड़ने के लिए सिर्फ़ फ़ील्ड के नाम नहीं, बल्कि वास्तविक वैल्यू पढ़नी पड़ती हैं।
एक जैसे फ़ील्ड नाम वाले अर्थगत अंतर। यह सबसे कठिन श्रेणी है, जिसमें दो प्रोवाइडर बिल्कुल एक ही फ़ील्ड नाम का उपयोग करते हैं लेकिन उससे थोड़ी अलग बातें मतलब रखते हैं, जैसे "accuracy" फ़ील्ड, जिसे एक प्रोवाइडर पते के घटकों के मिलान के आधार पर स्कोर करता है और दूसरा पूरी तरह अलग आंतरिक पद्धति के आधार पर। सिर्फ़ फ़ील्ड नामों पर आधारित तुलना इसे नहीं पकड़ेगी; इसके लिए यह समझना ज़रूरी है कि हर सिस्टम में कोई वैल्यू वास्तव में क्या दर्शाती है, आम तौर पर यह मानने के बजाय कि एक जैसे नाम का मतलब एक जैसा अर्थ है, दोनों प्रोवाइडर के दस्तावेज़ ध्यान से पढ़कर।
एक व्यावहारिक प्रक्रिया: वास्तविक ऐतिहासिक अनुरोधों का एक प्रतिनिधि सैंपल लें, जिसमें आदर्श रूप से कम से कम आपके सबसे आम अनुरोध पैटर्न और आपकी जानी-पहचानी पेचीदा खास स्थितियाँ शामिल हों, उन्हें पुराने और नए दोनों प्रोवाइडर पर चलाएँ, और कुछ उदाहरणों को सरसरी नज़र से देखने के बजाय परिणामों का व्यवस्थित रूप से diff करें। इस तुलना को ऑटोमेट करना, भले ही एक सरल स्क्रिप्ट के रूप में जो हर संरचनात्मक या महत्वपूर्ण वैल्यू के अंतर को चिह्नित करे, किसी बहुत छोटे इंटीग्रेशन से बड़ी हर चीज़ के लिए सेटअप के समय के लायक है।
My Geocode के कम्पैटिबिलिटी होस्ट खास तौर पर इसलिए बनाए गए हैं कि हर होस्ट जिस प्रोवाइडर की नकल करता है, उसके लिए पहली दो श्रेणियों के अंतर कम से कम हों, कॉपीराइट, शर्तों और गोपनीयता के टेक्स्ट को छोड़कर फ़ील्ड की मौजूदगी और फ़ॉर्मैट बिल्कुल मेल खाते हैं, जिसका हर होस्ट के लिए दस्तावेज़ /docs/compatibility/ पर है। इससे तीसरी श्रेणी, यानी एक जैसे फ़ील्ड नाम के नीचे अर्थगत अंतर, वह मुख्य चीज़ रह जाती है जिसे कम्पैटिबिलिटी होस्ट का उपयोग करते समय भी सीधे टेस्ट करना चाहिए, क्योंकि फ़ॉर्मैट का मेल कभी भी मूल पद्धति के मेल की पूरी गारंटी नहीं देता।
किसी माइग्रेशन को पूरा मानने से पहले इस तुलना के काम के लिए वास्तविक समय निकालना, कुछ आम पतों के सफल टेस्ट को काफ़ी मानने के बजाय, उस तरह की बारीक डेटा गुणवत्ता समस्या से बचने के ज़्यादा भरोसेमंद तरीकों में से एक है जिसे नोटिस करने में हफ़्ते लगते हैं और उसकी असली वजह तक पहुँचने में उससे भी ज़्यादा।