Sincronización de base de datos entre dev / staging y producción

34

Tengo un problema con la sincronización de la base de datos de WordPress entre desarrollo y producción y me pregunto cómo otras personas lo solucionan. Soy consciente de esta pregunta pero realmente no cubre el caso de uso más desagradable y más realista.

Digamos que tengo un sitio web de WordPress en vivo. Tomé un montón de todo, replicándolo en nuestro entorno de desarrollo. Comencé a hacer cambios. 1 semana después estoy listo para implementar mis actualizaciones. Mientras tanto, la base de datos en el sitio de producción ha cambiado (nuevas publicaciones, nuevos comentarios, etc.). ¿Cómo sincronizo los cambios entre la producción y el desarrollo durante el lanzamiento y es posible automatizar (al menos, algo) este proceso?

    
pregunta Alex 22.09.2010 - 15:18

4 respuestas

9

Puede haber una mejor manera de que me pierda, pero te voy a dar 2 opciones:

1.Utilice Exportación XML para exportar sus nuevas publicaciones y comentarios. Luego use WordPress Importer para importar las nuevas publicaciones y comentarios a la base de datos dev

Es mejor importar en dev y luego mover la base de datos a producción porque cuando lo importes descargará todos los nuevos archivos de medios de producción.

  

Mientras tanto, la producción ha cambiado (nuevas publicaciones, nuevos comentarios, etc.)

Esto resolvería su problema de traer cualquier contenido modificado.

2. Use el comando INSERT IGNORE INTO para agregar las nuevas tablas desde el dev. o el comando REPLACE para sobrescribir filas duplicadas en la misma tabla.

Antes de usar MySql, haga una copia de seguridad de ambas bases de datos, mueva la base de datos gz al servidor de producción y cargue el volcado (cambie el nombre de dev si es el mismo que el de producción).

INSERT IGNORE INTO '_wp_production_db'.'wp_cool_plugin_options'
SELECT *
FROM '_wp_dev_db'.'wp_cool_plugin_options'

No me siento cómodo con los comandos de MySql, así que elegiría la opción 1.

    
respondido por el Chris_O 23.09.2010 - 03:45
2

Si es más del mismo tipo de datos (algunas publicaciones de blog, comentarios nuevos), no estoy seguro de por qué necesitas sincronizarlo realmente. No es como que cambiará la forma en que funciona el código en el sitio, ya que es más de lo mismo. Normalmente no me preocupo por eso a menos que sea un nuevo tipo de datos.

Siempre me aseguro de tener una buena muestra de los datos del sitio, no de cada publicación, página, comentario del sitio en vivo.

    
respondido por el curtismchale 22.09.2010 - 16:21
1

En cuanto toca el tema de hacer cambios en paralelo, toca el área de administración de la configuración. Con muchos patrones, comunidades propias (http://www.cmcrossroads.com/) y herramientas no tanto para la administración de versiones (como svn / git) sino para el soporte de la administración de configuraciones (patrones) como clearcase. (áreas totalmente diferentes).

En este caso, todavía es una situación simple y encontrará que funciona con algunas limitaciones y algunos trabajos manuales y algunas listas.

El escenario en el que estoy pensando es que sea más descriptivo de la solución ideal: múltiples desarrolladores que trabajan en la misma base de código, múltiples entornos de prueba, múltiples entornos de aceptación, múltiples entornos de aceptación de producción posiblemente en todos los rincones del mundo.

Si quieres hacer esto un poco más profesional:

a) escriba una lista de todos los elementos de configuración que encuentre, este podría ser el propio código de WordPress, complementos externos, contenido, metadatos y decidir cuáles de estos desea incluir en algún tipo de "administración", que los que importan.

b) describe los flujos de trabajo que pueden ocurrir, por ejemplo, qué sucede con una solución, qué sucede con algo nuevo que se está desarrollando, en qué caso cambia el contenido de su lado, cómo se llama y quién lo hace, quién es el propietario, por ejemplo. una nueva publicación o un nuevo complemento.

