Un flux de travail 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 création de solutions CMS pour les entreprises était ma principale activité. 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 des applications 12 facteurs. La manière 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 évolué est que le même code est vérifié dans un système de gestion de code source de choix, avec un outil CI le déplaçant vers les serveurs de l'hébergement.

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 cœur de WordPress, et étendues plus tard aux plugins, thèmes et fichiers de traduction. Bien qu'un certain degré d'automatisation des mises à jour soit certainement souhaitable, la manière dont cela est implémenté dans WordPress (c'est-à-dire les mises à jour in situ) signifie que si votre base de code est dans un dépôt, elle sera rapidement obsolète, et vous devrez gérer les mises à jour dans le dépôt à côté, pour éviter des problèmes et des régressions à l'avenir. Si, au lieu de cela, vous gérez 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 vous garantir que les choses dégénéreront rapidement en un cauchemar.

Attendez, ce n'est pas tout

Cela devient plus compliqué. Pour citer à nouveau Chad dans le même article :

Cela devient plus compliqué. Pour citer encore Chad du 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 build hautement reproductible en conséquence de votre code et de son processus de build explicitement défini, le tout étant soumis au contrôle de version. [...] Le code externe (dépendances) [...] et idéalement les définitions de votre infrastructure elle-même sont soumis à des versions exactes afin que l'ensemble de votre processus DevOps, du début à la fin, soit répétable et reproductible. » 

C'est excellent aussi pour des raisons de sécurité. Pourtant, comme vous l'avez peut-être compris, cela entre complètement en conflit avec la façon dont WordPress gère les mises à jour automatiques, et celles-ci pourraient devoir être désactivées entièrement là où 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 offrir une approche plus moderne du développement WordPress, grâce également à 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 guide Déployer WordPress basé sur Composer sur Upsun de la documentation Upsun.

Maximiser l'automatisation avec un template 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 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 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 réussissent
• ont un nouveau code déployé en production automatiquement à chaque fusion de PR
• utiliser Redis comme cache en back-end
• utiliser Cloudflare comme CDN
• utiliser GitHub Actions comme CI/CD additionnel et Cron Scheduler

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 vise à automatiser le plus 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 basé sur Composer, reportez-vous à l'article de Chad ou directement au code dans mon dépôt.

Automatisation de l'installation de WordPress avec Distros et Composer

Les Distros ou profils d'installation sont essentiellement un moyen d'avoir votre propre configuration d'installation par défaut. Alors que certains logiciels ont un support intégré pour cela, WordPress ne l'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 deploy hook dans Upsun, c'est-à-dire après que la phase de build a téléchargé et construit WordPress et les autres dépendances via Composer. Le résultat sera une application WordPress entièrement installée, vous évitant d'avoir à passer par l'assistant de configuration WordPress manuel par défaut (bien que simple). 

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 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 de code plus tard, mais puisque nous avons référencé le script ci-dessus, je voulais souligner que le même script prend en charge la mise à jour de la base de données au cas où des mises à jour de code exigeraient une telle opération.

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 exécutera 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 bot émettra des pull requests périodiquement, é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 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 pull requests  ouvertes maximum à la fois. 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 l'ouverture automatique de PRs réalise-t-elle réellement les mises à jour automatiques des dépendances ? Eh bien, ce n'est pas le cas :)

Entrez dans l'auto-fusion

Ouvrir des tas de PR de manière automatisée ne vous facilitera guère la vie et ne maintiendra pas 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 capacité de fusionner automatiquement les requêtes de tirage qui répondent à certains critères. J'ai utilisé Mergify, mais il est probable que dans un futur proche vous puissiez utiliser les files d'attente de fusion 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 (squash-merge) 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évisualisation associé 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é.

Ceci, bien sûr, est une configuration très basique ; rien ne nous empêche d'utiliser des conditions status-success supplémentaires dans la configuration, qui pourraient être des tests unitaires exécutés par une CI et d'autres choses comme ça. Plus vous avez d'automatisation et de vérifications de statut, plus vous pouvez être sûr que la PR peut être fusionnée automatiquement.

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

La combinaison d'outils comme Dependabot, Mergify et Upsun vous offre un degré de contrôle et d'assurance beaucoup plus élevé sur votre processus de mises à jour automatisées pour le cœur de WordPress, les plugins, les thèmes et les fichiers de traduction. Cela est dû au fait que pour chaque mise à jour, vous pouvez être certain qu'un environnement de type production sera construit avec les modifications, et des tests supplémentaires peuvent être exécutés pour s'assurer que tout fonctionne toujours parfaitement. Vous pouvez décider si vous voulez mettre à jour automatiquement uniquement les versions mineures ou aussi les versions majeures. Vous pouvez exclure des versions spécifiques ou des éléments spécifiques (un plugin ou un thème particulier, par exemple). Et bien plus encore. Vous avez un contrôle précis, plus de puissance et un degré d'assurance plus élevé.

Développements futurs

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, une de façon de vraiment passer à un niveau supérieur serait 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 par Upsun 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.

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

Pendant que vous attendez la possibilité de mettre à niveau automatiquement votre infrastructure (en fait, je promets que je mettrai à jour mon modèle avec cette même fonctionnalité dès qu'il sera possible de le faire), 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