تغییر دیتابیس را یکباره نشکن؛ الگوی Expand–Migrate–Contract
یک rename یا تغییر ستون باعث میشود نسخه قدیمی برنامه و نسخه جدید در زمان deploy با هم ناسازگار شوند.
اول ساختار جدید را سازگار اضافه کن، داده و کد را منتقل کن و فقط بعد از اطمینان بخش قدیمی را حذف کن.
چطور دقیقتر به موضوع نگاه کنیم؟
- ستون یا ساختار جدید را بدون حذف قبلی اضافه کن و default/nullable بودن را آگاهانه انتخاب کن.
- کد را طوری منتشر کن که بتواند در دوره انتقال با ساختار جدید کار کند.
- دادههای قبلی را با job قابل تکرار backfill و تعداد رکوردهای باقیمانده را پایش کن.
- وقتی هیچ مصرفکننده قدیمی نمانده، read/write قبلی و در نهایت ستون قدیمی را حذف کن.
چرا این موضوع مهم است؟
در deployment واقعی، همه instanceها و jobها دقیقاً همزمان تغییر نمیکنند. مهاجرت سازگار پنجره انتقال میسازد.
سؤالهایی که معمولاً بعدش پیش میآید
برای پروژه کوچک هم لازم است؟
برای تغییر ساده ممکن است زیاد باشد، ولی هرجا downtime یا چند نسخه همزمان داری ارزش بیشتری دارد.
Rename مستقیم چرا بد است؟
ممکن است کد قدیمی در لحظه deploy هنوز نام قبلی را بخواهد.