La prévisualisation statique par branche via Cloudflare Pages, déjà détaillée pour un thème, convient à la revue purement visuelle. Elle atteint vite ses limites dès qu’une pull request touche à une extension métier, à un formulaire dynamique, ou à une logique d’administration : rien de tout cela ne fonctionne dans un export HTML figé. Pour ces cas, l’agence a construit un système d’environnement éphémère complet, avec base de données et back-office WordPress fonctionnels, par pull request.
Ce système tourne sur un cluster Kubernetes déjà utilisé par l’agence pour d’autres charges, ce qui explique le choix de cette orchestration plutôt qu’une solution plus légère : la mutualisation de l’infrastructure existante réduisait le coût marginal de chaque nouvel environnement.
Ce qu’un environnement complet doit reproduire
Contrairement à un export statique, un environnement de preview fonctionnel doit fournir : une base de données MySQL propre à cette pull request, un WordPress avec le code de la branche déployé, un jeu de données de test importé automatiquement, et une URL publique temporaire accessible par le client sans configuration de son côté.
Architecture générale
PR ouverte
│
▼
┌─────────────────────────────┐
│ Job CI : construction image │
│ Docker de la branche │
└──────────────┬───────────────┘
▼
┌─────────────────────────────────────┐
│ Namespace Kubernetes éphémère │
│ pr-1842 │
│ │
│ ┌──────────┐ ┌──────────────────┐ │
│ │ MySQL │◀──│ WordPress (pod) │ │
│ │ (pod) │ │ + jeu de données │ │
│ └──────────┘ └────────┬──────────┘ │
│ │ │
│ ┌─────────▼─────────┐ │
│ │ Ingress │ │
│ │ pr-1842.preview... │ │
│ └────────────────────┘ │
└────────────────────────────────────────┘
Créer le namespace et déployer
À l’ouverture d’une pull request, un workflow GitHub Actions génère un namespace Kubernetes dédié, nommé d’après le numéro de PR, et y déploie les ressources nécessaires via un chart Helm paramétré :
name: Preview complète
on:
pull_request:
types: [opened, synchronize, reopened]
jobs:
deployer-preview:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Construire l'image
run: |
docker build -t registre.agence.example/preview/pr-${{ github.event.number }}:latest .
docker push registre.agence.example/preview/pr-${{ github.event.number }}:latest
- name: Déployer via Helm
run: |
helm upgrade --install pr-${{ github.event.number }} ./charts/wordpress-preview \
--namespace preview-pr-${{ github.event.number }} \
--create-namespace \
--set image.tag=latest \
--set ingress.host=pr-${{ github.event.number }}.preview.agence.example \
--set database.dataset=jeu-de-test-standard
- name: Commenter la PR avec l'URL
uses: actions/github-script@v7
with:
script: |
github.rest.issues.createComment({
...context.repo,
issue_number: context.issue.number,
body: `Preview complète disponible : https://pr-${{ github.event.number }}.preview.agence.example (admin/admin)`
});
Le jeu de données standard
Le chart Helm inclut un job d’initialisation qui importe un export WXR de référence et active systématiquement le même compte administrateur de test, avec des identifiants volontairement faibles puisque l’environnement reste isolé du reste du réseau et détruit rapidement. Cette standardisation évite de reconstruire un jeu de données différent à chaque preview, au prix d’une fidélité moindre aux données réelles du client, un compromis assumé pour ce cas d’usage.
Détruire automatiquement à la fermeture
Un environnement de preview qui survit indéfiniment finit par consommer des ressources sans justification et par accumuler des données de test obsolètes. Un second workflow, déclenché à la fermeture ou à la fusion de la pull request, supprime intégralement le namespace :
on:
pull_request:
types: [closed]
jobs:
detruire-preview:
runs-on: ubuntu-latest
steps:
- name: Supprimer le namespace
run: |
kubectl delete namespace preview-pr-${{ github.event.number }} --ignore-not-found
Une sécurité supplémentaire, un job planifié quotidien, supprime tout namespace préfixé preview-pr- vieux de plus de sept jours, au cas où le workflow de fermeture n’aurait pas pu s’exécuter correctement pour une raison quelconque.
Maîtriser le coût par preview
Chaque environnement reçoit des limites de ressources Kubernetes strictes, un quart de vCPU et 256 Mo de mémoire pour le pod WordPress, autant pour MySQL, suffisant pour une revue fonctionnelle mais pas pour un test de charge. Sur une période où l’agence maintenait en moyenne huit previews actives simultanément, la consommation additionnelle de ressources sur le cluster est restée marginale par rapport à la charge de production déjà hébergée.
Une preview qui n’expose que le rendu visuel ne convainc jamais un client qui veut tester un formulaire ou explorer le back-office : à un moment, il faut lui donner un vrai WordPress qui répond.
En résumé
Ce système d’environnement éphémère complet répond à un besoin que le simple export statique ne couvre pas : valider une fonctionnalité dynamique, un plugin, un formulaire, avant fusion d’une pull request. Il demande une infrastructure Kubernetes déjà en place pour rester économiquement raisonnable ; sur une agence sans cluster existant, l’investissement initial ne se justifierait probablement pas pour ce seul usage.
