Миграции и схема как контракт

Оля · DevOps, #qa-antrakt

Пост-мортем вторника. Выкатывали релиз с миграциями 0002 и 0003. На копии прода 0002 упала: could not create unique index "tickets_active_seat", ключ (event_id, seat_id) дублируется. Её отложили и выкатили одну 0003, которая убирает DEFAULT у orders.status. Следующие четыре минуты, пока старые инстансы API доживали своё, каждый POST /orders получал 500: null value in column "status" of relation "orders" violates not-null constraint. 212 зрителей не купили билеты.

Тимур · бэкенд, #qa-antrakt

Обе миграции проходили CI. Они накатывались на пустую базу без единой ошибки. Что ещё тестировать в миграции, кроме того, что она накатывается?

В прошлом уроке тесты начали получать схему из миграций, а не из CREATE TABLE, написанного руками. Миграции стали частью того, что тесты трогают каждый день. Сегодня сделаем шаг дальше и будем тестировать сами миграции: не только «накатывается ли», а «что она сломает у тех, кто уже работает с базой».

Ремонт моста без закрытия движения

Город ремонтирует мост, по которому круглые сутки идут машины. Закрыть его нельзя. Поэтому сначала рядом строят временную полосу. Потом переводят на неё движение. Потом ремонтируют старую полосу. И только когда по отремонтированной снова едут, разбирают временную.

Если перепутать порядок и сначала разобрать старую полосу, машины, которые уже въехали на мост, окажутся над рекой. Миграция 0003 так и сделала: убрала DEFAULT, на который опирался код, который в этот момент ещё работал.