Un processus de développement moderne pour WordPress

Pour reprendre les mots de mon collègue Chad, WordPress « est resté extrêmement populaire depuis son lancement 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 plupart des cas d’utilisation. Il existe tellement de ressources de haute qualité pour WordPress, qu’il s’agisse de logiciels open source (OSS) ou premium, qu’on peut créer de superbes sites alimentés par un CMS facile à utiliser et opérationnels en un rien de temps.

C'est vrai, mais…

Il fut un temps dans ma carrière où la création de solutions CMS pour les entreprises était mon activité principale. Dans ces milieux, l’idée que WordPress était un jouet inadapté aux projets d’envergure était courante. C’était particulièrement vrai lorsque je travaillais avec des équipes déjà familiarisées avec les meilleures pratiques qui sont ensuite devenues la méthodologie « 12 Factor App ». La manière traditionnelle de « faire du WordPress » ne pouvait pas vraiment s’aligner facilement sur l’approche 12 Factor.

WordPress, traditionnellement

Traditionnellement, le code source d’un projet WordPress comprenait l’intégralité du cœur de WordPress, ainsi que tous les plugins et thèmes nécessaires au fonctionnement du projet. L’ensemble du code source était ensuite déployé sur l’hébergement de ton choix, généralement via — hum — (S)FTP. Le modèle légèrement évolué consiste à enregistrer ce même code source dans un système de gestion de code source de ton choix, un outil de CI se chargeant ensuite de le transférer sur les serveurs de l’hébergement.

Comprendre 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 cœur de WordPress, puis étendues aux plugins, aux thèmes et aux fichiers de traduction. Bien qu’un certain degré d’automatisation des mises à jour soit clairement souhaitable, la façon dont cela est implémenté dans WordPress (c’est-à-dire les mises à jour in situ) signifie que si ton code se trouve dans un dépôt, il deviendra rapidement obsolète, et tu devras gérer les mises à jour dans le dépôt en parallèle, pour éviter les problèmes et les régressions à l’avenir. Si, au contraire, tu gères tout via FTP uniquement, cela signifie que chaque mise à jour sera de toute façon très risquée. Dans tous les cas, je peux te garantir que la situation va rapidement dégénérer en cauchemar.

Attends, ce n’est pas tout

C'est encore plus compliqué. 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 lors de l’exécution. Ces solutions déploient une image de build hautement reproductible, résultat de ton code source et de son processus de build explicitement défini, le tout soumis au contrôle de version. [...] Le code externe (dépendances) [...] et, idéalement, les définitions de ton infrastructure elle-même sont validées dans des versions exactes afin que l’ensemble de ton processus DevOps, du début à la fin, soit répétable et reproductible. »

C'est également excellent pour des raisons de sécurité. Cependant, comme tu l'as peut-être compris, cela va complètement à l'encontre de la façon dont WordPress gère les mises à jour automatiques, et celles-ci pourraient devoir être complètement désactivées lorsqu'un système de fichiers en lecture seule est utilisé.

Tirer parti de Bedrock et Composer pour le développement WordPress moderne

Dans son article, Chad explique comment Bedrock exploite composer pour offrir une approche plus moderne du développement WordPress, grâce aussi à l’excellent travail réalisé par WordPress Packagist. Chad montre qu’en combinant ces efforts avec notre propre Source Operations, il est possible d’atteindre un bon niveau d’automatisation des mises à jour, avec un meilleur contrôle des versions et une plus grande répétabilité du processus.

Notre objectif : un processus et un développement WordPress efficaces

L'objectif de cet article est d'aller plus loin et de montrer comment combiner Upsun avec d'autres outils pour obtenir le meilleur processus WordPress possible — y compris les mises à jour automatiques —, ce qui permet également un niveau plus élevé de complexité, de contrôle et de configuration.

Pour ce faire, je vais commencer par suivre le guide « Déployer WordPress basé sur Composer sur Upsun » issu de la documentation d’Upsun. 

