Déployer WordPress sans interruption avec Trellis : le principe des déploiements atomiques

Dans l’écosystème WordPress, on voit encore très souvent des mises en production via FTP, rsync ou des mécanismes “one-click” côté hébergeur. Ça marche… jusqu’au jour où un utilisateur tombe au mauvais moment sur un mélange de fichiers anciens et nouveaux, ou qu’un déploiement se passe mal et qu’il faut improviser un retour arrière.

Trellis (le stack serveur + déploiement de Roots) apporte une approche beaucoup plus proche de ce qu’on pratique sur des apps modernes : le déploiement atomique. Concrètement, le site continue de répondre normalement pendant toute la préparation de la nouvelle release, puis on bascule d’un coup sur la nouvelle version. Pas d’état intermédiaire, pas de site “à moitié mis à jour”.

Zéro downtime : de quoi parle-t-on exactement ?

Un déploiement “zéro downtime” vise un objectif simple : le site reste accessible et fonctionnel pendant toute la mise en production. La nuance est importante : on ne parle pas seulement d’éviter une coupure serveur, mais aussi d’éviter les erreurs applicatives causées par un code déployé partiellement.

Dans un déploiement classique WordPress, tu remplaces des fichiers à la volée. Pendant quelques secondes (ou minutes), PHP peut charger une partie de l’ancien code et une partie du nouveau. C’est typiquement là qu’apparaissent des erreurs fatales, des classes introuvables, ou des incohérences côté assets.

Pourquoi les déploiements WordPress “traditionnels” posent problème

Les stratégies les plus courantes ont toutes le même défaut : elles modifient le code en place (in-place) alors que le site est en train de servir du trafic.

• FTP : upload manuel, écrasement des fichiers existants. C’est lent et le risque d’incohérence est élevé pendant l’envoi.
• Synchronisation (ex. rsync) : plus rapide, mais on reste sur de la copie/écrasement pendant que l’application tourne.
• Déploiement via plugin / outil de l’hébergeur : pratique, mais généralement sans vraie isolation de release ni mécanisme de rollback fiable et immédiat.

Résultat : pendant la fenêtre de déploiement, le site peut se comporter de manière imprévisible. Et si ça casse, le rollback dépend souvent d’une sauvegarde, d’un zip, ou d’un “on remet les fichiers d’avant” à la main.

La solution Trellis : déploiements atomiques et immuables

Trellis applique une stratégie atomique : la nouvelle version est préparée dans un répertoire isolé, puis un simple switch (quasi instantané) fait pointer le site vers cette nouvelle release.

On parle aussi de déploiement immutable (immuable) : une fois une release déployée, ses fichiers ne sont pas modifiés. Chaque déploiement crée un nouveau répertoire de release complet. Ça change tout pour la fiabilité… et pour le rollback.

La structure de répertoires sur le serveur

Lors d’un déploiement, Trellis met en place une arborescence stable. Le serveur web (Nginx, dans Trellis) sert toujours le site via un répertoire current/ qui n’est en réalité qu’un symlink (lien symbolique) vers la release active.

/srv/www/example.com/
├── current/             # Symlink vers la release active
├── releases/            # Historique des releases déployées
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # La plus récente
├── shared/              # Éléments partagés entre releases
│   └── uploads/
└── logs/

/srv/www/example.com/
├── current/             # Symlink vers la release active
├── releases/            # Historique des releases déployées
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # La plus récente
├── shared/              # Éléments partagés entre releases
│   └── uploads/
└── logs/

Le point clé, c’est current. Tant que le symlink n’a pas basculé, tes visiteurs restent sur l’ancienne release, intacte.

Ce qui se passe lors d’un trellis deploy production

Quand tu lances la commande de déploiement, Trellis orchestre une suite d’étapes (automatisées) pour construire une release complète avant de basculer.

