Environnements de preview : une copie de votre app pour chaque pull request

Un environnement de preview (ou environnement de prévisualisation) est une copie éphémère de votre application, construite à partir d'une pull request ou d'une branche et accessible à sa propre URL. Les relecteurs ouvrent un lien et testent la modification dans un navigateur au lieu de lire un diff. Une fois le travail terminé, l'environnement disparaît.

Ce guide explique à quoi servent les environnements de preview, ce qui les rend délicats à exploiter et comment ils fonctionnent sur Nodion.

Qu'est-ce qu'un environnement de preview ?

Voyez-le comme un environnement de staging temporaire pour une seule modification. Chaque pull request, ou chaque branche que vous choisissez, obtient :

• son propre build du code de cette branche,
• sa propre app en fonctionnement, avec sa propre URL,
• ses propres copies des services dont elle dépend, en général au moins une base de données vierge,
• une durée de vie limitée.

La différence avec un serveur de staging partagé classique : personne n'attend que le staging soit libre, et une fonctionnalité à moitié terminée ne risque pas de perturber les tests d'une autre. Pour la même idée, vous croiserez aussi les termes review apps, deploy previews ou environnements éphémères.

Pourquoi les équipes les utilisent

• Relire le logiciel en fonctionnement, pas seulement le code. Une mise en page cassée, un parcours confus ou une page lente sautent aux yeux dans le navigateur et passent facilement inaperçus dans un diff.
• La validation de chaque modification. Les testeurs vérifient une modification isolément avant son merge : chaque bug trouvé appartient donc à une seule pull request.
• Des parties prenantes sans environnement de développement local. Designers, product managers ou un client ouvrent un lien. Pas de checkout local, pas de partage d'écran.
• Tester les migrations. Une migration de schéma doit s'exécuter sur une vraie base de données avant que la preview fonctionne. Une migration qui ne marche que sur un seul ordinateur portable échoue ici, pas en production.
• Le travail en parallèle. Cinq pull requests ouvertes, ce sont cinq previews au lieu d'une file d'attente devant un unique serveur de staging.

Ce qui les rend difficiles

Construire l'app est la partie facile. Les difficultés se trouvent dans tout ce qui l'entoure.

Bases de données

Une app sans données est difficile à relire : la plupart des previews ont donc besoin d'une base de données. Il y a trois choix courants : une base vide, une base vide avec des données de départ (seed), ou une copie de la production. Copier la production est tentant, mais cela place de vraies données clients, y compris des données personnelles, dans de nombreux environnements éphémères auxquels davantage de personnes ont accès. C'est aussi lent dès que la base est volumineuse. Pour la plupart des équipes, une base vide avec un script de seed qui crée des données de démo réalistes est le choix par défaut le plus sûr.

Secrets

Une preview exécute du code qui n'a pas encore été relu. Les identifiants de production n'y ont pas leur place. Donnez aux previews des clés de test ou de sandbox pour les prestataires de paiement, l'e-mail et les API tierces, afin qu'un bug dans une branche ne puisse ni débiter une vraie carte ni envoyer d'e-mails à de vrais clients.

URL et callbacks

Chaque preview a un nom d'hôte différent. Les URL de redirection OAuth, les endpoints de webhook, les règles CORS et les cookies liés à votre domaine de production peuvent casser. Les apps qui lisent leur propre URL de base dans la configuration, au lieu de coder en dur le domaine de production, ont beaucoup moins de problèmes ici.

Coût et nettoyage

Chaque preview ouverte fait tourner une app, plus une base de données vierge pour chaque base rattachée à l'app parente. Dix pull requests ouvertes peuvent signifier dix environnements supplémentaires, et une preview oubliée continue de tourner jusqu'à ce que quelqu'un la ferme. Le nettoyage doit se faire sans que personne n'ait à y penser : c'est pourquoi les previews doivent expirer d'elles-mêmes.

Comment fonctionnent les environnements de preview sur Nodion

Sur Nodion, les previews font partie de chaque application déployée depuis un dépôt Git :