Optimise l'automatisation avec un modèle et des plugins de processus WordPress

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

• sont construits à l’aide de WordPress.org
• disposent d’une prise en charge rudimentaire de la « distribution »
• sont déployés sur Upsun en configuration Multi-App
• ont l’intégralité de 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 permettant de gérer les traductions WordPress pour le cœur, les plugins et les thèmes)
• voient leurs dépendances mises à jour automatiquement par Dependabot
• voient leurs PR Dependabot automatiquement fusionnés par Mergify lorsque les builds réussissent
• voient leur nouveau code déployé automatiquement en production à chaque fusion de PR
• utilisent Redis comme cache back-end
• utilisent Cloudflare comme CDN
• utiliser GitHub Actions comme outil supplémentaire de CI/CD et planificateur Cron

En plus de ce qui précède :

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

Enfin :

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

Si tu penses que cette expérience est issue d’un projet réel, tu as raison !

Dans la suite de cet article, je vais me concentrer sur les points qui montrent comment cette expérience vise à automatiser autant que possible ton processus de développement WordPress, et j’éviterai d’entrer dans d’autres détails. Ainsi, si tu souhaites en savoir plus sur le développement WordPress basé sur Composer, je te renvoie à l’article de Chad ou directement au code dans mon dépôt.

Automatiser l’installation de WordPress avec Distros et Composer

Les Distros, ou profils d’installation, sont essentiellement un moyen de disposer de ta propre configuration d’installation par défaut. Alors que certains logiciels intègrent cette fonctionnalité, ce n’est pas le cas de WordPress. 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.

La prise en charge rudimentaire que j’ai mise en place repose sur deux éléments. Tout d’abord, une section sur mesure 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 hook deploy dans Upsun, c'est-à-dire après que la phase de build a téléchargé et compilé WordPress et les autres dépendances via composer. Le résultat sera une application WordPress entièrement installée, t'évitant ainsi d'avoir à passer par l'assistant de configuration manuel (bien que simple) par défaut de WordPress.

Si tu te demandes pourquoi nous n’avons pas simplement utilisé la section scripts.postbuild de composer.json pour exécuter un tel script, la raison principale est que pendant la phase d’build (lorsque composer est exécuté), le service de base de données n’est pas encore disponible, car la phase de build 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 du code plus tard, mais puisque nous avons mentionné le script ci-dessus, je tenais à souligner que ce même script se charge de mettre à jour la base de données au cas où des mises à jour du code nécessiteraient cette opération.

Si tu as déjà travaillé avec WordPress, tu sais qu’au minimum, lorsque le cœur de WordPress est mis à jour, tu devras peut-être exécuter une routine très simple qui met à jour le schéma de la base de données en conséquence. Cela peut se faire via l’interface d’administration, qui te proposera un simple bouton sur lequel cliquer ; ou via l’wp-cli. C’est cette dernière méthode que ce script utilise (voir comment l’wp-cli est installé) : si WordPress est déjà installé, à chaque déploiement, il exécutera simplement une routine de mise à jour de la base de données, qui n’agira que s’il y a quelque chose à faire.

Mises à jour automatisées des dépendances

Membre de la famille GitHub depuis un certain temps déjà, Dependabot propose une formule gratuite pour les dépôts publics et prend en charge PHP+Composer. Tu peux le configurer pour choisir le type de mises à jour que tu souhaites effectuer sur tes dépendances, et le bot émettra périodiquement des pull requests, évitant ainsi les dépendances obsolètes. 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 effectuons une vérification quotidienne des dépendances (rappelle-toi, le cœur de WordPress lui-même est une dépendance !), avec une limite de 10 pull requests ouvertes au maximum à tout moment. Tu peux aussi faire des choses astucieuses comme ignorer des versions spécifiques d’une dépendance, si tu sais qu’elles sont boguées, par exemple.

