- Compara o esquema dos seus bancos de dados de desenvolvimento e produção.
- Gera o SQL necessário para fazer a produção corresponder ao desenvolvimento.
- Pede que você resolva qualquer ambiguidade, como uma coluna renomeada.
- Valida o SQL em uma cópia do seu banco de dados de produção.
- Aplica o SQL à produção depois que seu app é compilado e antes de a nova versão entrar no ar.
Isso só se aplica a bancos de dados que o Replit gerencia para o seu app. Se seu app publicado se conecta a um banco de dados externo, como Supabase, um projeto do Neon que você mesmo criou ou o Amazon RDS, o Publish não altera esse banco de dados. Use o fluxo de migração desse provedor.
Etapa 1: o Replit detecta as alterações
A publicação começa com uma etapa de Provision. Se o esquema de desenvolvimento for diferente do de produção, o painel Publish mostra Development database changes detected e começa a gerar as migrações.
Etapa 2: responda perguntas sobre alterações ambíguas
Algumas alterações de esquema podem ter dois significados. Quando o Replit não consegue saber qual você pretendia, ele pausa com Detected potential conflicts, please review e pede que você escolha. Selecione uma opção e depois Submit.Renomear ou nova?
Se uma coluna foi removida e outra adicionada na mesma tabela, o Replit pergunta se a coluna antiga foi renomeada.- Yes, rename column mantém os dados existentes sob o novo nome.
- No, create new column adiciona uma coluna vazia e descarta a antiga junto com seus dados.
Restrição de unicidade em uma tabela com dados
Se você adicionar uma restrição de unicidade a uma tabela que já tem linhas em produção, o Replit informa quantas linhas a restrição vai verificar.- Add the constraint as-is faz a migração falhar se alguma linha existente a violar. Você pode então corrigir os dados e publicar novamente.
- Remove all rows, then add the constraint limpa a tabela primeiro. Essa opção não é oferecida quando outras tabelas referenciam esta por meio de uma chave estrangeira.
Etapa 3: revise o SQL gerado
Depois que as perguntas são respondidas, o painel mostra Generated migrations to apply to production database com o SQL exato que o Replit vai executar. Leia-o antes de continuar.
- Aviso de perda de dados. Quando uma alteração pode remover dados de uma tabela que tem linhas em produção, o painel fica laranja e lista cada tabela afetada com sua contagem de linhas. As alterações que acionam esse aviso incluem:
- Remover ou recriar uma coluna ou tabela
- Alterar o tipo de uma coluna ou se ela exige um valor
- Adicionar uma coluna obrigatória
- Adicionar ou recriar índices e restrições
- Aviso de inatividade. Quando uma alteração não é compatível com a versão do seu app que está em execução, o Replit para o app em execução antes de aplicar a migração, para que os usuários não possam gravar no banco de dados durante a alteração. Expanda What’s happening? para ver detalhes.
A lista de avisos inclui apenas tabelas que contêm linhas em produção. Um
DROP TABLE em uma tabela vazia não mostra aviso, então leia o SQL mesmo quando o painel não estiver laranja.Etapa 4: o Replit valida a migração
O Replit cria uma cópia temporária do seu banco de dados de produção e executa o SQL nela. O painel mostra Validating database migrations… e depois Database migrations validated successfully.
Apps que usam um banco de dados Databricks Lakebase pulam esta etapa de validação. O painel pede que você revise o SQL gerado por conta própria antes de aprovar.
Etapa 5 (opcional): visualize seu app na cópia migrada
Depois que a validação for bem-sucedida, você pode selecionar Create preview deploy para compilar seu app com base na cópia migrada da produção. Quando a compilação terminar, selecione View preview para abri-la.
Etapa 6: aprove e publique
Selecione Approve and publish para continuar. O Replit envia o SQL exato que você revisou junto com a solicitação de publicação, então o que você viu é o que será executado. A publicação então segue pelas etapas restantes. A migração é executada depois que a compilação do seu app termina e antes de a nova versão ser promovida:- Verificações de segurança
- Compilação
- Migração do banco de dados aplicada à produção
- Empacotamento e promoção da nova versão
drizzle-kit push, db:push nem instruções CREATE TABLE IF NOT EXISTS ao comando de compilação da implantação ou ao ponto de entrada do seu servidor. Eles seriam executados a cada publicação, fora da revisão e da validação acima.
Se você pedir ao Agent para republicar em vez de usar o painel Publish e seus esquemas de desenvolvimento e produção forem diferentes, a republicação é bloqueada e você é direcionado de volta ao painel Publish para revisar a migração.
Faça alterações manuais na produção
Para correções pontuais, você pode executar SQL diretamente na produção a partir do painel Database: selecione Production no seletor de bancos de dados e use o console SQL. Veja Trabalhe com seus dados. O Replit sempre compara os bancos de dados reais, não o seu arquivo de esquema, então qualquer alteração manual passa a fazer parte da comparação da próxima publicação. Se você adicionar manualmente em produção uma coluna que não existe no desenvolvimento, a próxima publicação propõe descartá-la.Próximos passos
- Bancos de dados de desenvolvimento e produção: Entenda como seus dois bancos de dados diferem.
- Recuperação de dados: Restaure dados de desenvolvimento ou produção.
- Objetos de banco de dados não compatíveis: Objetos que o Publish não consegue migrar.