# Un environnement éphémère par pull request pour vos projets WordPress > Base clonée, URL dédiée, destruction automatique à la fermeture : l'architecture d'un site de recette généré pour chaque pull request. - Auteur : Clément Hadrot - Publié le : 2022-02-03 - Mis à jour le : 2022-02-03 - Catégorie : Outils & workflow - URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/environnements-ephemeres-pull-request/ ## L’essentiel - Un site complet créé à l'ouverture de chaque pull request - URL prévisible générée à partir du numéro de PR - Destruction automatique à la fermeture, sans intervention manuelle La revue d'une fonctionnalité WordPress se heurte souvent à un problème pratique : le relecteur doit-il cloner la branche en local pour juger visuellement un changement ? Sur un environnement staging unique et partagé, chaque pull request écrase le travail de la précédente, forçant l'équipe à se coordonner pour ne jamais tester deux fonctionnalités en même temps. L'environnement éphémère par pull request résout ce problème structurellement : chaque PR obtient son propre site complet, accessible par une URL dédiée, détruit automatiquement à la fermeture. Cette architecture ne remplace pas un environnement de staging permanent, réservé à la validation finale avant production — les deux répondent à des besoins différents et coexistent généralement sur un même projet. ## Vue d'ensemble de l'architecture > L'essentiel à retenir : Un site complet créé à l'ouverture de chaque pull request ; URL prévisible générée à partir du numéro de PR ; Destruction automatique à la fermeture, sans intervention manuelle ``` ┌─────────────────────────────────────────────┐ │ GitHub Actions / GitLab CI │ │ │ │ PR ouverte (#142) │ │ └─▶ Créer namespace / dossier pr-142 │ │ └─▶ Cloner la base de référence │ │ └─▶ Déployer les fichiers de la branche │ │ └─▶ wp search-replace vers pr-142.rec.fr │ │ └─▶ Commenter la PR avec le lien │ │ │ │ PR mise à jour (nouveau commit) │ │ └─▶ Redéployer uniquement les fichiers │ │ │ │ PR fermée / mergée │ │ └─▶ Supprimer le dossier et la base │ │ └─▶ Supprimer le sous-domaine DNS │ └─────────────────────────────────────────────┘ ``` Trois briques techniques suffisent à construire ce système : un serveur capable d'accueillir plusieurs installations WordPress isolées, un pipeline CI déclenché par les événements de pull request, et une convention de nommage prévisible pour les URLs générées. ## Créer l'environnement à l'ouverture de la PR Le pipeline, déclenché sur l'événement `pull_request` de type `opened`, exécute une série d'étapes sur le serveur de recette : ``` name: Environnement PR on: pull_request: types: [opened, synchronize, closed] jobs: deploy-preview: if: github.event.action != 'closed' runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Déployer l'environnement de PR run: | ssh deploy@recette.mon-agence.fr " mkdir -p /var/www/pr-${{ github.event.number }} && rsync -a --exclude=wp-content/uploads /var/www/base-reference/ /var/www/pr-${{ github.event.number }}/ && wp db create --path=/var/www/pr-${{ github.event.number }} --allow-root && wp db import /var/www/base-reference/reference.sql --path=/var/www/pr-${{ github.event.number }} --allow-root && wp search-replace 'base-reference.rec.fr' 'pr-${{ github.event.number }}.rec.fr' --path=/var/www/pr-${{ github.event.number }} --allow-root " ``` Un serveur web (nginx) configuré avec un bloc générique par sous-domaine, associé à une entrée DNS wildcard `*.rec.mon-agence.fr`, évite d'avoir à créer manuellement une configuration serveur à chaque nouvelle pull request. ## Commenter la pull request avec le lien Une action de commentaire automatique améliore nettement l'expérience de revue, en évitant à chacun de deviner l'URL générée : ``` - name: Commenter la PR uses: actions/github-script@v7 with: script: | github.rest.issues.createComment({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, body: `Environnement de recette disponible : https://pr-${context.issue.number}.rec.mon-agence.fr` }) ``` ## Détruire l'environnement à la fermeture Symétriquement, un job déclenché sur l'événement `closed` — qu'il s'agisse d'une fermeture volontaire ou d'un merge — nettoie l'ensemble des ressources créées : ``` destroy-preview: if: github.event.action == 'closed' runs-on: ubuntu-latest steps: - name: Détruire l'environnement de PR run: | ssh deploy@recette.mon-agence.fr " wp db drop --path=/var/www/pr-${{ github.event.number }} --yes --allow-root && rm -rf /var/www/pr-${{ github.event.number }} " ``` Sans cette étape symétrique, le serveur de recette accumule silencieusement des dizaines d'installations orphelines, chacune consommant de l'espace disque et, plus problématique, une entrée de base de données jamais nettoyée. ## Limites et points de vigilance - Le coût en ressources serveur croît avec le nombre de pull requests ouvertes simultanément — un serveur dédié suffisamment dimensionné est nécessaire pour une équipe active - Les emails transactionnels doivent être interceptés (avec un outil comme Mailhog ou Mailpit) pour éviter qu'un test sur un environnement éphémère n'envoie un vrai email à un client - Les webhooks externes (paiement, CRM) doivent pointer vers des environnements de test dédiés, jamais vers les intégrations réelles de production > Le vrai gain de cette architecture n'est pas seulement le confort de revue : c'est la disparition des conflits de staging, cette situation classique où deux développeurs se marchent dessus sans le savoir sur un environnement partagé. ## En résumé Un environnement éphémère par pull request transforme la revue de code WordPress en expérience réellement autonome : chaque changement s'évalue isolément, sans dépendre de la disponibilité d'un environnement partagé ni de la coordination d'équipe. La mise en place initiale demande un investissement réel en scripts CI, mais elle se rembourse rapidement sur un projet avec plusieurs contributeurs actifs et un rythme de pull requests soutenu.