Sincronización de bases de datos entre entornos dev/staging y producción en WordPress

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

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

Tan pronto como tocas el tema de realizar cambios en paralelo, entras en el área de gestión de configuración. Con muchos patrones, comunidades propias (http://www.cmcrossroads.com/) y herramientas no tanto para la gestión de versiones (como svn/git) sino para el soporte de la gestión de configuración (patrones) como clearcase. (áreas totalmente diferentes).

En este caso sigue siendo una situación simple y encontrarás que funciona con algunas limitaciones, algo de trabajo manual y algunas listas.

El escenario en el que estoy pensando para hacerlo más descriptivo de la solución ideal: múltiples desarrolladores trabajando 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 quisieras hacer esto un poco más profesional:

a) Haz una lista de todos los Elementos de Configuración con los que te encuentres, esto podría ser el código de WordPress en sí, plugins externos, contenido, metadatos y decide cuáles de estos quieres poner bajo algún tipo de "gestión", cuáles importan.

b) Describe los flujos de trabajo que pueden ocurrir, por ejemplo, qué pasa con una corrección, qué pasa con algo nuevo en desarrollo, en qué caso cambias contenido en tu lado, cómo se llama eso, y quién lo hace, quién es el dueño, por ejemplo, una nueva entrada o un nuevo plugin.

c) Para el trabajo en paralelo primero describe qué EC quieres gestionar, decide si el flujo siempre va desde desarrollo a producción o si realmente necesitas hacerlo en ambos sentidos.

d) Para cada tipo de EC en (a) escribe una resolución. Por ejemplo, para TODO lo que es texto (o texto exportado como archivos php pero TAMBIÉN texto plano en archivos XML) la fusión es posible. Esto realmente no es un problema pero necesitas una buena herramienta de fusión. por ejemplo, con ClearCase obtendrías en una fusión de 3 vías las siguientes situaciones: 1) Fusiones triviales: las hará automáticamente 2) No triviales automáticas: las hará automáticamente PERO necesitas verificarlo 3) No triviales no automáticas: esto es un conflicto, por ejemplo, en 1 línea se han hecho varios cambios. Las no triviales son la parte mínima que necesitas revisar manualmente, una buena herramienta de fusión te guiará en esto, por ejemplo, la de clearcase (que también hace fusión de palabras y donde puedes enlazar otros fusionadores comerciales o no comerciales para tipos de archivo específicos). Además, si has identificado en (a) archivos que deberían ser solo copiados, entonces su comportamiento sería no fusionarse sino simplemente copiarse en un sentido sobrescribiendo la otra versión sin fusión (por ejemplo, plugins que no has modificado). Muchos de estos tipos son posibles con diferentes comportamientos. Pero escribe las relaciones entre los EC.

Luego, para las fusiones no basadas en texto, necesitas tomar una decisión sobre cómo manejarlas, por ejemplo, imágenes que han sido cambiadas en 2 lugares. Podrías decidir aquí que producción siempre tiene preferencia (al menos eso es lo que yo pensaría), lo que lo hace simple.

Entonces... para resolver este problema necesitas una herramienta de gestión de versiones que soporte diferentes flujos. Cada flujo representaría una parte. (esto puede ser inmensamente complejo dependiendo de tus necesidades pero en este caso creo que es muy simple).

Si ahora puedes lograr tener estos flujos bajo tus instalaciones de WordPress y sincronizarlos también con el contenido de la base de datos, etc... entonces puedes realizar las fusiones en la herramienta de CM/gestión de versiones y luego exportarlo de vuelta al otro entorno.

El asunto es... necesitas escribir esto primero. Esto no es un truco técnico. Es un patrón estándar alrededor de la Gestión de Configuración, así que nada extraño aquí, pero necesitas escribirlo. Podrías encontrar, por ejemplo, que un plugin instalado hace cambios en la base de datos con algunos datos que son diferentes en otro entorno, así que necesitas un procedimiento extra alrededor de esto.

Técnicamente casi siempre todo es posible, revisa http://www.cmcrossroads.com/forums para escenarios que son docenas o cientos de veces más complejos aunque siempre usando el mismo enfoque y el mismo conjunto de patrones de CM.

En resumen: pon una capa de gestión de versiones debajo, automatiza las fusiones y maneja los conflictos, luego importa en el entorno objetivo. Piensa en una estrategia de flujos que encaje aquí y escríbela. Realiza un poquito de gestión de CM. Esa sería la solución profesional, de lo contrario instala algún truco de copia de base de datos, scripts, etc...

Acabo de publicar un artículo sobre cómo sincronizo nuestros datos de producción con el entorno de staging. Puedes leer mi publicación en el blog sobre esto en: http://blog.wp.weightpoint.se/2012/01/04/synchronizing-wordpress-multisite-database-from-production-to-staging-enviorment/

Si también deseas sincronizar el código y otros elementos, te recomendaría crear un repositorio git o mercurial con el archivo .ignore correspondiente.

Si deseas realizar actualizaciones diferenciales desde staging a producción, entonces supongo que crear scripts de migración es la forma más segura y adecuada.