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 (similaire 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 d'administration de WP et changer un paramètre ou quelque chose d'autre de petit ...
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?
la source
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’aurait-il pas un sens d’avoir un serveur SQL central / bureau et de 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 dans 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 des données WIP, utilisez simplement une branche en direct, de test et de développement dans votre référentiel.
la source