Flujo de trabajo de desarrollo de Magento: ¿cómo "controlar el origen" de las bases de datos y actualizar la instalación de Magento en vivo desde la instalación de prueba de magento?

Estoy publicando esta pregunta porque me gustaría saber cuál es el mejor flujo de trabajo de desarrollo para alguien que quiere administrar todos los aspectos de una tienda en línea.

Al igual que con todo el desarrollo web, por supuesto, es muy importante tener una copia en vivo y al menos una copia de desarrollo de toda la solución de software. Sin embargo, administrar cosas de Magento no es como administrar otro software "basado en archivos" porque también hay un componente de base de datos que entra en juego, así que, además del hecho de que puedo usar una herramienta como Git como una herramienta VCS para el control de código fuente, ¿cómo ¿Voy a gestionar las diferencias en la base de datos entre las versiones en vivo y de desarrollo?

Por supuesto, podría hacer copias de seguridad de la base de datos en vivo a través de cron e insertar las instrucciones SQL INSERT de la copia de seguridad en el control de origen, pero después de eso, dos bases de datos evolucionarán por separado mientras los clientes se registran y hacen pedidos por un lado que van a la base de datos en vivo, y ya que las actualizaciones se realizan en la base de datos de desarrollo por separado. Cuando se trata de fusionar el desarrollo y las versiones en vivo, los archivos php se pueden actualizar sin problemas a través de git (usando gitignore en el archivo único que aloja los detalles de configuración de la base de datos), pero ¿qué pasa con los archivos de la base de datos? ¿Cómo puedo fusionar los dos archivos que contienen las instrucciones INSERT SQL de las dos copias de seguridad sin causar un desastre y destruir el sistema?

Esta es el área sombreada del ciclo de vida de desarrollo de Magento que estoy enfrentando: administrar las diferencias de la base de datos.

Me parece que la única solución para sincronizar los contenidos de la base de datos que difieren entre las versiones de desarrollo / prueba y en vivo de la tienda Magento es escribir en una hoja de papel todos los cambios realizados en la versión de desarrollo a través del Panel de administración de Magento, y espero no cometer ningún error, y luego, una vez que todo esté probado y funcione, pasar a la versión en vivo y llevar a cabo esos mismos cambios mientras Magento se desconecta y se pone en modo de mantenimiento. Dado que este es un proceso manual, ¿es propenso a errores?

Entonces, ¿cuál es la mejor manera de manejar la sincronización de la base de datos entre el servidor Magento de prueba y el servidor Magento en vivo?

Gracias.

Opciones que conozco

1.) Manual: en otras palabras, repetir sus acciones manualmente en el back-end = como mencionó propenso a errores, lento

2.) En el nivel de la base de datos con consultas directas de SQL = propenso a errores

3.) Cree una extensión que agregue, realice cambios a través de scripts de instalación / actualización de SQL. Estos archivos son parte de su repositorio y se pueden implementar. Este enfoque sobre todo pasa por alto la interfaz de usuario.

4.) Se ha trabajado un poco para intentar hacer que este flujo de trabajo sea más agradable en proyectos como este , pero creo que todavía no está listo para el horario estelar.

De todas estas opciones, actualmente estoy a favor 3.)

Hay mageploy que también podría resolver este problema.

Existen herramientas de base de datos como el Sapo de Quest Software (ahora Dell) para MySQL. Esta herramienta de administración de bases de datos tiene características de comparación de datos y estructura que puede usar para ver cambios entre dos bases de datos. Simplemente mantenga copias de seguridad (o git commits) de las versiones de la base de datos que desea comparar, y listo. Incluso hay un generador de scripts para sincronizar los dos.

Resolvimos este problema creando una base de datos remota para los desarrollos locales y por etapas para leer / escribir. Realmente ayuda con tiempo y eficiencia; no más clonación, cargando la base de datos al entorno de todos.