С какими эволюционными базами данных ты работал

Что проверяют

Понимаете ли вы, что схема базы меняется вместе с кодом, и знаете ли, как это делается без простоя. Термин звучит непривычно, и уточнить вопрос тут не слабость, а нормальный ход.

Как отвечать

Речь про эволюционное проектирование базы: схема не фиксируется один раз, а изменяется небольшими версионированными шагами, которые лежат в репозитории рядом с кодом и применяются автоматически.

Что назвать:

• инструменты миграций: Liquibase и Flyway в мире Java, Alembic в Python, goose и golang-migrate в Go, встроенные миграции в Django и Rails. Все ведут учёт применённого в служебной таблице и накатывают только новые файлы;
• правило неизменности: применённый файл не переписывается задним числом, иначе история расходится между окружениями;
• совместимость на время выкладки: во время релиза одновременно работают старая и новая версии приложения, поэтому изменение делается в три шага. Добавить новое и писать в оба места, перенести данные, убрать старое следующим релизом. Схема называется «расширить и сжать»;
• безопасность операций: добавление колонки без значения по умолчанию мгновенно, индекс на большой таблице строится параллельным способом, бэкофилл идёт пачками, а не одним запросом на миллионы строк;
• откат: обратная миграция часто невозможна без потери данных, поэтому на практике выпускают исправляющую вперёд.

Что здесь делает тестировщик: проверяет прогон миграций на копии боевых данных, а не на пустой базе; проверяет работу старой версии приложения на новой схеме; следит, что данные после переноса сходятся по контрольным суммам; проверяет повторный запуск миграции на идемпотентность.

Где спотыкаются

Понимают вопрос как «какие базы вы знаете» и перечисляют PostgreSQL и MySQL.

Правят уже применённую миграцию.

Делают несовместимое изменение одним шагом и роняют выкладку.

Проверяют миграции только на пустой тестовой базе.