DÉPLOYER

Environnements de préview

Donnez à chaque pull request sa propre copie en ligne, avec sa propre URL, détruite à la fusion.

Un environnement de préview est une copie en ligne de votre application, construite depuis la branche d’une pull request, sur sa propre URL, créée à l’ouverture de la PR et détruite à sa fermeture. Les relecteurs cliquent un lien au lieu de récupérer une branche.

Un preview est une vraie application

Ce n’est pas un mode allégé spécial. DockBoard duplique la configuration de l’application source dans une nouvelle application : le preview hérite du même pipeline de build, des mêmes contrôles de permission, de la même admission par quota et du même chemin de démantèlement.

Cette réutilisation est le principe. Un « déploiement de préview » sur mesure serait une seconde implémentation de build-et-exécution qui divergerait de la vraie — et la première chose à diverger est toujours un contrôle de sécurité.

Les seules choses que la couche préview ajoute : quelle branche construire, sur quel nom d’hôte répondre, et quand mourir.

La base partagée

Les variables d’environnement sont copiées avec la configuration : un preview pointe donc sur la même base que son application source. C’est un environnement de revue pour une branche, pas un étage isolé.

L’alternative — vider l’environnement — semble plus sûre et se révèle pire : une application dont la configuration a été vidée ne démarre généralement pas, et « les previews sont cassés » est la conclusion que tout le monde en tire.

Dites-le clairement à votre équipe : une branche non relue peut écrire dans les vraies données via son preview. Si c’est inacceptable pour une application donnée, faites pointer ses previews sur une base séparée grâce à un jeu de variables par environnement, ou n’activez pas les previews dessus.

Cette base partagée est précisément la raison pour laquelle les previews sont créés avec leurs tâches cron désactivées. Une planification copiée exécuterait la migration ou la purge d’une branche non relue sur les vraies données — une fois par pull request ouverte. Voir planification et cron.

Création et démantèlement

01Activez les previews sur l’application et connectez le fournisseur Git.
02Une pull request s’ouvre. DockBoard clone la configuration, construit la branche de la PR et attribue un nom d’hôte dérivé du numéro de PR.
03Chaque nouveau push sur cette branche redéploie le preview, exactement comme une application normale.
04La pull request est fusionnée ou fermée. Le preview et son entrée DNS sont supprimés.

Un preview peut aussi être détruit à la main à tout moment — depuis sa propre page, ou depuis l’onglet Previews de l’application source.

Limites

Dix previews par application source. Un dépôt à soixante pull requests ouvertes ne doit pas pouvoir transformer une salve de merges en soixante builds simultanés. Le quota de projet finirait par l’arrêter, mais avec une erreur opaque à la quarante-et-unième pull request.
Les previews consomment le quota du projet comme toute autre application — CPU, mémoire, nombre d’applications. Dix previews d’une application lourde représentent un vrai budget.
Ils atterrissent sur le même serveur que leur application source.

Preview ou déploiement CI ?

Les deux résolvent des problèmes différents, et se tromper coûte un pipeline dont personne n’avait besoin :

Vous voulez	Utilisez
Une copie en ligne par pull request, pour la relecture	Les previews. DockBoard les crée et les détruit lui-même — aucun câblage CI.
Qu’un push sur `main` redéploie la production, et que le pipeline échoue si le déploiement échoue	Déployer depuis la CI avec une clé API à deux scopes.