Mantener la base de datos de WP sincronizada entre múltiples desarrolladores usando git

Estoy trabajando para mejorar mi flujo de trabajo de git tal como se aplica a mis proyectos de desarrollo de WordPress. A menudo, al desarrollar un sistema de gestión de contenido, creo un servidor de desarrollo (como http://dev.finalsitename.com) que contiene los tipos de publicaciones personalizadas y las taxonomías que se utilizarán en la versión de producción. Esto le permite a mi cliente comenzar a agregar su contenido al sitio.

Mientras están trabajando en esta tarea, generalmente estoy construyendo el aspecto y la sensación, así como la programación / complementos personalizados que se utilizarán en mi entorno de host local. Para asegurarme de no sobrescribir ninguna de sus actualizaciones, generalmente saco una copia de su base de datos y reemplazo la mía. Sin embargo, hay momentos en los que solo necesito ingresar al área de administración de WP y cambiar una configuración u otra cosa pequeña ...

Si hay varios desarrolladores trabajando en un proyecto de WordPress, cada uno de nosotros realiza un volcado de base de datos (con marca de tiempo) de nuestra versión del sitio y lo incluimos en el directorio raíz antes de confirmar y enviar su rama local al repositorio remoto. El problema con este enfoque es que las bases de datos a menudo no están sincronizadas y no hay una manera fácil de determinar cuál usar.

¿Qué están haciendo otros desarrolladores para mantener sus bases de datos sincronizadas y al mismo tiempo permitir que varios desarrolladores (y clientes / productores de contenido) trabajen en el mismo proyecto?

Hay 3 opciones desde la más fácil ->

1. Utilice solo una base de datos remota a la que todos se conectan con muchas copias de seguridad. De esa manera solo tienes que preocuparte por los archivos y no por el db.

2. Use la funcionalidad de importación y exportación integrada en WordPress y colóquela en el control de su versión directamente en la raíz de wp (como en una nueva carpeta). Claro que lleva unos minutos extra, pero es muy simple y puede automatizarlo, pero lo más importante será que formará parte del control de versiones.

3. Use un script de actualización personalizado para versionar la sincronización real de la base de datos. Honestamente, no sé cómo puedes manejar eso con git porque es solo un script y realmente no sé qué está pasando, sé que hay herramientas de terceros que hacen esto comercial y gratis ( http: // www. liquibase.org/ ).

Si necesita mantener las bases de datos sincronizadas por completo, es decir. esquema y datos, puede desarrollar un sistema de versiones personalizado basado en copias de seguridad.

O si desea mantener los datos de producción pero evolucionar su esquema, puede trabajar con una solución personalizada (un archivo versionado con todos los cambios de esquema), o con una solución estándar basada en el concepto de migration. Puede encontrar mucha información en este hilo de stackoverflow: Mecanismos para rastrear cambios en el esquema de db .

Lo siento si esto parece increíblemente obvio, pero si todos necesitan tener la misma copia de la base de datos con la misma estructura, ¿no tendría sentido tener un servidor SQL central / de oficina y usarlo? Clónelo localmente si necesita experimentar, pero manténgalo como el estándar de facto autoritario y realice copias de seguridad de ese servidor y solo de ese servidor.

De lo contrario, cuando estoy trabajando en un proyecto grupal, tenemos nuestras propias configuraciones con contenido diferente. El código se encarga de actualizar y migrar las estructuras de la tabla y podemos acceder a las instalaciones locales del código que se ejecuta en nuestras máquinas a través de la LAN, por lo que no es necesario que compartamos contenido.

Si estamos ingresando contenido, lo ejecutamos en un servidor de prueba que luego podemos exportar e importar al servidor en vivo, o podemos migrar directamente al servidor de producción si actualmente no existe una instancia en vivo.

Si en algún momento necesita una separación de la prueba en vivo y los datos de WIP, simplemente use una rama de prueba, en vivo y desarrollo en su repositorio