Dados de seed e fixtures para bancos de dados locais: pequenos, idempotentes e versionados junto com o esquema

Objetivo

Todo desenvolvedor, agente e job de CI consegue criar um banco de dados local com dados realistas e consistentes o bastante para executar a aplicação e seus testes, a partir de um único comando, em segundos, sem precisar de uma cópia da produção.

Pré-requisitos

Migrations de esquema sob controle de versão e um banco de dados local que possa ser descartado e recriado livremente (um contêiner serve; veja o artigo relacionado sobre bancos de dados efêmeros). Uma classificação das tabelas em dados de referência (países, papéis, planos), dados de exemplo (alguns usuários, pedidos, documentos) e grandes volumes de histórico de que o trabalho local não precisa.

Passos

1. Separe os três tipos de dados. Os dados de referência pertencem às migrations ou a uma etapa de seed que roda em todos os ambientes, inclusive em produção. Os dados de exemplo servem ao desenvolvimento e a demos. As linhas específicas de teste são criadas dentro dos próprios testes, por builders ou fixtures, nunca pelo seed global.
2. Escreva o seed como código idempotente. O guia do Rails diz sobre db/seeds.rb que o código deve ser idempotente, para poder ser executado a qualquer momento em qualquer ambiente; use upserts baseados em identificadores naturais (email, slug), e não inserts simples.
3. Mantenha o conjunto de exemplo pequeno e nomeado: um punhado de usuários com credenciais conhecidas e um registro em cada estado interessante (um pedido pago, um reembolsado, uma conta suspensa). Liste os nomes no README, para que "faça login como alice@example.test" seja um ponto de partida conhecido.
4. Use o formato que a stack suporta: o loaddata do Django lê arquivos de fixture gerados pelo dumpdata; outras stacks usam arquivos SQL, CSV com COPY ou um script na linguagem da aplicação. Prefira a linguagem da aplicação quando as linhas precisarem passar por validações e hooks.
5. Se for necessário um volume realista, faça o dump da produção com pg_dump --exclude-table-data para tabelas sensíveis ou enormes, anonimize o restante em uma etapa separada e guarde o resultado fora do repositório, com data de expiração. Nunca popule máquinas de desenvolvimento com dados brutos de produção.
6. Integre o seed ao script de setup e à etapa de banco de dados do CI, em ambos depois das migrations; assim, um seed quebrado por uma nova coluna é descoberto no mesmo dia.
7. Torne o seed parte da revisão sempre que o esquema mudar: uma migration que adiciona uma coluna obrigatória também atualiza o seed.

Resultado esperado

Uma única tarefa descarta, migra e popula o banco; duas máquinas populadas a partir do mesmo commit contêm dados de exemplo idênticos, e os testes não dependem de linhas que eles mesmos não criaram.

Limites e base de verificação

Seeds substituem o banco de dados vazio, não os builders de dados de teste. Os identificadores gerados diferem entre execuções, a menos que o seed os defina explicitamente. A anonimização é uma disciplina à parte e não é tratada aqui. Os passos são uma síntese da documentação citada; não se faz nenhuma afirmação sobre tempos de execução.