C’est une évidence, un site n’a pas vocation à rester sur notre machine de dev. Nous allons donc explorer les différentes manières d’exécuter WordPress pendant le développement et comment le déployer en prod.

Si vous utilisez DevKinsta avec Kinsta par exemple, le deploy s’effectue de manière totalement transparente, c’est la voie royale. Cependant, explorons les différentes manières de procéder.

À la mano

Pour un premier deploy, on peut se contenter de copier tout le répertoire WordPress depuis le local vers le serveur de prod. Soit vous le faites à la main avec un logiciel FTP comme FileZilla par exemple, soit vous aimez la CLI et dans ce cas, un petit coup de rsync accélère les choses.

Pour le rsync, un exemple de commande pourra peut-être vous aider. Dans l’exemple qui suit, j’exclue le package.json ainsi que le package-lock.json, les node_modules, l’historique Git, les fichiers sources Less et les .DS_Store – qui sont des fichiers créés par macOS et qui ne servent à rien sur le serveur (à moduler si vous n’êtes pas sur Mac). Tous ces fichiers n’ont rien à faire sur le serveur.

# La commande est ici lancée depuis le réprertoire WordPress ;
# d'où le "." qui sera à remplacer par le path si vous lancez la commande depuis un autre endroit
rsync -rv --exclude=.git --exclude=.DS_Store --exclude=node_modules --exclude=package*.json --exclude=*.less . SERVER_USER@SERVER_ADDR:SERVER_PATH

Pour la base de données, wp-cli to the rescue.

# En local on exporte la base
php wp-cli db export --add-drop-table dump.sql

# Une fois sur le serveur, on l'importe
php wp-cli dump.sql

# Sans oublier de modifier l'url du site
search-replace 'http://devURL' 'https://prodURL'

En général, on dumpera donc la base avant d’effectuer le rsync, de cette manière, on aura plus qu’à l’importer avec la wp-cli une fois connecté sur le serveur.

En dernier lieu, on remplacera les informations de la base de données dans le wp-config.php (ou le .env selon votre cas) sur le serveur.

Les deploys quotidien

Nous venons de parler du premier deploy dans lequel il faut tout migrer. Cependant, la plupart du temps, on travaille dans le thème et nous n’avons besoin que de mettre à jour les fichiers du thème.

Dans ce cas, rsync est clairement votre ami. D’ailleurs, c’est tellement pratique que dans Steroids, la commande est intégrée au package.json, de telle manière qu’un simple npm run deploy mettra le thème à jour.

Par ailleurs, comme les navigateurs mettent en cache les assets, si vous faites des modifications qui impactent le CSS et/ou le JavaScript, il peut être judicieux d’adopter une stratégie de cache invalidation. Dans ce contexte, on change le nom des assets afin que le navigateur soit obligé de télécharger les nouvelles versions.

Avec Steroids, cela s’effectue très simplement. Le projet porte un numéro de version de type MAJEUR.MINEUR.CORRECTIF. Il s’agit de la convention SemVer.

npm version patch // correction de bug
npm version minor // version mineure
npm version major // version majeure

// Il suffit ensuite de deploy et le tour est joué
npm run deploy

L’automatisation

Si vous utilisez Steroids et des outils de versioning qui permettent la CI/CD, tels que GitLab ou GitHub, vous pouvez automatiser vos deploy. Lorsque j’effectue un merge sur la branche master de mon dépôt, la dernière version de mon code est automatiquement déployée sur le serveur.

GitLab

Si vous utilisez GitLab, il faut placer un fichier .gitlab-ci.yml à la racine du projet.

image: debian

# On met en cache nos dépendances pour accélérer les deploy ultérieurs
cache:
  paths:
    - vendor/
    - public/themes/steroids/node_modules/

before_script:
  - apt-get update
  - apt-get install -y php php-mbstring unzip nodejs npm curl git rsync
  - curl -sS https://getcomposer.org/installer | php
  - php composer.phar config --global github-oauth.github.com $GITHUB_TOKEN
  - php composer.phar install
  - cd public/themes/steroids
  - npm ci
  - npm run build
  - cd ~/
  - mkdir -p .ssh
  - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > .ssh/config
  - echo "$SSH_PRIVKEY" > ~/.ssh/id_rsa && chmod 400 .ssh/id_rsa
  - cd /builds/Buzut/ && chmod -R 744 buzut/