Tu te demandes peut-être : d’accord, mais en quoi le fait d’ouvrir automatiquement des PR permet-il réellement d’obtenir des mises à jour automatiques des dépendances ? Eh bien, ça ne marche pas comme ça :)

Passe à la fusion automatique

Ouvrir des tonnes de PR de manière automatisée ne va guère te faciliter la vie ni maintenir tes 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 avenir proche, tu puisses utiliser les files d'attente de fusion GitHub s'ils décident de mettre en place un système similaire à Mergify, où tu peux définir un modèle pour les PR qui doivent être fusionnées 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 toutes les PR émises par Dependabot et qui ont été compilées 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 générée par Dependabot d’avoir un environnement de test associé où la compilation 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é comme vérification de statut pour les PR du dépôt. C’est cette vérification de statut que Mergify utilise ici pour s’assurer que tout va bien avec la PR ; si c’est le cas, la PR sera fusionnée.

Il s’agit bien sûr d’une configuration très basique ; rien ne nous empêche d’utiliser des conditions d’status-successs supplémentaires dans la configuration, qui pourraient être des tests unitaires exécutés par un CI et d’autres éléments de ce type. Plus tu disposes d’automatisations et de vérifications d’état, plus tu peux être sûr que la PR pourra être fusionnée automatiquement.

Contrôle et assurance avec Upsun et les outils d’automatisation

Combiner des outils comme Dependabot, Mergify et Upsun te donne un bien plus grand contrôle et une bien plus grande assurance sur ton processus de mises à jour automatisées pour le cœur de WordPress, les plugins, les thèmes et les fichiers de traduction. En effet, pour chaque mise à jour, tu peux être certain qu’un environnement de type production sera créé avec les modifications, et que des tests supplémentaires pourront être effectués pour s’assurer que tout fonctionne toujours parfaitement. Tu peux décider si tu souhaites mettre à jour automatiquement uniquement les versions mineures ou également les versions majeures. Tu peux exclure des versions spécifiques ou des éléments particuliers (un plugin ou un thème en particulier, par exemple). Et bien plus encore. Tu bénéficies d’un contrôle précis, de plus de puissance et d’un niveau de fiabilité supérieur.

Développements futurs

Le processus de développement WordPress que je t’ai présenté ici peut s’appliquer à des scénarios plus étendus. Par exemple, tu peux configurer Mergify pour fusionner automatiquement d’autres types de PR, voire tous les types de PR, sous certaines conditions (rappelle-toi que même les revues par les pairs manuelles et d’autres étapes manuelles peuvent être ajoutées comme vérifications de statut). Tu peux également extraire ce processus et l’appliquer à d’autres types d’applications, pas seulement à WordPress.

Cependant, une façon de vraiment passer à la vitesse supérieure serait d’automatiser les mises à niveau de l’infrastructure ! Il te suffirait de trouver un moyen de vérifier s’il existe une nouvelle version de l’un des services gérés par Upsun que tu utilises dans ton projet, puis de créer une nouvelle PR avec la mise à jour (tout comme le fait Dependabot avec les dépendances d’application). Une fois que tu disposes de ce composant (qui pourrait être implémenté au sein de ton outil CI externe, tel que GitHub Actions), tu pourrais alors configurer Mergify pour fusionner automatiquement ces PR, là encore, si les conditions sont réunies.

Commence l'automatisation du processus de développement WordPress avec Upsun

En attendant de pouvoir mettre à jour automatiquement ton infrastructure (en fait, je te promets que je mettrai à jour mon modèle avec cette fonctionnalité dès que ce sera possible), tu peux déjà commencer à utiliser ce modèle et ce processus dès maintenant, et faire gagner un temps précieux à ton équipe de développement :

• Fork cette expérience sur GitHub
• Crée un nouveau projet Upsun
• Lie ton dépôt forké au projet nouvellement créé via notre intégration GitHub (cela nécessite l'installation de notre CLI).

Et comme d'habitude, tu sais où nous trouver si tu as besoin de nous !

Liens utiles

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