Déployer sur un hébergement mutualisé sans pipeline : la méthode qui tient

lftp -c "mirror -R --only-newer --exclude-glob wp-content/uploads/ ./build/ /www/wp-content/themes/mon-theme/" : cette ligne, une fois bien réglée, a remplacé des mois d’hésitation sur la meilleure façon de déployer un thème chez un client qui refuse catégoriquement tout pipeline d’intégration continue, préférant un hébergement mutualisé classique sans accès SSH complet ni Git côté serveur.

Sans GitLab CI ni Bitbucket Pipelines envisageables sur ce type d’hébergement, la tentation aurait été de revenir au glisser-déposer manuel via un client FTP graphique, avec tous les risques que cela comporte : fichier oublié, dossier uploads écrasé par erreur, ou pire, un fichier de configuration de production remplacé par sa version de développement. La méthode retenue automatise ce transfert sans pour autant nécessiter d’infrastructure de déploiement complexe.

Pourquoi lftp plutôt qu’un client FTP graphique

lftp est un client en ligne de commande qui gère le protocole FTP avec un mode miroir capable de comparer les fichiers locaux et distants avant de ne transférer que ceux qui ont réellement changé. Contrairement à un glisser-déposer manuel, cette comparaison élimine le risque d’oublier un fichier modifié ou de retransférer inutilement l’ensemble du thème à chaque déploiement.

#!/usr/bin/env bash
set -euo pipefail

DOSSIER_LOCAL="./build/"
DOSSIER_DISTANT="/www/wp-content/themes/mon-theme/"

lftp -u "$FTP_UTILISATEUR","$FTP_MOT_DE_PASSE" "$FTP_HOTE" <<EOF
mirror --reverse --only-newer \
  --exclude-glob wp-content/uploads/ \
  --exclude-glob .env \
  "$DOSSIER_LOCAL" "$DOSSIER_DISTANT"
bye
EOF

Le paramètre --only-newer compare les dates de modification avant transfert, ce qui réduit un déploiement de thème modifié à quelques dizaines de secondes en moyenne sur ce projet, contre plusieurs minutes pour un transfert complet du dossier.

Ce que le script protège explicitement

Deux exclusions se sont révélées indispensables dès les premiers essais. La première protège le dossier wp-content/uploads/, qui ne doit jamais être écrasé par le contenu du dépôt local, puisqu’il contient les médias ajoutés en production, absents du dépôt de code source. La seconde exclut tout fichier de configuration sensible qui pourrait exister localement à des fins de test, pour éviter qu’il n’écrase la configuration réelle du serveur de production.

Une sauvegarde du dossier distant, via une archive compressée générée juste avant le transfert par une tâche cron côté hébergeur, complète ce dispositif. Sans accès SSH complet pour scripter cette sauvegarde depuis la machine de déploiement elle-même, elle a été déléguée à l’outil de sauvegarde déjà fourni par l’hébergeur mutualisé, déclenché automatiquement avant chaque fenêtre de déploiement prévue.

Étapes du déploiement, dans l’ordre

1. Compiler le thème localement (assets, minification) dans le dossier build/
2. Déclencher la sauvegarde côté hébergeur, ou vérifier qu’elle vient de s’exécuter
3. Lancer le script lftp en mode miroir avec les exclusions définies
4. Vérifier manuellement le site en production après transfert, faute de tests automatisés possibles sur cet hébergement

Ce qui reste malgré tout fragile dans cette méthode

Sans possibilité d’exécuter de tests automatisés côté serveur, la vérification finale reste manuelle, ce qui introduit un facteur humain que n’aurait pas un pipeline classique. Pour limiter ce risque, une checklist courte a été rédigée pour cette vérification post-déploiement : ouverture de la page d’accueil, d’une fiche produit type et du formulaire de contact, dans cet ordre précis, avant de considérer le déploiement comme terminé.

Un second point de fragilité concerne les identifiants FTP eux-mêmes, stockés dans des variables d’environnement sur la machine qui exécute le script plutôt que dans le script lui-même, pour éviter qu’ils ne se retrouvent un jour dans un dépôt Git par inadvertance. Cette précaution, banale sur un pipeline d’intégration continue, demande ici une vigilance supplémentaire puisque rien ne l’impose techniquement.

L’absence de pipeline ne dispense pas de rigueur : elle impose au contraire de scripter soigneusement ce qu’un pipeline aurait automatisé par défaut.

En résumé

Un déploiement par FTP n’a rien d’archaïque tant qu’il reste scripté et reproductible. Sur cet hébergement mutualisé sans accès à un pipeline, lftp en mode miroir, associé à des exclusions précises et à une sauvegarde systématique avant transfert, offre une fiabilité proche de celle d’un pipeline complet, pour une fraction de sa complexité de mise en place.