Automatiser sauvegardes et déploiements WordPress avec GitHub Actions et WP-CLI

Automatiser les tâches répétitives d’un site WordPress — sauvegardes, migrations ou déploiements — permet de réduire les erreurs manuelles et d’accroître la fiabilité des mises à jour. Ce guide explique comment assembler GitHub Actions et WP-CLI pour créer un flux sécurisé et reproductible, adaptable à un site hébergé chez un prestataire ou sur un VPS.

Résumé

Nous verrons les prérequis, la structure d’un workflow GitHub Actions pour sauvegarder la base et les fichiers, des exemples d’exécution WP-CLI à distance, et des recommandations de sécurité pour stocker les secrets et tester en continu.

1. Préparer l’environnement et les prérequis

Avant d’automatiser, vérifiez ces points :

• Accès SSH au serveur avec au moins un utilisateur disposant des droits nécessaires pour lire/écrire les fichiers du site et exécuter WP-CLI.
• WP-CLI installé sur le serveur ou capacité à l’installer via le workflow (ex. exécution de commandes distantes via SSH).
• Un dépôt Git hébergeant le thème, les plugins personnalisés et la configuration (ne pas stocker les données sensibles en clair dans le dépôt).
• Variables d’environnement et secrets configurés dans l’interface GitHub (clé SSH, hôte, utilisateur, chemin du site).

2. Architecture recommandée d’un workflow

Idée générale : séparer les workflows selon la nature de l’action.

• Workflow « sauvegarde » : déclenché manuellement (workflow_dispatch) ou périodiquement (schedule). Il exporte la base de données, archive les fichiers importants et transfère les archives vers un stockage externe ou un serveur de stockage.
• Workflow « déploiement » : déclenché par un push sur une branche spécifique (ex. main). Il synchronise les fichiers nécessaires et exécute les commandes WP-CLI post-déploiement (purge des caches, mise à jour des modules, flush des permaliens).
• Workflow « test » : exécute des contrôles rapides (lint du code, tests d’intégration) avant un déploiement.

Cette séparation réduit les risques et facilite le diagnostic.

3. Exemple de workflow : sauvegarde de la base et des fichiers

Un workflow de sauvegarde typique exécute :

• Connexion SSH au serveur
• Export de la base via WP-CLI : wp db export /tmp/site-export.sql
• Archivage des fichiers critiques (wp-content, uploads) : tar -czf /tmp/site-files.tar.gz wp-content
• Transfert des archives vers un emplacement sécurisé (S3, stockage distant, serveur secondaire)

Garder les commandes simples et idempotentes aide à relancer un job en cas d’échec.

4. Exemple de workflow : déploiement avec synchronisation et WP-CLI

Pour un déploiement, privilégiez une synchronisation incrémentale (rsync) pour les fichiers et l’exécution contrôlée de WP-CLI :

• Vérifier la branche et exécuter des tests locaux.
• Transférer les fichiers modifiés via rsync : rsync -avz --delete ./dist/ user@host:/var/www/site/
• Sur le serveur, exécuter les commandes WP-CLI nécessaires :
  • wp plugin update --all (si la politique de déploiement le permet)
  • wp cache flush
  • wp rewrite flush pour réinitialiser les permaliens si besoin

Évitez d’exécuter des mises à jour automatiques de plugins sur un site en production sans tests : préférez d’abord un environnement de staging.

5. Sécurité et gestion des secrets

La sécurité est essentielle :

• Ne stockez jamais de clés ou mots de passe en clair dans le dépôt. Utilisez les secrets GitHub (ou l’équivalent) pour la clé SSH, l’hôte et l’utilisateur.
• Restreignez la clé SSH à l’accès nécessaire (utilisateur dédié, pas root) et limitez l’adresse IP si possible.
• Privilégiez des comptes avec droits minimaux pour les tâches automatisées.
• Considérez des sauvegardes chiffrées et rotation des clés sur un calendrier défini.

6. Bonnes pratiques et conseils concrets

• Testez d’abord sur un environnement de staging identique à la production.
• Écrivez des scripts idempotents : relancer le workflow ne doit pas corrompre l’état du site.
• Conservez l’historique des sauvegardes et automatisez leur purge après une période définie.
• Surveillez les logs des workflows et configurez des notifications en cas d’échec.
• Documentez le processus dans le dépôt pour que l’équipe comprenne les actions automatisées.

Conclusion actionnable

Pour démarrer aujourd’hui :

1. Créez des secrets GitHub : clé SSH dédiée, hôte, utilisateur, et chemin du site.
2. Élaborez un petit workflow de sauvegarde (workflow_dispatch) qui exporte la base et archive wp-content vers /tmp, puis transfère vers un stockage externe.
3. Testez le workflow sur un serveur de staging et validez les archives.
4. Ajoutez un workflow de déploiement simple basé sur rsync, puis introduisez progressivement des étapes WP-CLI.

Ces étapes vous permettront d’automatiser de façon sûre et maîtrisée sans bouleverser vos processus existants.

FAQ

Faut‑il exécuter WP-CLI depuis GitHub Actions ou depuis le serveur ?
Il est généralement plus simple et sûr d’exécuter WP-CLI sur le serveur (via SSH) pour des commandes dépendant de l’environnement (chemins, permissions, extensions).

Que stocker dans le dépôt ?
Thèmes et plugins personnalisés, scripts de build et configuration ; jamais les données sensibles ou exports de base.

Comment tester sans risque ?
Utilisez un environnement de staging identique et automatisez les tests avant tout passage en production.