Начальные данные и фикстуры локальных баз: небольшой объём, идемпотентность и версионирование со схемой

Цель

Каждый разработчик, агент и задание CI может одной командой за секунды создать локальную базу с достаточным количеством реалистичных, согласованных данных для запуска приложения и тестов, не копируя производственную базу.

Предварительные условия

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

Шаги

1. Разделите три вида данных. Справочные данные относятся к миграциям или шагу заполнения, запускаемому в каждой среде, включая производственную. Примеры предназначены для разработки и демонстраций. Строки, специфичные для теста, создаются внутри тестов с помощью построителей или фикстур, а не глобального заполнения.
2. Пишите код заполнения идемпотентно. Руководство Rails говорит о db/seeds.rb, что код должен быть идемпотентным, чтобы его можно было выполнить в любой момент в любой среде; используйте upsert с естественными идентификаторами (email, slug) в качестве ключей, а не простые вставки.
3. Сохраняйте набор примеров небольшим и именованным: несколько пользователей с известными учётными данными и по одной записи в каждом интересующем состоянии — оплаченный заказ, заказ с возвратом средств, приостановленная учётная запись. Перечислите имена в README, чтобы «войти как alice@example.test» было известной отправной точкой.
4. Используйте формат, поддерживаемый стеком: loaddata в Django читает файлы фикстур, создаваемые dumpdata; другие стеки используют SQL-файлы, CSV с COPY или скрипт на языке приложения. Предпочитайте язык приложения, если строки должны проходить проверки и хуки.
5. Если нужен реалистичный объём данных, выгрузите производственную базу, исключив данные чувствительных или огромных таблиц с помощью pg_dump --exclude-table-data, отдельным шагом анонимизируйте остальное и храните результат вне репозитория с датой истечения срока хранения. Никогда не заполняйте базы на машинах разработчиков сырыми производственными данными.
6. Подключите заполнение к скрипту настройки и к шагу работы с базой в CI, в обоих случаях после миграций; тогда сбой заполнения из-за нового столбца обнаружится в тот же день.
7. При каждом изменении схемы включайте заполнение в проверку изменений: миграция, добавляющая обязательный столбец, должна также обновлять код заполнения.

Ожидаемый результат

Одна задача удаляет базу, выполняет миграции и заполняет её; две машины, заполненные из одного коммита, содержат одинаковые примеры, а тесты не зависят от строк, которые они сами не создавали.

Ограничения и основания проверки

Начальное заполнение заменяет пустую базу, а не построители тестовых данных. Сгенерированные идентификаторы различаются между запусками, если код заполнения не задаёт их явно. Анонимизация — самостоятельная дисциплина и здесь не рассматривается. Шаги обобщают цитируемую документацию; утверждений о замеренном времени выполнения нет.