Il est largement admis que les développeurs doivent tester les mises à jour via un site intermédiaire avant de les publier sur le serveur en direct, mais une fois que les mises à jour de développement nécessitent des modifications dans Wordpress DB, les choses se compliquent, car les utilisateurs du site en direct mettront également à jour la base de données.
Le seul flux (confus) que j'imagine est le suivant:
- Test sur un serveur local (WAMP, XAMP, etc.)
- Une fois prêt à déployer, mettez le site en ligne en mode maintenance
- Sauvegarde du site en direct (Duplicator, sqldump, etc.)
- Créer un clone de site en direct verrouillé sur le site intermédiaire
- Téléchargez les modifications de l'environnement local sur le site de transfert
- Testez le site de transit
- Poussez le site de transit pour vivre.
- Supprimer le mode de maintenance
Inconvénients du flux ci-dessus:
- les temps d'arrêt peuvent être plus longs que prévu pour les utilisateurs pendant que le développeur teste soigneusement les mises à jour sur le site de transfert;
- peut nécessiter une gestion manuelle des modifications: par exemple, les mises en page du constructeur de page d'origine sont stockées dans la base de données, donc une fois qu'une mise en page est modifiée, elle doit être importée manuellement dans le site de transfert; dans ce cas, il pourrait être suffisant de simplement déposer et d'importer des pages dans le site de transfert, et si cela fonctionne, de les importer dans le site en direct
Je me demande s'il existe un moyen meilleur et plus automatisé d'y parvenir.
Qu'est-ce que tu penses?
EDIT, comme demandé, certaines solutions ont été proposées dans le passé mais aucune n'offre une solution définitive:
- 9/2010 - Synchronisation de la base de données entre dev / staging et production
- 12/2011 - Déploiement de plug-ins mis à jour ou nouveaux qui modifient la table wp_options
- 9/2014 - Comment télécharger des modifications locales sur un serveur en direct sans remplacer les nouveaux messages / pages?
- 1/2015 - Comment maintenir les blogs du site wordpress en production et en mise en scène?
Réponses:
Les nouveaux hébergeurs qui s'adressent spécifiquement à WordPress ont généralement des outils en place pour soulager cette douleur. J'ai mis mes clients sur Pantheon qui a ce flux de travail compatible avec Git , où le code ne fait que monter (du développement à la mise en production à la production) et les trucs DB ne descendent que (vice versa à partir du code). La copie d'une base de données de la production au transfert est en un clic avec leur interface. À condition que ce flux de travail soit respecté, cela élimine à peu près le problème de toujours gâcher la base de données de production, ce qui me permet de toujours tester mes modifications sur un nouveau clone de données de base de données de production dans les stades de développement.
Il n'est pas nécessaire d'utiliser Pantheon - vous pouvez adopter une approche similaire dans votre processus en utilisant vos propres outils (Git + un plugin de clonage de base de données comme WP Migrate DB). Je trouve juste que cette méthode fonctionne bien pour moi.
Question: pourquoi mettriez-vous votre site de production en mode maintenance pendant le test de la mise en scène? Cela ne devrait pas être nécessaire dans la majorité des cas. Le seul cas auquel je peux penser est d'avoir une sorte de système très fragile très sensible aux données utilisateur supplémentaires qui y sont introduites, avec un bug catastrophique pour démarrer - mais cela serait probablement révélateur d'un problème différent, plus important, où l'on aurait besoin pour repenser toute l'architecture de leur produit.
la source
Jetez un œil à VersionPress qui apporte le versioning GIT à l'ensemble du processus (fichiers et base de données)
Comme décrit sur leur site:
la source