Déploiement continu de WordPress et contrôle de version avec Bitbucket

D'accord, les amis. Il est temps d'avouer.

Si vous êtes un peu comme moi, vous avez passé la première étape de vos années de développement WordPress à "coder en cow-boy", c'est-à-dire à apporter des modifications sauvages sur des sites en direct, à les tester de toute urgence et à les lancer avec FTP, ce qui entraîne souvent 500 messages d'erreur internes du serveur et tout le site est visible pour vos visiteurs estimés.

Bien que ce soit absolument excitant alors que l'adrénaline pompait entre vos doigts, martelant ce point-virgule oublié, sur des sites avec plus de 0 visiteurs (qui ont en fait remarqué le temps d'arrêt), cela commençait à devenir un problème. Si un arbre tombe et que personne n'est là pour l'entendre, fait-il un bruit ? Cela dépend de la théorie de l'humanité à laquelle vous souscrivez.

Cependant, si un site plante et que quelqu'un est là pour le voir, il émettra certainement un son.

Déploiement continu de WordPress mal fait

Entrez dans les sites de développement, dupliquez les installations WordPress (du moins en théorie) où des modifications pourraient être apportées, puis refaites sur le site en direct une fois que tout a été confirmé. Bien que cela ait calmé les visiteurs, cela a commencé à faire du bruit chez les développeurs. Soudain, nous avons dû suivre deux sites, nous assurer que le code est synchronisé manuellement entre eux et tout tester à nouveau pour nous assurer qu'il fonctionne sur le site en ligne. Les listes longues et désordonnées de "assurez-vous de changer cela en direct" et "assurez-vous de basculer cela sur le site de staging avant de copier le code" étaient pour le moins angoissantes. Les sauvegardes de ce système étaient également un cauchemar - une multitude de dossiers nommés "my-theme-staging-1" et "my-theme-live-before-menu-restyle-3", etc.

Il devait y avoir un meilleur moyen, et il y en avait.

Il y avait Git, qui offre un contrôle parfait des sources et d'autres fonctionnalités aux développeurs. L'utilisation du contrôle de version pour les installations WordPress a instantanément accéléré et nettoyé le développement, car des heures n'étaient plus consacrées à la sauvegarde dans un système par développeur, mais en fait au codage. Les modifications ont été enregistrées et j'ai enfin pu ajouter des messages significatifs à mon travail, des mondes de différence par rapport à "my-theme-4-v2".

Alors que la base de code était beaucoup plus propre, il restait le problème des déploiements réels et de la garantie que le site en question utilisait le dernier code - entrez l'opportunité d'une erreur humaine. S'appuyer toujours sur les téléchargements FTP manuels pour écraser le code précédent n'était pas très agréable. Alors que d'autres services CI / CD existaient, beaucoup d'entre eux comportaient un prix substantiel et une grande quantité de configuration - reconfiguration du serveur, s'appuyer sur un autre service même pour le site Web le plus simple, apprendre toute la «façon de faire» de l'autre service et tout les idiosyncrasies qui vont avec.

Bien que des configurations similaires à ce didacticiel puissent être effectuées avec GitHub/GitLab et d'autres services, j'avais mis mes œufs dans le panier Atlassian très tôt en raison de leurs référentiels privés gratuits (qui n'ont été qu'une offre récente de GitHub). Lorsque Bitbucket a introduit ses services Pipelines et Déploiements , il a permis au nouveau code de se déployer automatiquement sur des sites de staging ou de production (ou tout autre site intermédiaire) sans recharger via FTP ou en utilisant un service externe. Les développeurs peuvent désormais utiliser toutes les valeurs du contrôle de source dans leur développement WordPress et envoyer instantanément ces modifications aux destinations appropriées sans clics ni frappes supplémentaires, avec le statut de tout visible via un tableau de bord. Cela garantit que tout reste synchronisé et, en un coup d'œil, vous permet de savoir exactement quel code chaque site exécute. De plus, le prix des minutes de construction de Bitbucket est incroyablement abordable, avec 50 minutes gratuites par mois et une option pour un plan "Gratuit avec dépassements".

Il a fallu un peu de temps de démarrage pour déterminer comment utiliser au mieux les branches et les autres fonctionnalités du contrôle de source dans ce nouveau modèle et les détails de la configuration de Bitbucket Pipelines. Voici le processus que j'utilise pour démarrer de nouveaux projets WordPress. Je n'entrerai pas dans tous les détails de la configuration de git et de l'installation de WordPress, car d'excellentes ressources pour cela ne sont qu'à une recherche Google. Au final, le flux de contenu ressemblera à ceci :

