Sincronización de la base de datos de Wordpress entre dev y prod

Se ha preguntado antes sobre cómo sincronizar archivos y la base de datos entre dos instalaciones de Wordpress.

Para el nivel de la base de datos, la respuesta suele ser básicamente volcar una base de datos e insertarla en otro servidor. El problema con esto es que terminas perdiendo cualquier cambio que potencialmente se haya realizado en el servidor de producción. Por ejemplo, métricas de uso, comentarios, etc.

Con esto en mente, comencé a preguntarme si sería posible extender el ORM de Wordpress para que pueda generar deltas y luego inyectarlos en el sitio de producción.

¿Alguien ha intentado esto, investigándolo o tiene alguna idea o comentario?

La realidad es que lo que queremos es esto: http://www.liquibase.org/

Liquibase es una biblioteca de código abierto (Apache 2.0 con licencia), independiente de la base de datos para rastrear, administrar y aplicar cambios en la base de datos. Se basa en una premisa simple: todos los cambios en la base de datos se almacenan en una forma legible pero rastreable y se registran en el control de origen.

Sin embargo, nuestro proceso de desarrollo no lo admite. Por lo general, no modificamos la base de datos a través de secuencias de comandos discretas que escribimos nosotros mismos, utilizamos complementos que activamos. No escribimos scripts DML para modificar los datos de búsqueda que luego verificamos en el control del código fuente, utilizamos una interfaz de usuario en la página de administración y, por lo tanto, no tenemos código fuente para su uso posterior en la replicación de ese cambio durante la migración.

Sin embargo, podemos emular algunos de ellos, utilizando algunas de las herramientas enumeradas en esta página:

/programming//q/225772/149060

Por ejemplo, liquidbase tiene una función diff que también incluye opcionalmente cambios en los datos. Potencialmente, podríamos generar el esquema y la diferencia de datos en un script, excluyendo (como sea posible) ciertas tablas que probablemente incluyan datos de prueba (es decir, publicaciones, etc.) y luego aplicar el script a la base de datos de producción.

MySQLDiff (discutido en la pregunta de StackOverflow) hace diferencias de esquema, y ​​su autor recomienda mysql_coldiff para diferencias de datos en forma de tabla; ambas se implementan en perl, si las herramientas de Java (liquidbase) requieren demasiados recursos para sus servidores, aunque traiga ambas bases de datos locales y ejecutar la herramienta en tu PC resuelve ese problema ...

Si realmente queremos hacerlo bien, debemos registrar cualquier sql que esté relacionado con la configuración, las opciones u otros cambios de configuración, y cualquier cambio de esquema, y ​​convertir el código registrado en un script de migración para jugar en nuestro servidor de producción. Juegue el script de migración contra el servidor, copie los archivos del sitio de WordPress (excluyendo las cargas, si corresponde) y somos dorados.

Entonces, me parece que la mejor manera de salir es un plugin de desarrollador de migración del desarrollador que atrapa el sql que necesitamos, lo almacena y luego genera un script de migración a partir del código registrado, en lugar de crear una forma de fusionar bases de datos entre puesta en escena y producción. Parece un problema más simple de resolver también.

Si miramos el código del gancho de instrumentación de @bueltge llama al complemento de inspiración: https://gist.github.com/1000143 (gracias a Ron Rennick a través de G + por señalarme en la dirección de SAVEQUERIES y el gancho de apagado, eso llévame a encontrarlo)

- modifíquelo para obtener la salida SAVEQUERIES en su lugar 
- solo se ejecuta mientras está en admin 
- filtrar todas las selecciones 
- guardar resultados en la tabla en el gancho de apagado 
- podríamos alternar selectivamente la captura de salida en función de lo que estábamos haciendo en este momento.  

Por ejemplo:

Nombre de captura: Activar y configurar el complemento XYZ

Capture State Toggle - activado

... instalar y configurar el complemento XYZ

Capturar estado alternar - apagado

Exportar script de migración para: Activar y configurar el complemento XYZ

Presione el botón Exportar para generar un campo de texto emergente con el SQL atrapado filtrado, idealmente formateado previamente como un script de shell con llamada de línea de comandos a mysql. Cópielo y péguelo en su carpeta de código de migración y agréguelo a su repositorio de código fuente.

Atención cuidadosa para activar y desactivar la captura mientras trabaja y podrá generar el script de migración perfecto para llevar su base de datos de producción a una configuración equivalente a su base de datos provisional.

Lo que es mejor, tendrá un script (o una serie de los mismos) que puede PROBAR. ¡Imágenes con scripts de migración replicables, comprobables!

Ya estoy enamorado

¿Alguien mas?

El complemento de WordPress Sync de base de datos hace un gran trabajo al sincronizar datos entre dos servidores.

Por defecto, sobrescribe TODOS los datos de destino, sin embargo, acabo de implementar algunas mejoras en el complemento que le permiten sincronizar solo tablas de bases de datos específicas. Esto puede ayudarlo a retener comentarios, usuarios y otros datos que no desee sobrescribir. ¿Eso te da la granularidad que necesitas?

Todavía no he publicado mis cambios al público, pero si está interesado en una copia, envíeme un correo electrónico a simon-at-yump.com.au. Si alguien encuentra esto útil o tiene solicitudes de funciones adicionales, avíseme y veré qué puedo hacer.

ACTUALIZACIÓN: También acabo de encontrar el complemento WP-Sync-DB , que es una bifurcación del complemento comercial WP-Migrate-DB-Pro . Hace algo muy similar, aunque probablemente tenga más brillo que la sincronización de base de datos .

Existe un servicio comercial relativamente nuevo específicamente para esta tarea. Se llama RAMPA:

http://alexking.org/blog/2011/07/20/ramp-content-deploy-wordpress