web-dev-qa-db-fra.com

Gérant WP Mises à jour principales et plugins pour les clients

J'aimerais savoir comment vous gérez WP Core & Plugin pour les clients? C’est un service que ma société Web souhaiterait offrir mais nous ne sommes pas certains de la meilleure solution.

Me laisser fournir quelques détails:

  1. Les sites que nous construisons sont sous contrôle de version (Git/Github)
  2. Notre processus implique généralement 3 environnements: développement local, mise en scène/test, production
  3. Le déploiement est géré via Github & DeployHQ
  4. Les bases de données sont synchronisées à l'aide de l'excellent WP Migrate DB Pro Plugin
  5. Les sites sont hébergés sur un VPS

Par défaut, nous désactivons les mises à jour automatiques dans WP.

Nous recherchons une solution adaptée à notre flux de travail et nous nous demandons si quelqu'un d'autre utilise un flux de travail similaire?

Nous ne souhaitons pas simplement nous connecter à un site de production de clients et mettre à jour le noyau et/ou les plugins via l’administrateur. Cela signifierait que le code sous contrôle de version serait "obsolète" et que cela pourrait potentiellement endommager le site actif.

Nous allons bientôt gérer les sauvegardes de code & db avec CodeGuard .

Toute suggestion serait très appréciée.

pluginsupdatescoremanagement
6
Philip Benton

Vous ne savez pas vraiment si vous avez une réponse précise à votre question, mais vous trouverez ci-dessous quelques informations/réflexions utiles.

En plus de cela, je ne connais pas (tous) les outils que vous mentionnez, mais c’est secondaire quand même.

Ce que vous voulez, bien sûr, est de maintenir en vie le processus de développement, comme vous l'avez décrit. Comme vous l'avez dit, cela ressemble à ceci:

local dev (start cycle 1) > testing/staging (cycle 1) > production (cycle 1)

Ce n'est bien sûr pas un processus linéaire, c'est un cycle. Parce qu'après le déploiement de votre travail en production, vous allez certainement développer de nouvelles fonctionnalités basées sur l'état le plus récent que vous avez atteint. Ceci s'applique de la même manière pour les mises à jour - principales ou plug-in.

Donc, si vous commencez votre nouveau cycle de développement, ce serait comme ceci:

local dev (production from cycle 1, start cycle 2) > testing/staging (cycle 2) > production (cycle 2)

De cette façon, votre code est au même stade à chaque étape du processus, votre contrôle de version est intact, mais bien sûr ceci est juste un projet simplifié sur la façon de le faire.

Après tout, vous voulez créer des branches git pour les nouvelles fonctionnalités/mises à jour et utiliser les possibilités de contrôle de version en général. Donc, une dernière insertion, à cause de ces possibilités, le cycle n’est pas unidimensionnel, il suffit de penser aux branches de développement parallèles et autres.

Quoi qu’il en soit, il s’agit de choisir un flux de travail adapté git , associé à vos besoins en matière de synchronisation et de sauvegarde. En tant que modèle de branche git ou de flux de travail est définitivement hors de portée ici, je m'en tiens à cela. Regardez autour de vous, il y a beaucoup d'informations sur les modèles de workflow git.

Remarque: Cela devrait être un commentaire, mais je ne sais pas comment faire court.

5
Nicolai