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 celui qui permet une mise sur le marché rapide dans la plupart des cas d’utilisation. Il y a tellement de ressources de grande qualité pour WordPress, qu’il s’agisse de logiciels open source (OSS) ou de versions Premium, qu’on peut créer de superbes sites grâce à un CMS facile à utiliser et les mettre en ligne 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 constituait l’essentiel de mon activité. Dans ces milieux, l’idée selon laquelle WordPress n’était qu’un jouet inadapté aux projets d’envergure était courante. C’était particulièrement vrai lorsque je travaillais avec des équipes déjà initiées aux bonnes pratiques qui ont ensuite été baptisées « méthodologie des 12 facteurs ». La manière traditionnelle de « faire du WordPress » ne permettait pas vraiment de s’aligner facilement sur l’approche des 12 facteurs.

WordPress, à l’ancienne

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, puis à le transférer sur les serveurs de l’hébergement à l’aide d’un outil d’intégration continue (CI).

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. Même si un certain degré d’automatisation des mises à jour est clairement souhaitable, la façon dont cela est mis en œuvre 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 uniquement via FTP, chaque mise à jour sera de toute façon très risquée. Dans tous les cas, je peux te garantir que ça va vite tourner au 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 Cloud, imposent des systèmes de fichiers en lecture seule lors de l’exécution. Ces solutions déploient une image de build hautement reproductible, issue de ton code source et de son processus de build explicitement défini, le tout validé dans le contrôle de version. [...] Le code externe (dépendances) [...] et, idéalement, les définitions de ton infrastructure elle-même sont validées avec des versions précises, 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 totalement à 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 de Composer pour le développement WordPress moderne

Dans son article, Chad explique comment Bedrock s’appuie sur composer pour proposer 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 solution 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 un peu plus loin et de montrer comment combiner Upsun Cloud avec d’autres outils pour obtenir le meilleur processus WordPress possible — y compris les mises à jour automatiques —, ce qui permet aussi un niveau plus élevé de complexité, de contrôle et de configuration.

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

Optimiser l’automatisation grâce à 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), qui sont tous les deux : 

• sont construits avec WordPress.org
• disposent d’une prise en charge rudimentaire de la « distro »
• sont déployés sur Upsun dans une 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 quand les builds réussissent
• voient leur nouveau code déployé automatiquement en production à chaque fusion de pull request
• utilisent Redis comme cache back-end
• utilisent Cloudflare comme CDN
• utiliser GitHub Actions comme outil supplémentaire de CI/CD et de planification Cron

En plus de ce qui précède :

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

Enfin :

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

Si tu penses que cette expérience est issue d’un vrai projet, 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 veux en savoir plus sur le développement WordPress basé sur Composer, n’hésite pas à te référer à l’article de Chad ou directement au code de mon dépôt.

Automatiser l’installation de WordPress avec les distributions 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 prennent cela en charge de manière native, 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. 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"
    ]
  },

Ensuite, un script qui utilise les informations de cette section pour effectuer certaines configurations initiales :

#!/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 [email protected]
  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 » d’Upsun Cloud, c’est-à-dire après que la phase de build a téléchargé et compilé WordPress ainsi que les autres dépendances via composer. Tu obtiendras ainsi une application WordPress entièrement installée, ce qui t’évitera de devoir passer par l’assistant de configuration manuel par défaut (même s’il est simple) de WordPress.

Si tu te demandes pourquoi on n’a pas simplement utilisé la section « scripts.postbuild » sur composer.json pour exécuter ce script, c’est principalement parce que pendant la phase « build » (lorsque composer est exécuté), le service de base de données n’est pas encore disponible, puisque la phase de build est conçue uniquement pour créer un artefact prêt à être déployé.

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

On parlera des mises à jour du code plus tard, mais comme on a mentionné le script ci-dessus, je voulais 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, quand 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. Ça peut se faire via l’interface d’administration, où tu trouveras un simple bouton sur lequel cliquer ; ou via l’wp-cli. C’est cette dernière méthode que ce script utilise (regarde 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 enverra périodiquement des pull requests, évitant ainsi les dépendances obsolètes. Notre configuration ressemble à ça :

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, on effectue une vérification quotidienne des dépendances (n’oublie pas que le cœur de WordPress lui-même est une dépendance !), avec une limite maximale de 10 pull requests ouvertes à tout moment. Tu peux aussi faire des choses astucieuses, comme ignorer des versions spécifiques d’une dépendance, si tu sais qu’elles comportent des bugs, par exemple.

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

C’est là qu’intervient la fusion automatique

Ouvrir des tas de PR de manière automatisée ne va guère te faciliter la vie ni maintenir tes dépendances à jour sans effort. Il faut donc associer un outil comme Dependabot à un autre qui propose des files d’attente de fusion et la possibilité de fusionner automatiquement les pull requests répondant à certains critères. J’ai utilisé Mergify, mais il est probable que, dans un futur 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 (en « squash-merge ») toutes les pull requests émises par Dependabot et qui ont été compilées avec succès sur Upsun Cloud.

Comme je l’ai déjà mentionné, cette expérience est destinée à être utilisée via l’intégration de GitHub avec Upsun Cloud. Cela permet à chaque PR générée par Dependabot d’être associée à un environnement de test où auront lieu la compilation et le déploiement de l’application avec les dépendances mises à jour. Grâce à l’intégration avec GitHub, ce processus est ajouté en tant que 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 t’empêche d’utiliser des conditions d’status-successs supplémentaires dans la configuration, comme des tests unitaires exécutés par un CI ou d’autres éléments de ce genre. Plus tu as 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 grâce à Upsun et aux outils d’automatisation

En combinant des outils comme Dependabot, Mergify et Upsun Cloud, tu bénéficies d’un niveau bien plus élevé de contrôle et d’assurance sur ton processus de mises à jour automatisées du cœur de WordPress, des plugins, des thèmes et des fichiers de traduction. En effet, pour chaque mise à jour, tu peux être certain qu’un environnement similaire à celui de production sera créé avec les modifications, et que des tests supplémentaires pourront être effectués pour vérifier que tout fonctionne toujours parfaitement. Tu peux choisir de mettre à jour automatiquement uniquement les versions mineures ou aussi les versions majeures. Tu peux exclure des versions spécifiques ou des éléments précis (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é accru.

Développements ultérieurs

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, à condition que les conditions soient réunies (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.

Mais pour vraiment passer à la vitesse supérieure, tu peux automatiser les mises à jour de l’infrastructure ! Il te suffit de trouver un moyen de vérifier s’il y a une nouvelle version de l’un des services gérés par Upsun Cloud que tu utilises dans ton projet, puis de créer une nouvelle PR avec la mise à jour (exactement 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 de CI externe, comme GitHub Actions), tu pourrais alors configurer Mergify pour qu’il fusionne automatiquement ces PR, là encore, si les conditions sont réunies.

Lance l'automatisation de ton processus de développement WordPress avec Upsun Cloud

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

• Fais un fork de cette expérience sur GitHub
• Crée un nouveau projet Upsun Cloud
• Lie ton dépôt forké au projet nouvellement créé via notre intégration GitHub (ça nécessite d’installer 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 « à l'état brut » sur Upsun Cloud