web-dev-qa-db-fra.com

Les sites intermédiaires, comment gérez-vous la synchronisation des mises à jour dans la base de données?

Il est généralement admis que les développeurs doivent tester les mises à jour via un site intermédiaire avant de les publier sur le serveur actif. Toutefois, lorsque les mises à jour de développement nécessitent des modifications dans Wordpress DB, les choses se compliquent car les utilisateurs du site actif mettent également à jour la base de données.

Le seul flux (confus) que je puisse imaginer est le suivant:

  1. Test sur un serveur local (WAMP, XAMP, etc.)
  2. Une fois prêt à être déployé, mettez le site actif en mode maintenance.
  3. Site de sauvegarde en direct (duplicateur, sqldump, etc.)
  4. Créer un clone de site actif verrouillé sur le site intermédiaire
  5. Télécharger des modifications de l'environnement local vers le site intermédiaire
  6. Tester le site de mise en scène
  7. Poussez le site de mise en scène pour vivre.
  8. Supprimer le mode 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 intermédiaire;
  • peut nécessiter une gestion manuelle des modifications: par exemple, les mises en page de siteorigin pagebuilder sont stockées dans la base de données; ainsi, une fois la mise en forme modifiée, elle doit être importée manuellement dans le site intermédiaire; dans ce cas, il pourrait être suffisant de simplement déposer et importer des pages dans le site intermédiaire et, si vous travaillez, de les importer dans le site actif.

Je me demande s’il existe un moyen plus automatisé d’atteindre cet objectif.

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:

databasestagingsync
8
Riccardo

Les nouveaux fournisseurs d’hébergement qui s’intéressent spécifiquement à WordPress ont généralement des outils en place pour atténuer ces problèmes. Je mets mes clients sur Pantheon qui possède ce flux de travail soigné , où le code ne fait que monter (du développement à la production) et le contenu de la base de données descendant (à l'inverse du code). Copier une base de données de la production à la mise en scène se fait en un clic avec leur interface. Si ce flux de travail est respecté, cela élimine à peu près le problème de la faille dans la base de données de production, me permettant ainsi de toujours tester mes modifications sur un nouveau clone de données de base de données de production lors de la phase 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 tel que WP Migrate DB). Je trouve juste que cette façon fonctionne bien pour moi.

Question: pourquoi voudriez-vous mettre votre site de production en mode maintenance lors des tests de staging? Cela ne devrait pas être nécessaire dans la majorité des cas. Le seul cas auquel je peux penser est d'avoir un système très fragile très sensible aux données utilisateur supplémentaires, avec un bogue catastrophique à démarrer - mais cela indiquerait probablement un problème différent, plus important, qui nécessiterait repenser toute l'architecture de leur produit.

2
montrealist

Jetez un coup d'œil à VersionPress qui intègre le versioning de GIT à l'ensemble du processus (fichiers et base de données)

Comme décrit sur leur site:

VersionPress fournit une mise en scène sans douleur . 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. La fusion est la clé Word ici - VersionPress gère les situations dans lesquelles votre site en direct présente un nouveau contenu de manière transparente.

1
marekeiba