c) para el trabajo paralelo, describa primero los CI que desea administrar, decida si el flujo es siempre del desarrollo a la producción o si realmente es necesario hacerlo de dos maneras.

d) para cada uno de los tipos de CI en (a) escriba una resolución. P.ej. para TODO lo que es texto (o texto exportado como archivos php pero TAMBIÉN texto sin formato en archivos XML) es posible la combinación. Esto realmente no es un problema, pero necesitas una buena herramienta de combinación. p.ej. Con ClearCase obtendrías una combinación de 3 maneras en las siguientes situaciones:  1) Fusiones triviales: las hará automáticamente.  2) automático no trivial: lo hará automáticamente PERO usted necesita verificarlo  3) no trivial no automático: esto es un conflicto, por ejemplo. En 1 línea se han realizado varios cambios. Los elementos no triviales son la parte mínima que debe cuidar manualmente, una buena herramienta de fusión lo guiará en esto, por ejemplo. el que está en clearcase (que también hace fusión de palabras y donde puede vincularse en otras fusiones comerciales o no comerciales para tipos de archivos específicos). Además, si ha identificado en (a) archivos que deberían copiarse solo, su comportamiento sería no fusionarse, sino simplemente copiarse de una manera sobrescribiendo la otra versión sin una combinación (por ejemplo, complementos que no haya modificado). Muchos de estos tipos son posibles con diferentes comportamientos. Pero anote las relaciones entre los CI's,

Luego, para las combinaciones no basadas en texto, debes tomar una decisión sobre cómo manejarlas, por ejemplo. Imágenes que han sido cambiadas en 2 lugares. Aquí podría decidir que la producción siempre tiene preferencia (al menos eso es lo que pensaría), lo que lo hace simple.

Entonces ... para resolver este problema, necesita una herramienta de administración de versiones que admita diferentes flujos. Cada flujo representaría una parte. (Esto puede ser inmensamente complejo dependiendo de sus necesidades, pero en este caso creo que es muy simple).

Si ahora puede administrar tener estas transmisiones bajo sus instalaciones de WordPress y sincronizarlas también con el contenido de la base de datos, etc ..., entonces puede realizar las fusiones en la herramienta CM / versioning y luego exportarla de nuevo en el otro entorno.

La cosa es ... primero debes escribir esto. Esto no es un truco técnico. Es un patrón predeterminado alrededor de Config Management, por lo que aquí tampoco hay nada extraño, pero debe escribirlo. Usted podría encontrar por ejemplo que un complemento instalado realiza cambios en la base de datos con algunos datos que son diferentes en otro entorno, por lo que necesita tener un procedimiento adicional para solucionarlo.

Técnicamente, casi siempre todo es posible, compruebe enlace para ver los escenarios que son docenas o cientos de veces más complejos, aunque siempre con el mismo enfoque. y usando el mismo conjunto de patrones de CM.

en resumen: ponga una capa de administración de versión debajo, automatice las fusiones y maneje los conflictos, luego importe en el entorno de destino. Piense en una estrategia de transmisión que encaje aquí y escríbala. Realizar una pequeña gestión de CM. Esa sería la solución profesional. De lo contrario, instale un hack db copy, scripts, etc ...

    
respondido por el edelwater 14.11.2010 - 22:55
1

Acabo de publicar una publicación sobre cómo sincronizo los datos de producción con nuestra puesta en escena; consulte la publicación de mi blog al respecto en: enlace

Si también desea sincronizar el código y otras cosas, recomendaría crear un repositorio de git o mercurial con el archivo de ignorar correspondiente.

Si desea realizar actualizaciones diferenciales para la producción desde la puesta en escena, supongo que crear scripts de migración es la mejor y la más segura.

    
respondido por el Niklas 06.01.2012 - 00:21

Lea otras preguntas en las etiquetas