Sitios de ensayo, ¿cómo se gestionan las actualizaciones de sincronización en la base de datos?


10

Es ampliamente aceptado que los desarrolladores deben probar las actualizaciones a través de un sitio provisional antes de lanzarlas al servidor en vivo, sin embargo, una vez que las actualizaciones de desarrollo requieren modificaciones en Wordpress DB, las cosas se complican, ya que los usuarios en el sitio en vivo también actualizarán la base de datos.

El único flujo (confuso) que puedo imaginar es el siguiente:

  1. Probar en un servidor local (WAMP, XAMP, etc.)
  2. Una vez que esté listo para la implementación, coloque el sitio en vivo en modo de mantenimiento
  3. Copia de seguridad del sitio en vivo (Duplicator, sqldump, etc.)
  4. Cree un clon de sitio en vivo bloqueado para el sitio de preparación
  5. Subir modificaciones del entorno local al sitio de preparación
  6. Probar el sitio de preparación
  7. Empuje el sitio de preparación para vivir.
  8. Eliminar modo de mantenimiento

Inconvenientes del flujo anterior:

  • los tiempos de inactividad pueden ser más largos de lo esperado para los usuarios mientras el desarrollador prueba cuidadosamente las actualizaciones en el sitio de preparación;
  • puede requerir la administración manual de modificaciones: por ejemplo, los diseños del generador de páginas de origen se almacenan en la base de datos, por lo que una vez que se modifica un diseño, debe importarse manualmente en el sitio de ensayo; en este caso, podría ser adecuado simplemente colocar e importar páginas en el sitio de ensayo y, si funciona, importarlas en el sitio activo

Me pregunto si hay una forma mejor y más automatizada para lograr esto.

¿Qué piensas?

EDIT, según lo solicitado, algunas soluciones se han propuesto en el pasado pero ninguna ofrece una solución definitiva:


@ Dan9, pensé que sería más seguro minimizar el acceso al sitio en vivo. ¿Es un hábito común editar diseños en el sitio en vivo? ¡Tal vez me estoy preocupando demasiado!
Riccardo

Bueno, puedes crearlos, actualizarlos, eliminarlos, restaurarlos. ¿De qué te preocupas?
MinhTri

Entonces, ¿es habitual cargar diseños sin realizar pruebas en el sitio de preparación? ¿Cuál es su flujo de trabajo típico (local / puesta en escena / en vivo)?
Riccardo

Eche un vistazo al complemento wp-sync-db .
MinhTri

¿Es confiable? ¿Estás usando esta herramienta?
Riccardo

Respuestas:


2

Los proveedores de alojamiento más nuevos que se adaptan específicamente a WordPress generalmente tienen herramientas para aliviar este dolor. Puse a mis clientes en Pantheon que tiene este flujo de trabajo ordenado habilitado para Git , donde el código solo se mueve hacia arriba (desde el desarrollo hasta la producción) y las cosas de DB solo se mueven hacia abajo (viceversa desde el código). Copiar una base de datos de producción a puesta en escena es un clic con su interfaz. Siempre que se respete este flujo de trabajo, esto prácticamente elimina el problema de desordenar la base de datos de producción, lo que me permite probar siempre mis cambios en un nuevo clon de datos de producción DB en cualquier etapa de desarrollo.

Uno no tiene que usar Pantheon: puede adoptar un enfoque similar en su proceso utilizando sus propias herramientas (Git + un complemento de clonación de DB como WP Migrate DB). Me parece que esta forma funciona bien para mí.

Pregunta: ¿por qué pondría su sitio de producción en modo de mantenimiento mientras prueba la puesta en escena? No debería ser necesario en la mayoría de los casos. El único caso en el que puedo pensar es en tener algún tipo de sistema muy frágil altamente sensible a los datos adicionales del usuario que se ingresan, con un error catastrófico para arrancar, pero eso probablemente sea indicativo de un problema diferente y más grande en el que uno necesitaría repensar la arquitectura completa de sus productos.


Mi proveedor permite crear sitios de preparación con un solo clic y pulsar para vivir con una selección granular en las tablas que se reescriben, sin embargo, todavía necesito bloquear a los usuarios mientras se ejecuta la prueba final porque parte de la implementación está inyectando datos del lado del desarrollador en la base de datos (los diseños de página del creador de sitios, por ejemplo, se almacenan en la base de datos), lo que requiere que los usuarios dejen de actualizar durante esta fase. Si tiene una mejor idea de cómo lograr este paso, ¡me encantaría compartirlo con usted!
Riccardo

Por cierto, ¿pasa por el flujo de desarrollo / puesta en escena / en vivo cada vez que se realiza una pequeña modificación? Por ejemplo, cambiando ligeramente el diseño de una página dentro del editor, o modificando un menú
Riccardo

Sí, los archivos pasan por dev -> puesta en escena -> prod cada vez (tal vez puede deshabilitar la puesta en escena o dev - no lo recuerdo). El desarrollo es para el equipo de desarrollo, la preparación es para el control de calidad o la aprobación del diseñador / cliente antes de presionar para producir.
montrealist

1

Eche un vistazo a VersionPress, que lleva el control de versiones GIT a todo el proceso (archivos y base de datos)

Como se describe en su sitio:

VersionPress proporciona una puesta en escena sin dolor . Esto significa que puede crear fácilmente un entorno de prueba seguro para sus cambios y fusionarlos solo cuando estén listos. Fusionar es la palabra clave aquí: VersionPress maneja situaciones en las que su sitio en vivo tenía contenido nuevo mientras tanto sin problemas.


¿Cómo puedo verificar la confiabilidad de esta herramienta?
Riccardo
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.