En gardant WP base de données synchronisée entre plusieurs développeurs utilisant git
Je travaille à l'amélioration de mon flux de travail git tel qu'il s'applique à mes projets de développement WordPress. Souvent, lors du développement d'un système de gestion de contenu, je crée un serveur de développement (tel que http://dev.finalsitename.com) contenant les types de publication personnalisés et les taxonomies qui seront utilisés dans la version de production. Cela permet à mon client de commencer à ajouter son contenu sur le site.
Pendant qu'ils travaillent sur cette tâche, je construis généralement l'aspect et la convivialité, ainsi que la programmation personnalisée/les plugins qui seront utilisés sur mon environnement localhost. Pour m'assurer de ne pas écraser leurs mises à jour, je retire généralement une copie de leur base de données et remplace la mienne. Cependant, il y a des moments où je dois juste sauter dans la zone WP admin et modifier un paramètre ou quelque chose d'autre de petite taille ...
Si plusieurs développeurs travaillent sur un projet WordPress, nous effectuons chacun une sauvegarde de la base de données (horodatée) de notre version du site, que nous incluons dans le répertoire racine avant de valider et de repousser leur branche locale dans le référentiel distant. Le problème avec cette approche est que les bases de données sont souvent désynchronisées, sans moyen facile de déterminer laquelle utiliser.
Que font les autres développeurs pour maintenir leurs bases de données synchronisées tout en permettant à plusieurs développeurs (et clients/producteurs de contenu) de travailler sur le même projet?
Il y a 3 options parmi les plus simples ->
Utilisez une seule base de données distante à laquelle vous vous connectez avec de nombreuses sauvegardes. De cette façon, vous devez vous préoccuper des fichiers et non de la base de données.
Utilisez les fonctionnalités d'importation et d'exportation intégrées à WordPress et insérez-les dans votre contrôle de version directement dans la racine de wp (comme dans un nouveau dossier). Bien sûr, cela prend quelques minutes supplémentaires, mais la solution est simple et vous pouvez l’automatiser, mais plus important encore, elle fera partie du contrôle de version.
Utilisez un script de mise à jour personnalisé pour la version de la synchronisation de base de données réelle. Honnêtement, je ne sais pas comment vous pouvez gérer cela avec git car c'est juste un script et je ne sais pas vraiment ce qui se passe, je sais qu'il existe des outils tiers qui le font commercialement et gratuitement ( http: // www.liquibase.org/ ).
Si vous devez synchroniser entièrement les bases de données, c.-à-d. Schéma et données, vous pouvez développer un système de gestion de version personnalisé basé sur des sauvegardes.
Ou si vous souhaitez conserver les données de la production mais faire évoluer son schéma, vous pouvez travailler avec une solution personnalisée (un fichier versionné avec toutes les modifications de schéma) ou avec une solution standard basée sur le concept migration. Vous pouvez trouver de nombreuses informations dans ce thread stackoverflow: Mécanismes de suivi des modifications du schéma de base de données .
Je suis désolé si cela semble incroyablement évident, mais si vous devez tous disposer de la même copie de la base de données avec la même structure, n’auriez-vous pas intérêt à disposer d’un serveur SQL central/bureau et à l’utiliser? Clonez-le localement si vous avez besoin d'expérimenter, mais conservez-le comme standard defacto faisant autorité et effectuez des sauvegardes de ce serveur et uniquement de ce serveur.
Sinon, lorsque je travaille sur un projet de groupe, nous avons nos propres configurations avec un contenu différent. Le code prend en charge la mise à niveau et la migration des structures de table et nous pouvons accéder aux installations locales du code s'exécutant sur nos machines via le réseau local. Il n'est donc pas nécessaire de partager du contenu.
Si nous entrons du contenu, nous l'exécutons sur un serveur de test que nous pouvons ensuite exporter et importer sur le serveur actif ou nous pouvons migrer directement vers le serveur de production si aucune instance active n'existe actuellement.
Si, à un moment quelconque, vous avez besoin d'une séparation des données de test en temps réel et de données WIP, utilisez simplement une branche en direct, de test et de développement dans votre référentiel.