Un flux de développement moderne pour WordPress

Pour citer mon collègue Chad, WordPress "est resté extrêmement populaire depuis sa sortie en 2003". Pour beaucoup, WordPress reste de loin le système de gestion de contenu (CMS) le plus facile à adopter et qui permet une mise sur le marché rapide dans la majorité des cas d'utilisation. Il existe tellement de matériel de haute qualité pour WordPress, qu'il s'agisse de logiciels Open Source (OSS) ou Premium, que l'on peut avoir de beaux sites propulsés par un CMS facile à utiliser et opérationnel en un rien de temps.

C'est vrai, mais...

Il fut un temps dans ma carrière où la construction de solutions CMS pour les entreprises était la principale chose que je faisais. Dans ces cercles, l'idée que WordPress était un jouet qui ne convenait pas aux projets d'entreprise était courante. C'était particulièrement vrai lorsque je travaillais avec des équipes qui avaient déjà été initiées aux meilleures pratiques, connues plus tard sous le nom de méthodologie des12 facteurs. La façon traditionnelle de "faire du WordPress" ne pouvait pas vraiment épouser la méthode des 12 facteurs.

WordPress, traditionnellement

Traditionnellement, la base de code d'un projet WordPress se composait de l'ensemble du noyau de WordPress, ainsi que de tous les plugins et thèmes nécessaires au fonctionnement du projet. L'ensemble de la base de code était ensuite déployé sur l'hébergement de son choix, généralement via(S)FTP. Le modèle légèrement plus évolué consiste à enregistrer cette même base de code dans le système de gestion de code source de son choix, un outil d'intégration de code la transférant sur les serveurs de l'hébergeur.

Naviguer dans les mises à jour automatiques en arrière-plan de WordPress

