Mantendo o banco de dados WP sincronizado entre vários desenvolvedores usando o git


33

Estou trabalhando para melhorar meu fluxo de trabalho git, conforme ele se aplica aos meus projetos de desenvolvimento WordPress. Freqüentemente, ao desenvolver um sistema de gerenciamento de conteúdo, criarei um servidor de desenvolvimento (como http://dev.finalsitename.com) contendo os tipos de postagens personalizadas e taxonomias que serão usadas na versão de produção. Isso permite que meu cliente comece a adicionar seu conteúdo ao site.

Enquanto eles estão trabalhando nessa tarefa, geralmente desenvolvo a aparência e os plugins / programação personalizados que serão usados ​​no meu ambiente de host local. Para garantir que eu não sobrescreva nenhuma de suas atualizações, geralmente puxo uma cópia do banco de dados e substituo o meu. No entanto, há momentos em que eu só preciso entrar na área de administração do WP e alterar uma configuração ou outra coisa pequena ...

Se houver vários desenvolvedores trabalhando em um projeto WordPress, cada um de nós fará um despejo de banco de dados (com registro de data e hora) de nossa versão do site e incluirá no diretório raiz antes de confirmar e enviar sua ramificação local de volta ao repositório remoto. O problema dessa abordagem é que os bancos de dados geralmente estão fora de sincronia, sem uma maneira fácil de determinar qual usar.

O que outros desenvolvedores estão fazendo para manter seus bancos de dados sincronizados e, ao mesmo tempo, permitir que vários desenvolvedores (e clientes / produtores de conteúdo) trabalhem no mesmo projeto?

Respostas:


12

Existem 3 opções mais fáceis ->

  1. Use apenas um banco de dados remoto ao qual todos se conectam com muitos backups. Dessa forma, você só precisa se preocupar com arquivos e não com o banco de dados.

  2. Use a funcionalidade de importação e exportação incorporada ao WordPress e jogue-a no seu controle de versão diretamente na raiz do wp (como em uma nova pasta). Claro que leva alguns minutos extras, mas é simples e você pode automatizá-lo, mas o mais importante será que ele fará parte do controle de versão.

  3. Use um script de atualização personalizado para versão a sincronização real do banco de dados. Sinceramente, não sei como você pode gerenciar isso com o git, porque é apenas um script e realmente não sabe o que está acontecendo, sei que existem ferramentas de terceiros que fazem isso comercial e gratuitamente ( http: // www. liquibase.org/ ).


1

Se você precisar manter os bancos de dados totalmente sincronizados, ou seja. esquema e dados, você pode desenvolver um sistema de versão personalizado com base em backups.

Ou, se você deseja manter os dados em produção, mas evoluir seu esquema, você pode trabalhar com uma solução personalizada (um arquivo com versão com todas as alterações de esquema) ou com uma solução padrão com base no conceito de migration. Você pode encontrar muitas informações neste encadeamento de stackoverflow: Mecanismos para rastrear alterações no esquema db .


Também é simples aqui stackoverflow.com/questions/825787/…
grm

1

Sinto muito se isso parece incrivelmente óbvio, mas se todos vocês precisam ter a mesma cópia do banco de dados com a mesma estrutura, não faria sentido ter um servidor SQL central / de escritório e usá-lo? Clone-o localmente se você precisar experimentar, mas mantenha-o como padrão padrão oficial e faça backups desse servidor e somente desse servidor.

Caso contrário, quando estou trabalhando em um projeto de grupo, temos nossas próprias configurações com conteúdo diferente. O código cuida da atualização e migração das estruturas da tabela e podemos acessar as instalações locais do código em execução em nossas máquinas pela LAN, para que não haja necessidade de compartilhar conteúdo.

Se estivermos inserindo conteúdo, executamos em um servidor de teste, o qual podemos exportar e importar para o servidor ativo ou podemos migrar diretamente para o servidor de produção, se nenhuma instância ativa existir atualmente.

Se a qualquer momento você precisar de uma separação de dados ativos de teste e WIP, use apenas uma ramificação ativa, de teste e de desenvolvimento em seu repositório

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.