Concepts
Déploiements
Preview, production, adresse de production, adresse de déploiement, statuts et retour arrière. Le cycle de vie d'une version de ton site.
Un déploiement est une version figée de ton site. Il ne change plus après sa publication : une nouvelle version crée un nouveau déploiement, avec sa propre adresse.
Cette page explique ce modèle. Pour les actions pas à pas, voir Revenir en arrière, redéployer ou annuler.
Preview et production
Chaque déploiement est soit une preview, soit une production.
| Cible | Créée par | Servie sur |
|---|---|---|
| Preview | vercel deploy, ou une branche autre que la production | Son adresse de déploiement, et les domaines de branche qui la suivent |
| Production | vercel deploy --prod, ou la branche de production | Son adresse de déploiement, l’adresse de production du projet et ses domaines de production |
Avec l’intégration GitHub, la branche de production part en production, et toutes les autres en preview. Le dernier déploiement de production prêt est celui que servent tes domaines de production.
Contrôle avant la mise en production
Host ne remplace ta production en ligne que par une version qui répond. Quand un déploiement de production est prêt, Host ouvre sa page d’accueil à son adresse de déploiement :
- site statique : la page doit répondre avec un code 2xx ou 3xx ;
- site avec des fonctions : la page doit répondre avec un code inférieur à 500. Un
404de ton application suffit, il prouve qu’elle tourne.
Le contrôle dure une minute au plus. Pendant ce temps, la page du déploiement affiche Contrôle avant la mise en production, et ta production ne change pas.
Si la page ne répond pas, le déploiement reste Prêt sur son adresse, mais il ne passe pas en production. La page du déploiement affiche Pas mis en production avec la raison, et le statut Host du commit sur GitHub passe en échec. Corrige le site et redéploie. Tu peux aussi cliquer Mettre en production : cette action ne fait pas de contrôle.
Le premier déploiement de production d’un projet n’est pas contrôlé : il n’y a encore rien à protéger.
Adresse de production
Chaque projet reçoit à sa création une adresse qui suit toujours sa production, de la forme https://<projet>.hgdc.cloud. C’est l’équivalent de <projet>.vercel.app.
- Elle ne change jamais : ni à une nouvelle mise en production, ni si tu renommes le projet.
- Elle sert le déploiement de production du moment. Une nouvelle production ou un retour arrière la déplace tout de suite, sans nouveau certificat ni réglage DNS.
- Si
<projet>est déjà pris par une autre organisation, l’adresse devient<projet>-<organisation>.hgdc.cloud. La console affiche celle de ton projet dans la carte de production, sous Domaines. - Elle n’est pas indexée par les moteurs de recherche. Pour un site public, branche ton propre domaine : voir Brancher un domaine.
Donne cette adresse à un outil qui doit toujours viser ta production : un proxy, une sonde de disponibilité, une console Docs. Elle est aussi la valeur de VERCEL_PROJECT_PRODUCTION_URL tant que le projet n’a pas de domaine.
Adresse de déploiement
Chaque déploiement reçoit une adresse unique, de la forme https://<projet>-<suffixe>.hgdc.cloud. Elle reste valable tant que le déploiement existe. Quand Host efface le déploiement, cette adresse répond 410 : voir « Durée de conservation » plus bas sur cette page.
Partage cette adresse pour faire valider une version avant de la passer en production. Une preview se valide ainsi, sans toucher au site en ligne.
Statuts
| Statut | Libellé dans la console | Signification |
|---|---|---|
QUEUED | En file | Le déploiement attend son tour de publication |
BUILDING | Build en cours | Le build tourne dans la CI, ou les fichiers sont en cours de publication |
READY | Prêt | Le site est en ligne sur son adresse |
ERROR | Erreur | Le build ou la publication a échoué. La cause est sur la page du déploiement |
CANCELED | Annulé | Annulé dans la console, ou dans GitHub Actions |
Pour corriger une version en ligne, déploie une nouvelle version : elle reçoit son propre déploiement et sa propre adresse.
Vue d’ensemble du projet
La vue d’ensemble montre le déploiement de production : un aperçu du site, son adresse, l’adresse de production du projet et ses domaines, le commit et son auteur. Le projet reprend le favicon de son site.
Les previews actives listent la dernière adresse de chaque branche.
Revenir en arrière
Revenir en arrière remet en ligne un déploiement de production précédent, tout de suite et sans nouveau build. L’adresse de production et les domaines le servent aussitôt. Seul un déploiement prêt peut passer en production.
Le déploiement remis en ligne garde les variables qu’il a reçues à son build. Une variable modifiée depuis ne s’y applique pas.
Un build de production lancé avant le retour arrière, et encore en cours, ne reprend pas la production en finissant. La même règle vaut après une mise en production manuelle. Le prochain déploiement de production, lancé après, la reprend comme d’habitude.
Redéployer
- Projet relié à GitHub : reconstruit le même commit, avec les variables d’aujourd’hui.
- Projet construit par Host : Redéployer sans cache reconstruit aussi le même commit, mais réinstalle les dépendances et refait les caches. Réservé aux admins de l’organisation.
- Projet envoyé par la CLI : republie les fichiers du déploiement choisi, sans rien reconstruire. Pour une nouvelle version, relance
vercel deploy.
Annuler
Un déploiement en file ou en cours de build peut être annulé. Un déploiement prêt ne s’annule pas : reviens en arrière à la place.
Durée de conservation
Host efface les anciens déploiements, comme Vercel. La durée compte depuis la création du déploiement. Par défaut :
| Déploiement | Durée par défaut |
|---|---|
| Annulé | 30 jours |
| En erreur | 90 jours |
| Preview | 90 jours |
| Ancienne production, plus en ligne | 180 jours |
Un admin de l’organisation règle ces quatre durées par projet, dans Réglages du projet, section Conservation des déploiements. Les choix : 7 jours, 30 jours, 60 jours, 90 jours, 180 jours, 1 an, 2 ans, ou Jamais. L’API expose les mêmes durées : voir Projets.
Quel que soit son âge, Host garde toujours :
- la production en ligne ;
- les 10 productions qui ont précédé la production en ligne, pour revenir en arrière ;
- les 10 derniers déploiements du projet ;
- la dernière preview prête d’une branche qui a un domaine de branche ;
- le déploiement remplacé au dernier retour arrière ou à la dernière mise en production manuelle.
Host fait un passage par jour, vers 3 h 40 (heure suisse). Un déploiement effacé disparaît avec ses fichiers et ses logs de build. Son adresse https://<projet>-<suffixe>.hgdc.cloud répond 410 avec la page « Ce déploiement a été supprimé ». Il ne se restaure pas. L’adresse de production et les domaines ne changent pas.
Supprimer un déploiement
Tu peux supprimer un déploiement avant sa date d’effacement :
vercel --api https://api.host.hgdc.ch rm site-atelier-x1y2z3.hgdc.cloudLa même action existe dans l’API : voir Déploiements. Host refuse de supprimer la production en ligne : mets d’abord une autre version en production. Il refuse aussi un build en file ou en cours : annule-le d’abord.
Logs de build
La page de chaque déploiement affiche la sortie du build, en direct pendant le build avec l’intégration GitHub. Voir Lire les logs.
Cette page t'a aidé ?
Merci, c'est noté.