La routine de déploiement Alexa Green WordPress

Les étapes décrites ici doivent être effectuées au besoin :

Sur le serveur du client

Configurez un domaine pour le site en direct (par exemple, clientsite.com) et un sous-domaine pour la mise en scène (par exemple, staging.clientsite.com).

Installez WordPress à la fois sur le site en direct et sur le sous-domaine intermédiaire. Cela peut être fait via cPanel/Softaculous (si l'hébergement du client en dispose) ou en téléchargeant depuis wordpress.org. Assurez-vous qu'il existe des bases de données distinctes pour le live et le staging respectivement.

Sur Bitbucket.com

Configurez un nouveau référentiel. Inclure un .README pour nous aider à démarrer.

Dans le référentiel, Paramètres > Pipelines > Paramètres puis cochez Activer les pipelines .

Dans Paramètres > Pipelines > Variables du référentiel , saisissez les informations suivantes :

 Name: FTP_username Value: The client FTP username

 Name: FTP_password Value: The client FTP password 

Revenez à Pipelines > Paramètres et cliquez sur le bouton Configurer bitbucket-pipelines.yml . Sélectionnez PHP comme langage sur la page suivante. Vous voudrez utiliser quelque chose comme le code suivant. Assurez-vous de remplacer la version PHP par celle que vous utilisez sur le serveur du client, et les URL/serveurs FTP par les URL/serveurs FTP réels du site client (production et staging).

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

Cliquez sur Valider le fichier . La configuration des pipelines va maintenant être validée et exécutée.

Si tout se déploie avec succès, revenez en arrière et modifiez le fichier bitbucket-pipelines.yml (vous pouvez y accéder via Pipelines > Paramètres et Afficher bitbucket-pipelines.yml ). Vous voudrez remplacer les deux endroits où il est écrit git ftp init par git ftp push et save/commit. Cela garantira que seuls les fichiers modifiés sont téléchargés, vous permettant ainsi d'économiser des minutes de construction. Votre fichier bitbucket-pipelines.yml devrait maintenant indiquer :

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

Ajoutez une branche appelée main-dev .

Sur votre machine locale

Clonez le référentiel dans un répertoire vide que vous souhaitez utiliser pour l'installation locale. Découvrez la branche main-dev .

Configurez une installation WP locale dans ce répertoire. Il existe de nombreux outils pour cela : Local by Flywheel, MAMP, Docker, etc. Assurez-vous que tout est identique (version WordPress, version PHP, Apache/Nginx, etc.) à ce qui s'exécute sur le serveur du client.

Ajoutez un .gitignore qui ressemble à ceci. Essentiellement, nous voulons que Git ignore tout sauf wp-content (pour éviter les problèmes d'installation entre les installations). Vous pouvez également ajouter vos propres règles pour ignorer les fichiers de sauvegarde volumineux et les fichiers d'icônes et DS_Store créés par le système.

 # Ignore everything * # But not .gitignore !*.gitignore # And not the readme !README.md # But descend into directories !*/ # Recursively allow files under subtree !/wp-content/** # Ignore backup files # YOUR BACKUP FILE RULES HERE # Ignore system-created Icon and DS_Store files Icon? .DS_Store # Ignore recommended WordPress files *.log .htaccess sitemap.xml sitemap.xml.gz wp-config.php wp-content/advanced-cache.php wp-content/backup-db/ wp-content/backups/ wp-content/blogs.dir/ wp-content/cache/ wp-content/upgrade/ wp-content/uploads/ wp-content/wflogs/ wp-content/wp-cache-config.php # If you're using something like underscores or another builder: # Ignore node_modules node_modules/ # Don't ignore package.json and package-lock.json !package.json !package-lock.json

Enregistrez et .gitignore .

Apportez des modifications et engagez-vous en conséquence.

Chaque fois que vous vous engagez sur main-dev, il déclenchera un téléchargement FTP sur le site de staging. Chaque fois que vous vous engagez à maîtriser, il déclenchera un téléchargement FTP sur le site de production. Notez que cela utilisera des minutes de construction, vous voudrez peut-être effectuer la plupart des modifications locales sur une branche de main-dev, puis fusionner avec main-dev une fois que vous avez terminé pour la journée.

La fusion de main-dev dans master apportera tous les changements de mise en scène en direct. Vous pouvez vérifier l'état des pipelines et des déploiements sur le dépôt sur Bitbucket.org.

Synchronisation des bases de données WordPress entre les installations

Notez que ce qui précède ne synchronisera que les fichiers (thèmes, plugins, etc.). La synchronisation de la base de données entre la production et la mise en scène devient une autre affaire, car souvent les clients apportent des modifications sur le site en direct qui ne sont pas reflétées sur le site de mise en scène, et vice versa.

Pour synchroniser les bases de données sur les installations WordPress, plusieurs options existent. Traditionnellement, vous pouvez mettre à jour les bases de données en important/exportant via phpmyadmin . C'est délicat cependant, car il ne peut pas mettre à jour certaines choses qui doivent être mises à jour, comme les permaliens dans le contenu des publications. En utilisant cette méthode, un outil préféré est le plug-in Velvet Blues Update URLs, que vous pouvez ensuite utiliser pour rechercher/remplacer toutes les instances de l'ancienne URL du site (par exemple, https://staging.clientsite.com) par la nouvelle URL du site ( par exemple, https://clientsite.com). Vous pouvez également l'utiliser avec des chemins et des chaînes relatifs. Cette méthode finit par laisser beaucoup de place à l'erreur humaine - si une chaîne remplacée est mal écrite, cela peut entraîner la rupture du site entier et l'impossibilité d'utiliser le plug-in/d'accéder au tableau de bord.

Alors qu'un plugin comme All-in-One WP Migration offre une fonction de recherche/remplacement prête à l'emploi et est incroyablement convivial, il apporte également des fichiers, annulant ainsi les valeurs de l'ensemble de notre flux de travail Pipelines. De plus, comme il réimporte tous les téléchargements wp, cela peut entraîner des fichiers et des temps de chargement volumineux (il n'est donc pas adapté au déplacement des modifications entre les installations). Un plugin comme celui-ci est mieux réservé aux sauvegardes de l'ensemble du site à des fins d'archivage/de sécurité.

VersionPress semble être une solution intéressante, mais elle n'a pas encore fait ses preuves dans de nombreux environnements de production. Pour l'instant, les plugins comme WP Sync DB ou WP Migrate DB Pro semblent être les meilleures solutions pour la gestion de bases de données. Ils permettent de tirer/pousser des bases de données à travers les installations tout en offrant la possibilité de mettre à jour automatiquement les URL et les chemins. Ils ne peuvent migrer que certaines tables, comme wp_posts pour le contenu des publications uniquement, sans perdre de temps à réimporter les utilisateurs et les paramètres du site. J'aime toujours tirer du direct pour m'assurer qu'aucune donnée de production n'est écrasée. Voici un exemple de configuration si vous utilisez WP Sync DB (plus de procédures pas à pas disponibles sur le github WP Sync DB) :

1. Sur le site en direct : configurez WP Sync DB avec le paramètre "Autoriser l'extraction depuis ce référentiel" activé.
2. Sur le site intermédiaire : configurez WP Sync DB avec les paramètres Pull from Live. Nommez-le "live-to-staging".
3. Sur votre configuration de développement locale : configurez WP Sync DB avec les paramètres Pull from Live. Nommez-le "live-to-dev".

Vous pouvez également configurer une règle de poussée "dev-to-staging" et vérifier le paramètre du site de staging pour autoriser l'écrasement de la base de données.

Emballer

J'ai trouvé que ces méthodes ont tendance à fonctionner pour la plupart des cas d'utilisation, à la fois pour développer un nouveau site Web WordPress et pour reconcevoir/reconfigurer un site déjà en ligne.

Il permet des déploiements de code qui maintiennent toutes les versions du site à jour sans temps/effort de développement supplémentaire et une logique de migration de base de données intentionnelle et sûre pour travailler entre les sites. La mise à jour des plugins est également effectuée dans le contrôle de la source, de sorte que les mises à jour des plugins peuvent être vérifiées en toute sécurité lors de la mise en scène avant de s'engager sur le site en direct, minimisant ainsi les interruptions du site de production.

Bien qu'il y ait certainement place à l'amélioration pour apporter plus d'un flux de travail de contrôle de source à la gestion de la base de données, jusqu'à ce qu'un outil comme VersionPress soit davantage utilisé dans les environnements de production, cette méthode d'extraction/poussée sélective de la base de données via WP Sync DB ou WP Migrate DB Pro semble être la méthode la plus sûre pour y faire face. Curieux de savoir ce qui fonctionne pour votre flux de travail WordPress, ou si après tout cela, vous préférez simplement saisir votre lasso et le code cowboy !