Mantener la base de datos de WordPress sincronizada entre múltiples desarrolladores usando git
Estoy trabajando en mejorar mi flujo de trabajo con Git aplicado a mis proyectos de desarrollo en WordPress. A menudo, cuando desarrollo un sistema de gestión de contenidos, creo un servidor de desarrollo (como http://dev.nombredelsitiofinal.com
) que contiene los tipos de contenido personalizados y taxonomías que se usarán en la versión de producción. Esto permite que mi cliente comience a añadir su contenido al sitio.
Mientras trabajan en esta tarea, yo suelo estar desarrollando el diseño visual así como la programación personalizada/plugins que se usarán en mi entorno localhost. Para asegurarme de no sobrescribir ninguna de sus actualizaciones, generalmente descargo una copia de su base de datos y reemplazo la mía. Sin embargo, hay veces que necesito entrar rápidamente al área de administración de WP y cambiar algún ajuste u otra cosa menor...
Si hay múltiples desarrolladores trabajando en un proyecto WordPress, cada uno hace un volcado de la base de datos (con marca de tiempo) de su versión del sitio y lo incluye en el directorio raíz antes de hacer commit y push de su rama local al repositorio remoto. El problema con este enfoque es que las bases de datos frecuentemente se desincronizan sin una forma fácil de determinar cuál usar.
¿Qué están haciendo otros desarrolladores para mantener sus bases de datos sincronizadas mientras permiten que múltiples desarrolladores (y clientes/productores de contenido) trabajen en el mismo proyecto?

Hay 3 opciones desde la más sencilla -->
Usar solo una base de datos remota a la que todos se conecten con muchas copias de seguridad. De esta manera solo tendrás que preocuparte por los archivos y no por la base de datos.
Usar la funcionalidad de importar y exportar incorporada en WordPress y guardarla en tu control de versiones directamente en la raíz de wp (como en una nueva carpeta). Claro que toma unos minutos extra pero es extremadamente simple y puedes automatizarlo, pero más importante es que se convertirá parte del control de versiones.
Usar un script personalizado para actualizar y versionar la sincronización real de la base de datos. Honestamente no sé cómo podrías manejar esto con git porque es solo un script y no sabe realmente lo que está pasando, sé que hay herramientas de terceros que hacen esto tanto comerciales como gratuitas ( http://www.liquibase.org/).

Si necesitas mantener las bases de datos completamente sincronizadas, es decir, tanto el esquema como los datos, podrías desarrollar un sistema de control de versiones personalizado basado en copias de seguridad.
O si deseas conservar los datos de producción pero evolucionar su esquema, podrías 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
. Puedes encontrar mucha información en este hilo de stackoverflow: Mecanismos para rastrear cambios en el esquema de la base de datos.

También uno sencillo aquí http://stackoverflow.com/questions/825787/how-to-automate-migration-schema-and-data-for-php-mysql-application

Lamento 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 más sentido tener un servidor SQL central/oficina y usarlo? Clonarlo localmente si necesitan experimentar, pero mantenerlo como el estándar definitivo y autoritativo, y hacer copias de seguridad solo de ese servidor.
De lo contrario, cuando trabajo en un proyecto grupal, cada uno tiene su propia configuración con contenido diferente. El código se encarga de actualizar y migrar las estructuras de las tablas, y podemos acceder a las instalaciones locales del código que se ejecutan en las máquinas de los demás a través de la LAN, por lo que no hay necesidad de compartir 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 no existe una instancia en vivo actualmente.
Si en algún momento necesitan separar datos de producción, prueba y trabajo en progreso, simplemente usen ramas de live, test y development en su repositorio.

Para aquellos que no encuentran que las soluciones anteriores sean lo suficientemente fáciles, una excelente solución de plugin de pago es WP Migrate DB Pro.
Te permite enviar y extraer bases de datos entre instancias de WordPress. Aún no ofrece un sistema similar a git para tus bases de datos, pero si tienes un servidor de staging central que sea la "verdad" para las bases de datos y donde se deben realizar los cambios, funciona increíblemente bien.
(Sugerencia obsoleta a continuación - Gracias a Elmar en los comentarios)
O podrías investigar Version Press, que afirma ofrecer un sistema de gestión similar a git para archivos y bases de datos. Este plugin no lo he usado personalmente, pero lo he estado siguiendo durante un tiempo y todavía está disponible.