• Activez-les dans les Settings de l'app.
• Une preview par pull request ou par branche. Chaque preview est une app éphémère avec sa propre URL.
• À la main ou automatiquement. Créez une preview à la main, ou laissez Nodion en créer une automatiquement pour les pull requests.
• Une base de données vierge. Pour chaque base de données rattachée à l'app, une preview obtient sa propre base vide, jamais un clone de vos données de production. Les volumes, les buckets et les zones e-mail ne sont pas copiés.
• Les paramètres de l'app suivent. Une preview démarre avec une copie des variables d'environnement de l'app, secrets compris. Les variables des bases rattachées pointent vers les bases vierges de la preview ; tout le reste, y compris les clés et les URL d'autres services, est copié tel quel : vérifiez-le donc. Nodion ajoute NODION_PREVIEW=1, NODION_PR_NUMBER, NODION_BRANCH et NODION_PARENT_APP.
• Les previews expirent après un certain nombre de jours sans déploiement (7 par défaut, réglable dans les paramètres de l'app). D'ici là, vous pouvez redéployer ou fermer chacune d'elles depuis l'onglet Previews de l'app.
• Apps Git uniquement. Les apps déployées à partir d'une image préconstruite n'ont pas de previews.

La base vierge est un choix délibéré : les bases de preview rattachées démarrent vides et ne contiennent donc aucune donnée de production. Vérifiez aussi les clés et les URL copiées, pour que le code de preview ne puisse pas atteindre les systèmes de production par leur intermédiaire. Le revers de la médaille : votre app doit pouvoir démarrer sur une base vide, ce qui mérite de toute façon d'être bien fait.

Pour commencer, connectez votre dépôt sous Intégrations Git, créez l'app à partir de celui-ci et activez les previews dans ses paramètres. Tous les détails se trouvent dans la documentation des applications.

Un cycle de revue typique

1. Un développeur ouvre une pull request. Si les previews automatiques sont activées, une preview démarre pour elle, avec sa propre URL et une base de données vide.
2. Le développeur publie le lien de la preview dans la pull request. Les relecteurs, la QA et le product owner testent la modification dans le navigateur.
3. Les retours se traduisent en nouveaux commits. Redéployez la preview depuis l'onglet Previews pour présenter le code le plus récent aux relecteurs.
4. Une fois la modification approuvée et mergée, fermez la preview, ou laissez-la expirer d'elle-même.

Personne n'a eu à réserver un créneau sur le staging, et Nodion a créé une base vierge pour la preview, à la place de la base rattachée à l'app parente. Vérifiez toutes les autres clés et URL copiées avant d'exécuter du code de preview, car elles pointent toujours là où pointent les paramètres de l'app.

Préparer votre app pour les previews

• Exécutez les migrations automatiquement au déploiement ou au démarrage de l'app, pour qu'une base vierge reçoive le schéma actuel sans étape manuelle.
• Ajoutez un script de seed qui crée un compte de test et un peu de contenu de démo. Les relecteurs doivent voir quelque chose d'utile dès le premier clic.
• Lisez l'URL de base dans une variable d'environnement au lieu de coder en dur votre domaine de production.
• Passez les effets de bord en mode test quand NODION_PREVIEW est défini : paiements, e-mails et tout ce qui écrit dans d'autres systèmes. Les previews héritent des secrets de l'app : sans cette vérification, une preview utilise vos clés de production.
• Gardez vos pull requests ciblées. Une preview pour une modification ciblée est bien plus facile à relire qu'une preview pour une semaine de travail.

Quand vous pouvez vous en passer

Pour un projet solo avec quelques modifications par semaine, un environnement local et la production peuvent suffire. Les previews deviennent utiles dès que plus d'une personne relit, teste ou valide les modifications, ou quand les migrations de base de données font partie de votre travail courant.

Les previews sont incluses dans chaque app Git sur Nodion, aux côtés des processus, des logs, des métriques et du déploiement automatique. Consultez Applications pour une vue d'ensemble.