• Initialize : vérifie/crée l’arborescence et prépare un nouveau dossier de release horodaté.
• Update : récupère le dernier code depuis ton dépôt Git dans un répertoire source séparé (hors du site servi).
• Prepare : copie les fichiers vers le dossier de release cible.
• Build : exécute composer install pour installer les dépendances PHP.
• Share : relie (symlink) les éléments partagés — typiquement uploads — depuis shared/ vers la nouvelle release.
• Finalize : bascule le symlink current vers la nouvelle release.

Ce dernier point est la bascule atomique : on passe d’une release à l’autre sans période de “mix” entre deux versions.

Et la base de données dans tout ça ?

Point à ne pas rater : Trellis gère le zéro downtime côté fichiers / code. En revanche, les changements de schéma en base (migrations) ne sont pas inclus automatiquement dans un déploiement Trellis.

Database migrations to a new schema are not included as part of a Trellis deploy.

Trellis documentation (Roots)

Si tu utilises Acorn (le runtime Laravel-like pour WordPress côté Roots), tu peux créer des migrations de style Laravel et les exécuter dans ton processus de déploiement, mais c’est un sujet distinct : il faut gérer la compatibilité entre ancienne et nouvelle version (migrations “forward compatible”, phase de transition, etc.).

Rollback intégré : revenir en arrière en quelques secondes

L’autre bénéfice immédiat des releases immuables, c’est le rollback. Comme chaque version existe déjà sur disque, revenir à la release précédente revient à… repointer current vers l’ancien dossier.

trellis rollback production

trellis rollback production

Par défaut, Trellis conserve les cinq releases les plus récentes sur le serveur. En cas de souci après déploiement (bug, dépendance cassée, config manquante), tu as une marche arrière simple et rapide, sans restauration lourde.

Hooks de déploiement : adapter Trellis à ton pipeline

Dans la pratique, on a rarement un déploiement “nu”. Purge de cache, backup, notifications, smoke tests… Trellis expose des hooks (points d’extension) pour injecter tes tâches au bon moment. Un hook, ici, c’est un mécanisme qui permet d’exécuter des actions avant/après une étape donnée.

• deploy_build_before / deploy_build_after : ajouter des étapes de build (assets, validations, etc.).
• deploy_finalize_before / deploy_finalize_after : tâches juste avant/après la bascule (purge cache, warmup, etc.).
• Hooks par étape majeure : initialize, update, prepare, build, share, finalize.

Ça permet notamment d’automatiser des patterns utiles : sauvegarde de base avant déploiement, purge de caches applicatifs/CDN, envoi de notifications à l’équipe, ou exécution de smoke tests sur la release fraîchement préparée.

Démarrer rapidement : Trellis juste pour le déploiement

L’angle intéressant, c’est qu’il n’est pas nécessaire d’adopter Trellis pour tout ton workflow local. Beaucoup de teams l’utilisent surtout pour profiter du déploiement atomique vers des hébergeurs managés (par exemple Kinsta) ou via des outils comme RunCloud, tout en gardant leur environnement local habituel (Valet, Lando, DDEV, etc.).

1. Structurer le projet avec Bedrock (organisation plus propre d’un projet WordPress).
2. Installer Trellis et configurer les paramètres de déploiement.
3. Renseigner wordpress_sites.yml avec les infos du dépôt Git à déployer.
4. Lancer le déploiement en production avec trellis deploy production.

Le premier déploiement est généralement le plus long (mise en place de l’arborescence, installation des dépendances). Ensuite, les déploiements deviennent plus rapides — et surtout beaucoup plus prévisibles côté disponibilité.

À retenir

• Le “zéro downtime” côté WordPress, c’est surtout éviter l’état intermédiaire où le site sert un mélange de fichiers.
• Trellis y arrive via des releases isolées et un symlink current qui bascule instantanément.
• Les releases étant immuables, le rollback devient une opération simple et rapide.
• La base de données reste un sujet à part : migrations à gérer explicitement (Acorn peut aider).
• Les hooks de Trellis permettent d’intégrer les étapes indispensables à un vrai pipeline de prod.