Um ambiente de teste com dados semeados vale mais do que uma cópia de produção

Há um momento na vida de todas as equipas pequenas em que alguém sugere apontar o desenvolvimento local para uma cópia da base de dados de produção, porque os dados fictícios parecem finos e os erros a sério só acontecem com registos reais. É uma ideia tentadora com uma longa cauda de arrependimento: credenciais espalhadas por portáteis, nomes de clientes em capturas de ecrã, um trabalho de teste de emails que um dia encontra endereços reais. Fomos pelo caminho oposto e nunca mais olhámos para trás.

Um Postgres inteiro dentro do processo

As versões embebidas do Postgres ficaram genuinamente boas. A nossa aplicação decide no arranque: se existirem credenciais reais de base de dados no ambiente, usa a base de dados alojada; se estiverem em branco, levanta um Postgres dentro do processo que vive numa pasta local. As máquinas de desenvolvimento simplesmente nunca têm as credenciais, por isso o pior que acontece a um portátil mal configurado é uma base de dados vazia acabada de criar, e não um incidente em produção.

1// Choose the database at runtime. Blank env = embedded, local, harmless.2function makeDb() {3  const url = process.env.DATABASE_URL;4  if (url) return connectHosted(url);5  // In-process Postgres persisted to a local folder6  const client = new EmbeddedPostgres('./.pgdata');7  return drizzle(client, { schema });8}

O caminho da reconstrução conta tanto como o motor. Recriamos a base de dados local aplicando os mesmos ficheiros de migração que produção correu, por ordem, desde o primeiro. Essa única decisão apanhou uma família inteira de erros de graça: uma migração que assumia uma coluna de um ficheiro posterior, uma alteração de esquema que funcionava contra uma cópia antiga mas não de raiz. Se o portátil não consegue construir o esquema a partir do histórico, o lançamento seguinte também não conseguiria.

Semeie um negócio, não linhas

A diferença entre dados fictícios inúteis e úteis é a narrativa. O nosso script de sementeira não insere dez utilizadores chamados teste. Cria um salão com nome, equipa com especialidades, serviços com preços e durações honestos, clientes com histórico de visitas, marcações por vir, produtos de retalho com níveis de stock e um registo de movimentos por trás. As páginas parecem habitadas, o que significa que os erros de layout, os estados vazios e os cortes de texto desajeitados aparecem como apareceriam a um cliente real.

Essa última propriedade é fácil de subestimar. Todas as capturas de ecrã da nossa documentação, do nosso blog e dos nossos relatórios de erros vêm do ambiente semeado. Ninguém tem de olhar de perto para uma imagem a perguntar se escapou o nome de algum cliente, porque não há nomes de clientes para escapar. O processo de anonimização mais seguro é não haver nada para anonimizar.

O que é preciso acertar

• Faça do caminho seguro o caminho por defeito. Os programadores devem ter de sair do caminho para chegar a dados reais, e não para os evitar.
• Neutralize também os efeitos secundários: as chaves de email, de pagamentos e de armazenamento ficam em branco localmente, por isso um ciclo sobre clientes semeados nunca pode enviar mensagens a uma pessoa real.
• Semeie os estados que teme: a conta acabada de criar, o dia com a agenda cheia, o produto esgotado, o cliente com uma única visita há anos.
• Mantenha a sementeira na revisão de código. Quando uma funcionalidade acrescenta uma tabela, a sementeira cresce com ela, ou o ambiente apodrece em silêncio.

O retorno acumula-se. Os colegas novos correm dois comandos e ficam com um negócio a funcionar para mexer. O controlo de qualidade visual pode fotografar todas as páginas sem revisão de privacidade. E o ambiente de demonstração está sempre a cinco minutos de estar impecável, porque impecável é só uma reconstrução.

Os dados de produção respondem a perguntas. Os dados semeados deixam-no fazê-las em segurança.