Les mises à jour automatiques en arrière-plan ont été introduites dans WordPress 3.7 pour le noyau de WordPress, et plus tard étendues aux plugins, aux thèmes et aux fichiers de traduction. Bien qu'un certain degré d'automatisation des mises à jour soit certainement souhaitable, la façon dont cela est mis en œuvre dans WordPress (c'est-à-dire les mises à jour in situ) signifie que si votre base de code est dans un dépôt, elle deviendra rapidement obsolète, et vous devrez gérer les mises à jour dans le dépôt en parallèle, afin d'éviter les problèmes et les régressions en cours de route. Si au contraire, vous gérez tout par FTP uniquement, cela signifie que chaque mise à jour sera de toute façon très risquée. Dans les deux cas, je peux vous garantir que les choses vont rapidement tourner au cauchemar.

Attendez, ce n'est pas tout

Les choses se compliquent encore. Pour citer à nouveau Chad dans le même article :

"De nombreuses solutions d'hébergement, y compris Upsun, imposent des systèmes de fichiers en lecture seule au moment de l'exécution. Ces solutions déploient une image de construction hautement reproductible, conséquence de votre base de code et de son processus de construction explicitement défini, tous engagés dans le contrôle de version. [Le code externe (dépendances) [...] et idéalement les définitions de votre infrastructure elle-même sont engagés dans des versions exactes de sorte que l'ensemble de votre processus DevOps du début à la fin est répétable et reproductible".

C'est une excellente chose, y compris pour des raisons de sécurité. Cependant, comme vous l'aurez compris, cela entre en conflit avec la façon dont WordPress gère les mises à jour automatiques, et celles-ci pourraient devoir être entièrement désactivées lorsqu'un système de fichiers en lecture seule est utilisé.

Exploiter Bedrock et Composer pour le développement moderne de WordPress

Dans son article, Chad parle de la façon dont Bedrock s'appuie sur Composer pour fournir une approche plus moderne du développement WordPress, grâce aussi à l'excellent travail derrière WordPress Packagist. Chad montre qu'en combinant ces efforts avec nos propres Opérations Source, il est possible d'atteindre un bon degré d'automatisation dans les mises à jour, avec un plus grand contrôle sur les versions et une plus grande répétabilité du processus.

Notre objectif : un flux de travail et un développement WordPress efficaces

Le but de cet article est d'aller plus loin, et de montrer comment combiner Upsun avec d'autres outils, pour obtenir le meilleur flux de travail WordPress - y compris les mises à jour automatiques - qui permet également un plus grand degré de complexité, de contrôle et de configuration.

Pour ce faire, je commencerai par suivre le guideDeploy Composer-based WordPress on Upsunde la documentation Upsun.

Maximiser l'automatisation avec un modèle et des plugins de workflow WordPress

Après avoir suivi le guide, j'ai modifié mon expérience pour héberger la base de code de deux sites (ita et eng), où les deux :

• sont construits avec WordPress.org
• ont un support "distro" rudimentaire
• sont déployés sur Upsun dans une configuration multi-applications
• ont toute leur base de code gérée via composer, grâce à johnpbloch/wordpress, WordPress Packagist (pour les plugins et les thèmes), et inpsyde/wp-translation-downloader (un plugin composer pour gérer les traductions de WordPress pour le noyau, les plugins et les thèmes)
• ont leurs dépendances automatiquement mises à jour par Dependabot
• voient leurs PRs Dependabot automatiquement fusionnés par Mergify lorsque les builds passent
• ont un nouveau code déployé en production automatiquement à chaque fusion de PR
• utiliser Redis comme cache en arrière-plan
• utiliser Cloudflare comme CDN
• utiliser GitHub Actions comme CI/CD et Cron Scheduler supplémentaire

En plus de ce qui précède :

• le site ita utilise Elasticsearch
• le site eng utilise Algolia

Enfin :

• l'expérience est destinée à être utilisée comme un dépôt GitHub lié à un projet Upsun via notre intégration GitHub.

Si vous pensez que cette expérience est dérivée d'un projet réel, vous avez raison !

Dans la suite de cet article, je me concentrerai sur les points qui montrent comment cette expérience permet d'automatiser autant que possible votre flux de travail de développement Wordpress, et j'éviterai d'entrer dans d'autres détails. Ainsi, si vous voulez en savoir plus sur le développement de WordPress à l'aide de compositeurs, reportez-vous à l'article de Chad ou directement au code dans mon dépôt.

Automatiser l'installation de WordPress avec Distros et Composer

Lesdistros ou profils d'installation sont essentiellement un moyen d'avoir votre propre configuration d'installation par défaut. Alors quecertains logiciels ont un support intégré pour cela, WordPress n'en a pas. Mon objectif était d'automatiser complètement l'installation lors du premier déploiement, j'ai donc décidé de prendre les choses en main.

Le support rudimentaire que j'ai mis en place pour cela repose sur deux choses. Tout d'abord, une section spécifique dans le fichier composer.json:

 "distro" : {"default-theme" : "lovecraft", "enable-plugins" : ["academic-bloggers-toolkit", "akismet", "contextual-category-widget", "elasticpress", "jetpack", "really-simple-ssl", "redis-cache", "series", "social-pug", "wp-cloudflare-page-cache", "wpforms-lite" ] },

Deuxièmement, un script qui utilise les informations de cette section pour effectuer une configuration initiale :

#!/usr/bin/env bash cd wordpress if ! wp core is-installed ; then WP_URL=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'keys[]' | grep $PLATFORM_APPLICATION_NAME | grep https | grep www) wp core install --url="${WP_URL}" --title="Modern WordPress" --admin_user=admin --admin_password=changeme --admin_email=change@me.com DEFAULT_THEME=$( jq -r '.[ "distro" ][ "default-theme" ]' ../composer.json ) wp theme activate ${DEFAULT_THEME} jq -r '.[ "distro" ][ "enable-plugins" ][]' ../composer.json | while read PLUGIN ; do wp plugin activate ${PLUGIN} done else wp core update-db fi

Le script est ensuite exécuté dans le cadre du crochet de déploiement dans Upsun, c'est-à-dire après que la phase de construction ait téléchargé et construit WordPress et les autres dépendances via composer. Le résultat sera une application WordPress complètement installée, vous évitant d'avoir à passer par l'assistant d'installation manuelle par défaut (bien que simple) de WordPress.

Si vous vous demandez pourquoi nous n'avons pas simplement utilisé la section scripts.postbuild dans composer.json pour exécuter un tel script, la raison principale est que pendant la phase de construction (lorsque composer est exécuté) le service de base de données n'est pas encore disponible, puisque la phase de construction est conçue uniquement pour créer un artefact déployable.

Mises à jour automatiques de la base de données WordPress

Nous parlerons des mises à jour de code plus tard, mais puisque nous avons fait référence au script ci-dessus, je voulais souligner que le même script se charge de mettre à jour la base de données dans le cas où des mises à jour de code ont exigé qu'une telle opération ait lieu.

Si vous avez déjà travaillé avec WordPress, vous savez qu'au minimum, lorsque le noyau de WordPress est mis à jour, vous pouvez être amené à exécuter une routine très simple qui met à jour le schéma de la base de données en conséquence. Cela peut être fait via l'interface d'administration, qui vous présentera un simple bouton à cliquer ; ou cela peut être fait via le wp-cli. C'est ce dernier que ce script utilise (voir comment le wp-cli est installé) : si WordPress est déjà installé, à chaque déploiement il lancera simplement une routine de mise à jour de la base de données, qui ne fera quelque chose que s'il y a quelque chose à faire.

Mises à jour automatisées des dépendances

Faisant partie de la famille GitHub depuis un certain temps maintenant, Dependabot fournit un plan gratuit pour les dépôts publics, et il supporte PHP+Composer. Vous pouvez le configurer pour décider du type de mises à jour que vous souhaitez effectuer sur vos dépendances, et le robot émettra des pull requests périodiquement, évitant ainsi les dépendances périmées. Notre configuration ressemble à ceci:

version : 2 updates : - package-ecosystem : composer directory : "/eng" schedule : interval : daily open-pull-requests-limit : 10 ignore : - dependency-name : wpackagist-plugin/really-simple-ssl versions : - 4.0.10 - package-ecosystem : composer directory : "/ita" schedule : interval : daily open-pull-requests-limit : 10

Pour les deux applications, nous avons une vérification quotidienne des dépendances (rappelez-vous, le noyau de WordPress lui-même est une dépendance !), avec une limite de 10 demandes d'extraction ouvertes à tout moment. Vous pouvez également faire des choses intelligentes comme ignorer des versions spécifiques d'une dépendance, si vous savez qu'elles sont boguées, par exemple.

Vous pourriez demander : ok, mais comment le fait d'ouvrir des PRs automatiquement permet-il d'obtenir des mises à jour automatiques des dépendances ? Et bien, ce n'est pas le cas :)

Entrez dans l'auto-fusion

Ouvrir des tas de PRs de manière automatisée ne va pas vous rendre la vie plus facile et maintenir vos dépendances à jour sans effort. Ainsi, un outil comme Dependabot doit être combiné avec un autre qui fournit des files d'attente de fusion et la possibilité de fusionner automatiquement les pull requests qui répondent à certains critères. J'ai utilisé Mergify, mais il est probable que dans un futur proche vous puissiez utiliser les merge queues de GitHub s'ils décident d'implémenter un système similaire à Mergify, où vous pouvez définir un modèle pour les PRs qui doivent être fusionnés automatiquement :

pull_request_rules : - name : automatic merge for Dependabot pull requests conditions : - author~=^dependabot(|-preview)\[bot\]$ - status-success=upsun actions : merge : method : squash

La configuration ci-dessus demande essentiellement à Mergify de fusionner automatiquement tous les PRs émis par Dependabot et qui ont été construits avec succès sur Upsun.

Comme je l'ai déjà mentionné, cette expérience est destinée à être utilisée via l'intégration de GitHub avec Upsun. Cela permet à chaque PR émise par Dependabot d'avoir un environnement de prévisualisationassocié où la construction et le déploiement de l'application avec les dépendances mises à jour auront lieu. Grâce à l'intégration avec GitHub, ce processus est ajouté en tant que vérification du statut des PRs sur le dépôt. Mergify utilise cette vérification d'état pour s'assurer que tout va bien avec le PR ; si c'est le cas, le PR sera fusionné.

Bien entendu, il s'agit d'une configuration très basique ; rien ne nous empêche d'utiliser d'autres conditions d'état et de succès dans la configuration, qui pourraient être des tests unitaires exécutés par un CI et d'autres choses de ce genre. Plus il y a d'automatisation et de vérifications d'état, plus vous pouvez être sûr que le PR peut être automatiquement fusionné.

Obtenir le contrôle et l'assurance avec Upsun et les outils d'automatisation

La combinaison d'outils comme Dependabot, Mergify et Upsun vous donne un plus grand degré de contrôle et d'assurance sur votre processus de mises à jour automatisées pour le noyau de WordPress, les plugins, les thèmes et les fichiers de traduction. En effet, pour chaque mise à jour, vous pouvez être certain qu'un environnement de production sera construit avec les changements, et des tests supplémentaires peuvent être effectués pour s'assurer que tout fonctionne toujours parfaitement. Vous pouvez décider de ne mettre à jour automatiquement que les versions mineures ou également les versions majeures. Vous pouvez exclure des versions ou des éléments spécifiques (un plugin ou un thème particulier, par exemple). Et bien d'autres choses encore. Vous disposez d'un contrôle fin, d'une puissance accrue et d'un niveau d'assurance plus élevé.

Développements ultérieurs

Le processus de développement de WordPress que je vous ai présenté ici peut être appliqué à d'autres scénarios. Par exemple, vous pouvez configurer Mergify pour qu'il fusionne automatiquement d'autres types de PR, voire tous les types de PR, si les conditions sont réunies (rappelez-vous que même les évaluations manuelles par les pairs et d'autres étapes manuelles peuvent être ajoutées en tant que contrôles d'état). Vous pouvez également extraire ce flux de travail et l'appliquer à d'autres types d'applications, et pas seulement à WordPress.

Cependant, l'une des façons d'atteindre un niveau supérieur est d'automatiser les mises à niveau de l'infrastructure ! Tout ce dont vous avez besoin est un moyen de vérifier s'il existe une nouvelle version de l'un des services gérés parUpsun que vous utilisez dans votre projet, puis d'émettre un nouveau PR avec la mise à jour (tout comme Dependabot le fait avec les dépendances d'applications). Une fois que vous avez ce composant (qui pourrait être implémenté dans votre outil de CI externe, tel que GitHub Actions), vous pouvez alors configurer Mergify pour fusionner automatiquement ces PRs, une fois de plus, dans les bonnes conditions.

Commencer l'automatisation du flux de travail de développement de WordPress avec Upsun

En attendant la possibilité d'auto-upgrade de votre infrastructure (en fait, je promets de mettre à jour mon modèle avec cette fonctionnalité dès qu'elle sera possible), vous pouvez toujours commencer à utiliser ce modèle et ce flux de travail dès maintenant, et commencer à faire gagner un temps précieux à votre équipe de développement :

• Faites un "Fork " de cette expérience sur Github
• Créez un nouveau projet Upsun
• Liez votre dépôt forké au projet nouvellement créé via notre intégration GitHub (nécessite l'installation de notre CLI).

Et comme d'habitude, vous savez où nous trouver, si vous avez besoin de nous !

Liens utiles

• WordPress | Upsun Docs
• Déployer WordPress Vanilla sur Upsun