اول کد رو یکی کن، بعد مهاجرت کن
پایتونخلاصهٔ کاملتر
نویسنده تعریف میکنه که سرویسشون سالها دو تا نسخه داشت: نسخهٔ پایتون ۲ که روی سرورهای on-prem خودشون سرویس میداد، و یه نسخهٔ مدرن پایتون ۳ روی یه برنچ جدا که منتظر مهاجرت به کلاد بود. به گفتهٔ نویسنده کلی از پروژههای بهروزرسانی سیستمهای قدیمی همین شکلیان: مقصد روشنه، پس تیم مستقیم میره سراغش و کار سنگین رو دور از production روی یه برنچ طولانیمدت جلو میبره.
نویسنده میگه این نقشه معمولاً چیزی که قول میده رو تحویل نمیده، چون تا وقتی نسخهٔ جدید ریلیز نشده ریسک از بین نمیره بلکه روی هم تلنبار میشه. هر فیکس فوری باید روی نسخهٔ قدیمی بره و بعد به نسخهٔ جدید پورت شه، یا اصلاً فراموش میشه. هر تفاوت رفتاری بین این دو هم یه باگیه که تازه بعد از cutover (یعنی همون لحظهای که ترافیک از سیستم قدیمی به جدید سوییچ میشه) لو میره؛ درست همونجا که پیدا کردن مقصرش از همیشه سختتره.
کاری که تیم کرد یه قدم به عقب بود. سیستمعامل هاستهای قدیمی اونقدر قدیمی بود که پشتیبانی پایتونش نهایتاً تا ۳.۶ میرسید، ولی نسخهٔ مدرن ۳.۷ رو هدف گرفته بود. بهجای بیلد کردن پایتون از سورس یا سوار کردن کانتینر روی هاستهایی که هیچوقت براش ساخته نشده بودن، نسخهٔ جدید رو به ۳.۶ دانگرید کردن و کانفیگ دیپلوی on-prem رو برگردوندن، با تنظیماتی که سر اجرا بر اساس محیط انتخاب میشن. نتیجه یه کدبیس واحد بود که هم روی هاست قدیمی و هم روی Kubernetes دیپلوی میشد.
با برقرار شدن parity (یعنی وقتی کد قدیم و جدید دقیقاً یکی میشه)، هر ریلیز به هر دو محیط میرفت و تفاوت رفتارها همون لحظه و قطرهقطره خودشون رو نشون میدادن، نه یکجا سر cutover. سالها واگرایی بین دو نسخه وقتی صاف شد که زیرساخت قدیمی هنوز بهعنوان fallback سر جاش بود. برای همین مهاجرت نهایی به کلاد فقط یه تغییر زیرساختی بود: اگه چیزی میشکست، معلوم بود تقصیر پلتفرمه، چون کد دو طرف عین هم بود.
نویسنده معتقده اگه یه برنچ ماههاست بازه یا یه بازنویسی منتظر مهاجرت بقیهٔ تیمهاست، یعنی اون تغییر داره یهجا خیلی زیاد کار انجام میده. پیشنهادش اینه دنبال یه حالت میانی بگردی که همین الان قابل ریلیزه، حتی اگه ظاهرش عقبگرد باشه. بعد از مهاجرت هم همون آپگرید پایتون که سالها گیر کرده بود به شکل یه ریلیز معمولی رفت بالا، چون نه سقف نسخهٔ هاست قدیمی سر راه بود و نه دیگه دو تا کدبیس داشتن.
نکات کلیدی:
- سرویس سالها دو نسخه داشت: پایتون ۲ روی on-prem و پایتون ۳ روی یه برنچ جدا
- سقف پایتون روی سیستمعامل هاستهای قدیمی ۳.۶ بود، در حالی که نسخهٔ مدرن ۳.۷ رو هدف گرفته بود
- تیم عمداً به ۳.۶ دانگرید کرد تا یک کدبیس هم روی on-prem و هم روی Kubernetes دیپلوی شه
- تنظیمات هر محیط موقع اجرا انتخاب میشد، نه با دو تا شاخهٔ جدا
- سوییچ نهایی به کلاد فقط یه تغییر زیرساختی بود، چون کد دو طرف یکی بود
