Environnements de prévisualisation par branche : une copie déployée par pull request, détruite à la fusion

Objectif

Chaque pull request obtient une copie fonctionnelle et accessible de l'application sur sa propre URL, créée par le pipeline et supprimée lorsque la branche est fusionnée ou fermée, afin que relecteurs, testeurs et agents puissent exercer le changement au lieu de l'imaginer à partir du diff.

Prérequis

Un artefact déployable par commit (image de conteneur ou bundle statique), une infrastructure capable d'héberger de nombreuses petites copies à faible coût, et un schéma de nommage reliant le numéro de pull request au nom d'hôte. Les plateformes hébergées offrent cela pour les sites statiques et sans serveur : Netlify décrit ses aperçus de déploiement comme le déploiement des pull requests ou merge requests sur une URL unique avec un préfixe deploy-preview-<number>. Pour les services sur un cluster, les espaces de noms (namespaces) Kubernetes fournissent un mécanisme d'isolation de groupes de ressources au sein d'un même cluster, ce qui fait d'un espace de noms par pull request l'unité naturelle.

Étapes

1. Construire une seule fois par commit et étiqueter l'artefact avec le SHA du commit ; l'aperçu déploie cet artefact, jamais une reconstruction.
2. Dériver le nom de l'environnement du numéro de la pull request (pr-1234), pas du nom de la branche, qui peut contenir des caractères inadaptés aux noms d'hôte et peut être renommée.
3. Provisionner la copie : un espace de noms ou une stack, une base de données remplie à partir des données de départ locales (voir l'article associé), une configuration pointant vers des versions simulées ou en bac à sable des services tiers, et un enregistrement DNS générique avec un certificat correspondant, pour qu'aucun changement DNS par aperçu ne soit nécessaire.
4. Republier l'URL sur la pull request et l'enregistrer comme un déploiement. Les environnements GitHub portent des règles de protection de déploiement et des secrets propres à l'environnement, ce qui permet aux aperçus de disposer de leurs propres identifiants, plus faibles.
5. Détruire l'environnement à la fusion, à la fermeture ou après un délai d'inactivité, en supprimant les artefacts et les données avec lui ; exécuter un balayage nocturne pour détecter les orphelins.
6. Plafonner le nombre d'aperçus simultanés et les ressources par aperçu ; une file d'attente vaut mieux qu'un cluster qui s'effondre.
7. Diriger le test de fumée de bout en bout vers l'URL de l'aperçu, afin que le pipeline vérifie que la copie démarre effectivement.

Résultat attendu

Un relecteur ouvre le lien depuis la pull request, essaie le changement avec des données de départ, et l'environnement disparaît après la fusion sans que personne n'ait à se souvenir de le supprimer.

Limites et base de vérification

Des aperçus qui partagent un backend avec état (une seule base de données ou file d'attente pour tous) laissent fuiter des changements d'une branche à l'autre ; les services avec état ont besoin d'une copie ou d'un schéma par aperçu. Des migrations difficiles à annuler se marient mal avec la destruction et la recréation. Le coût croît avec le nombre de pull requests ouvertes. La procédure est une synthèse de la documentation de plateforme citée ; aucun chiffre de débit ou de coût n'est avancé.