Flux de travail de développement Magento: comment «contrôler les sources» des bases de données et mettre à jour l'installation Magento en direct à partir de l'installation Test magento?

Je poste cette question parce que je voudrais savoir quel est le meilleur workflow de développement pour quelqu'un qui veut gérer tous les aspects d'une boutique en ligne.

Comme pour tout développement Web, il est bien sûr très important d'avoir une copie en direct et au moins une copie de développement de l'ensemble de la solution logicielle. Cependant, gérer des trucs Magento n'est pas comme gérer d'autres logiciels "basés sur des fichiers" car il y a aussi un composant de base de données qui entre en jeu, donc, en plus du fait que je peux utiliser un outil comme Git comme outil VCS pour le contrôle de source, comment -Je gérer les différences dans la base de données entre les versions live et développement?

Je pourrais bien sûr faire des sauvegardes de la base de données en direct via cron et insérer les instructions SQL INSERT de la sauvegarde dans le contrôle de source, mais après cela, deux bases de données évolueront séparément pendant que les clients s'enregistreront et passeront des commandes d'une main qui iront dans la base de données en direct, et car les mises à jour sont apportées à la base de données de développement séparément. Quand il s'agira de fusionner le développement et les versions live, les fichiers php peuvent être mis à jour sans problème via git (en utilisant gitignore sur le fichier unique qui héberge les détails de configuration de la base de données), mais qu'en est-il des fichiers de base de données? Comment puis-je fusionner les deux fichiers contenant les instructions INSERT SQL des deux sauvegardes sans provoquer de catastrophe et détruire le système?

C'est la zone d'ombre du cycle de vie du développement Magento à laquelle je suis confronté: la gestion des différences de base de données.

Il me semble, comme la seule solution pour synchroniser le contenu de la base de données qui diffère entre le développement / test et les versions en direct de la boutique Magento est d'écrire sur un morceau de papier toutes les modifications apportées dans la version de développement via le panneau d'administration Magento, et espérons ne faire aucune erreur, puis une fois que tout est testé et fonctionne, pour passer à la version live et effectuer ces mêmes changements pendant que Magento est mis hors ligne et est mis en mode maintenance. Puisqu'il s'agit d'un processus manuel, est-il sujet à erreur.

Alors, quelle est la meilleure façon de gérer la synchronisation de la base de données entre le serveur magento de test et le serveur magento en direct?

Merci.

Options que je connais

1.) Manuel - en d'autres termes, répétez vos actions manuellement dans le back-end = comme vous l'avez mentionné, sujet aux erreurs, lent

2.) Au niveau de la base de données avec des requêtes SQL directes = sujettes à erreur

3.) Créez une extension qui ajoute, apporte des modifications via des scripts de configuration / mise à niveau SQL. Ces fichiers font partie de votre référentiel et peuvent être déployés. Cette approche contourne principalement l'interface utilisateur.

4.) Il y a eu du travail en cours pour essayer de rendre une partie de ce flux de travail plus agréable dans des projets comme celui-ci , mais je pense qu'il n'est pas encore tout à fait prêt pour les heures de grande écoute.

Parmi toutes ces options, je suis actuellement en faveur 3.)

Il y a mageploy qui pourrait aussi résoudre ce problème.

Il existe des outils de base de données comme Toad Software (maintenant Dell) pour MySQL. Cet outil de gestion de base de données possède des fonctionnalités de comparaison de données et de structure que vous pouvez utiliser pour voir les changements entre deux bases de données. Gardez simplement des sauvegardes (ou git commits) des versions de base de données que vous souhaitez comparer, et le tour est joué. Il existe même un générateur de script pour synchroniser les deux.

Nous avons résolu ce problème en créant une base de données distante pour les développements locaux et intermédiaires à lire / écrire. Aide vraiment avec le temps et l'efficacité; plus de clonage, téléchargement de la base de données dans l'environnement de chacun.