deploy-prod:
  script:
    - rsync -zar buzut/ $SERVER:$SERVER_PATH --exclude=node_modules --exclude=public/uploads/ --exclude=.htaccess --delete
  only:
    - master

J’utilise ici l’image Docker Debian, j’y installe certaines dépendances qui ne sont pas présentes par défaut et je lance le build. Une fois cela fait, je configure SSH afin que le serveur de deploy puisse se connecter à mon serveur web et je transfère le tout via rsync.

Les variables sont déclarées depuis l’interface GitLab, cela permet évidemment de ne pas mettre dans le code des valeurs qui peuvent être confidentielles. Vous noterez que j’importe le GitHub token afin de pouvoir accéder aux plugins stockés dans des dépôts privés.

GitHub

Chez GitHub, depuis la racine, on créé un fichier .github/workflows/deploy.yml. deploy semble explicite mais vous pouvez le nommer de la manière qui vous plaît. En effet, tous les fichiers dans workflows/ sont exécutés.

name: Deploy website

on:
  push:
    branches: [ master ]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-node@v2

    - name: add private composer secret key
      run: composer config --global github-oauth.github.com ${{ secrets.COMPOSER_PRIVATE_KEY }}

    # On met en cache nos dépendances pour accélérer les deploy ultérieurs
    - name: Cache packages
      id: composer-cache
      uses: actions/cache@v2
      with:
        path: |
          vendor
          public/themes/steroids/node_modules/
        key: ${{ runner.os }}-${{ hashFiles('**/composer.lock') }}-${{ hashFiles('**/package-lock.json') }}

    - name: Install php dependencies
      run: composer install --prefer-dist --no-progress

    - name: Build front
      working-directory: public/themes/steroids/
      run: npm ci && npm run build

    - name: Create SSH key
      run: |
        mkdir -p ~/.ssh/
        echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
        echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa
        sudo chmod 600 ~/.ssh/id_rsa
      shell: bash
      env:
        SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVKEY }}

    - name: Deploy
      run: rsync -zarv $GITHUB_WORKSPACE/ ${{ secrets.SERVER_HOST }}:${{ secrets.SERVER_PATH }} --exclude=.git --exclude=node_modules --exclude=public/uploads/ --exclude=.htaccess --delete
      shell: bash

La procédure est ici sensiblement la même, seule la syntaxe diffère. Notez que si vous utilisez Steroids, soit votre hébergeur propose un environnement pour configurer les variables d’environnement, soit il vous faudra également déployer un fichier .env.

Dans ce dernier cas, il vous suffira de stocker son contenu dans les variables d’environnement de GitHub ou GitLab et de le créer avant le deploy. Par exemple, pour GitHub, nous ajouterions simplement cette tâche.

  - name: Create .env file
    run: echo "${{ secrets.ENV }}" > .env

Si vous souhaitez en savoir plus sur les possibilités offertes par les Actions GitHub, la doc officielle est votre amie.

Enfin, notez que la GitLab CI et les GitHub Actions utilisent tous deux Docker. Vous pouvez donc utiliser n’importe quelle image du Docker Hub en lieu et place de debian et ubuntu-lastest que j’utilise ici.

La CLI c’est bon

On en parle assez peu, mais WordPress offre une interface en ligne de commande : WP-CLI. Cet outil d’une grande puissance permet d’effectuer des actions qu’il n’est pas possible – ou très fastidieux – de faire via l’admin.

Exporter et importer la base de données, rechercher et remplacer des occurrences dans les tables de la base, gérer les plugins, les images, les utilisateurs… bref, les possibilités sont grandes. Pour une prise en main rapide ou un aperçu des possibilités, je vous conseille la lecture de cet article qui passe en revue les commandes indispensable avec des exemples utiles.

Gérer la base de données

Migrer la base de données de manière atomique, quelle que soit l’application (WordPress ou autre), est toujours un peu tricky. Vos données de dev et de prod divergent : c’est normal et même parfois souhaitable.

Vous pouvez cependant, faire de temps en temps un dump de la base de prod et l’importer en dev pour avoir un jeu de données plus frais. À ce propos, je ne l’ai pas encore testé, mais il existe un plugin qui se propose de gérer tout cela avec Git directement au sein de WordPress : VersionPress.

Vous avez maintenant les clefs pour installer en local et déployer WordPress de manière automatique. Dans le prochain chapitre, nous allons nous pencher sur la sécurité.

Dans le prochain chapitre, nous allons apprendre à gérer l’AJAX afin d’améliorer l’expérience utilisateur.