Migration שגורם ל-downtime = customer alerts, revenue loss, panic. הנה איך להימנע.

העקרון הבסיסי – Backwards Compatibility

Old code חייב להמשיך לעבוד עם schema חדש. New code חייב להמשיך לעבוד עם schema ישן (זמנית).

למה? כי במהלך deploy, יש moments של mixed state – חלק servers רץ old code, חלק new code.

Add Column

הכי פשוט. ADD COLUMN new_col DEFAULT NULL. Old code מתעלם. New code משתמש.

אם צריך NOT NULL: (1) Add nullable. (2) Deploy code שממלא. (3) Backfill old rows. (4) ALTER COLUMN NOT NULL.

Remove Column

Never: DROP COLUMN בבת אחת.

Yes: (1) Deploy code שלא משתמש בעמודה. (2) חכה שכל instances מעודכנים. (3) DROP COLUMN.

Rename Column

Never: ALTER TABLE … RENAME.

Yes: (1) ADD new_column. (2) Backfill data. (3) Deploy code שקורא ל-new + writes to both. (4) Deploy code שקורא ל-new בלבד. (5) DROP old.

Change Column Type

למשל varchar(50) ל-text.

Postgres יכול להיות quick אם התוספת compatible (text > varchar). אבל changes כמו integer ל-bigint ב-Postgres < 12 - lock long.

Safest: (1) Add new column of new type. (2) Backfill. (3) Deploy code. (4) Drop old.

Add Index

Never: CREATE INDEX בlarge table. Locks writes for hours.

Yes: CREATE INDEX CONCURRENTLY (Postgres). זה איטי יותר אבל לא blocking.

Migration Tools

Node/TypeScript: Prisma, Drizzle, Knex.

Ruby: Active Record migrations.

Python: Alembic, Django migrations.

הכל: תבדקו את הכלי – איך הוא מטפל ב-DDL. Prisma למשל יש lock issues.

Testing

Staging environment עם production-scale data. Migration test – זמן, locks.

לפעמים – להרים instance של production database backup ולבדוק שם.

Timing

Migration בזמן peak = טעות. עשו migrations בזמנים של low traffic.

לפני migration – snapshot של DB. אם משהו משתבש – restore מהיר.

מבוסס על פרויקטים אמיתיים

המדריך הזה מבוסס על עבודה עם:

• Platforma365
• Podd

קריאה נוספת

אם המדריך הזה עזר לכם, אולי תרצו לקרוא גם על פיתוח SaaS מותאם – המדריך המקיף שלנו לתחום.