Sites de transit, comment gérez-vous la synchronisation des mises à jour dans la base de données?

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:

database staging sync

— Riccardo
source

@ Dan9, je pensais qu'il serait plus sûr de minimiser l'accès au site en direct. Est-ce une habitude courante de modifier les mises en page sur le site en ligne? Peut-être que je m'inquiète trop!

— Riccardo

Eh bien, vous pouvez les créer, les mettre à jour, les supprimer, les restaurer. De quoi vous inquiétez-vous?

— MinhTri

Il est donc habituel de télécharger des mises en page sans tester dans le site de transfert? Quel est votre flux de travail typique (local / intermédiaire / en direct)?

— Riccardo

Jetez un œil au plugin wp-sync-db .

— MinhTri

Est-ce fiable? Utilisez-vous cet outil?

— Riccardo

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.

— montréaliste
source

Mon fournisseur permet de créer des sites de transit en un clic et de pousser-à-vivre avec une sélection granulaire sur les tables en cours de réécriture, mais j'ai toujours besoin de verrouiller les utilisateurs pendant que le test final est exécuté car une partie du déploiement injecte des données côté développeur dans la base de données (les mises en page de sitebuilder par exemple sont stockées dans la base de données), obligeant les utilisateurs à arrêter la mise à jour pendant cette phase. Si vous avez une meilleure idée de la façon de réaliser cette étape, je serais heureux de partager avec vous!

— Riccardo

BTW, passez-vous par le flux dev / staging / live chaque fois qu'une petite modification a été apportée? Par exemple, changer légèrement la mise en page d'une page dans l'éditeur ou modifier un menu

— Riccardo

Oui - les fichiers passent par dev -> staging -> prod à chaque fois (vous pouvez peut-être désactiver staging ou dev - je ne m'en souviens pas). Le développement est destiné à l'équipe de développement, la mise en scène est destinée à l'AQ ou à l'approbation du concepteur / client avant de pousser vers la prod.

— montréaliste

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:

VersionPress offre une mise en scène indolore . Cela signifie que vous pouvez facilement créer un environnement de test sécurisé pour vos modifications et les fusionner uniquement lorsqu'elles sont prêtes. Fusionner est le mot clé ici - VersionPress gère les situations où votre site en direct avait de nouveaux contenus entre-temps de manière transparente.

— marekeiba
source

Comment puis-je vérifier la fiabilité de cet outil?

— Riccardo