Compatibility Layers और क्रमिक Migration

नया रास्ता आसान रास्ता बनाएँ

Migration तब सफल होते हैं जब आगे बढ़ना सस्ता हो। Server पर अनुवाद परतें दें ताकि पुराने अनुरोध नए मॉडल पर map हों, अद्यतन SDKs और यांत्रिक नाम-बदलाव के लिए codemod या script प्रकाशित करें, clients को सब कुछ एक साथ पलटने की जगह प्रति feature या प्रति अनुरोध opt-in करने दें (header, flag या तारीख़ version से), और दोनों versions एक ही test suite में रखें ताकि बहाव दिखे। तोड़ने वाले व्यवहारगत बदलावों के लिए पुराने और नए को shadow mode में साथ चलाएँ (users को प्रभावित किए बिना responses की तुलना)। पहले अपनी सेवाएँ deprecated versions से हटाएँ; API टीम v2 उपयोग न करे तो कोई उस पर भरोसा नहीं करेगा।

v2 मॉडल के ऊपर v1 adapter (उदाहरण)

v1 responses उसी record से बनते हैं, बँटे fields को वापस एक name में जोड़कर, इसलिए सँभालने के लिए कोई दूसरा डेटा रास्ता नहीं।

def to_v2(item):
    return {"id": item.id, "first_name": item.first_name,
            "last_name": item.last_name, "plan": item.plan}

def to_v1(item):                       # adapter: same data, old shape
    v2 = to_v2(item)
    return {"id": v2["id"], "name": f"{v2['first_name']} {v2['last_name']}", "plan": v2["plan"]}

त्वरित जाँच: Shadow mode में पुराने और नए responses की तुलना क्यों करें?

• डेटा हटाने के लिए
• बिल दोगुना करने के लिए
• testing से बचने के लिए
• users के प्रभावित होने से पहले अंतर पकड़ने के लिए