La realidad es que lo que queremos es esto: enlace
Liquibase es un código abierto (con licencia Apache 2.0),
Biblioteca independiente de la base de datos para el seguimiento, gestión y aplicación.
Cambios en la base de datos. Está construido sobre una premisa simple: Todas las bases de datos.
los cambios se almacenan en una forma legible pero rastreable por humanos y se verifican
en el control de código fuente.
Sin embargo, nuestro proceso de desarrollo no lo admite. Por lo general, no modificamos la base de datos a través de scripts discretos que escribimos nosotros mismos, usamos complementos que activamos. No escribimos scripts DML para modificar los datos de búsqueda que luego verificamos en el control de código fuente, usamos una interfaz de usuario en la página de administración y, por lo tanto, no tenemos ningún código fuente para usar posteriormente en la replicación de ese cambio durante la migración.
Sin embargo, podemos emular algunos de ellos, utilizando algunas de las herramientas que se enumeran en esta página:
enlace
Por ejemplo, liquidbase tiene una función de diferencias que también, opcionalmente, incluye cambios en los datos. Podríamos, potencialmente, 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, publicación, 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 las diferencias de datos de tabla - ambas se implementan en perl, si las herramientas java (liquidbase) son demasiado pesadas para sus servidores, aunque las bases de datos locales y la herramienta ejecutada en su PC resuelven ese problema ...
Si realmente queremos hacerlo bien, deberíamos registrar cualquier sql 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 contra nuestro servidor de producción. . Reproduce el script de migración en el servidor, copia los archivos del sitio de wordpress (excluyendo las subidas, si corresponde) y somos oro.
Por lo tanto, me parece que la mejor manera de salir es un plug-in de migración-creador-desarrollador que atrapa el sql que necesitamos, lo almacena y luego genera un script de migración desde el código registrado, en lugar de construir una forma 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 complemento de llamadas de gancho de instrumentación de @bueltge para inspirarse: enlace (gracias a Ron Rennick a través de G + por apuntarme en la dirección de GUARDAR y el gancho de apagado, que me llevan a encontrarlo.
-- alter it to get the SAVEQUERIES output instead
-- only run while in admin
-- filter out all selects
-- save results out to table in the shutdown hook
-- we could selectively toggle output trapping based on what we were doing at the moment.
Por ejemplo:
Nombre de captura: Activar & Configurar Plugin XYZ
Activación del estado de captura
... instalar y configurar el complemento XYZ
Capturar estado desactivado
Exportar secuencia de comandos de migración para: Activar & Configurar Plugin XYZ
Presione el botón Exportar - para generar un campo de texto emergente con el SQL atrapado filtrado - idealmente preformateado como un script de shell con una llamada de línea de comandos a mysql. Copiar & péguelo en su carpeta de código de migración y añádalo a su repositorio de código fuente.
Preste especial atención a la activación y desactivación de 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ás un script (o una serie de los mismos) que puedes PROBAR. ¡La imagen tiene secuencias de comandos replicables y comprobables!
Ya estoy enamorado.
¿Alguien más?