Cette page est la référence parente pour tous les flux de déploiement sur Stack Harbor PaaS. Elle explique quelle méthode utiliser selon le contexte, détaille chaque paramètre de chaque boîte de dialogue, couvre les particularités propres à chaque runtime, et renvoie vers les pages dédiées à chaque sujet.
Pour une carte conceptuelle de toutes les façons de livrer du code — incluant Git-Push-Deploy et le déploiement blue/green — consultez d’abord l’aperçu du déploiement applicatif.
Ce que couvre cette page
- Carte des méthodes de déploiement — archive (fichier local / URL), VCS (Git / SVN / Bitbucket), registre (Hub / Docker Hub / public / privé).
- Points d’entrée — le panneau Gestionnaire de déploiement et la ligne Deployments sur le serveur applicatif.
- Déploiement par archive — chaque champ de la boîte de dialogue.
- Déploiement VCS — chaque champ, plus les particularités de runtime (nœud de build Maven Java, flux distinct .NET/IIS, déploiement sans interruption PHP).
- Auto-déploiement — interrogation périodique, résolution de conflits.
- Édition d’un projet VCS existant — ajustement des paramètres et mise à jour des identifiants.
- Validation post-déploiement — Open in Browser, Logs, Gestionnaire de fichiers, SSH.
- Runtimes et formats d’archive pris en charge.
- Pages connexes — toutes les pages dédiées à chaque sujet de déploiement.
Carte des méthodes de déploiement
Trois grandes catégories couvrent toutes les façons de déployer du code applicatif sur la plateforme :
| Méthode | Quand l’utiliser |
|---|---|
| Archive (fichier local ou URL) | Votre pipeline de build produit un artefact empaqueté (.zip, .war, .jar, .tar.gz, etc.) que vous téléversez ou liez directement. La plateforme ne clone aucun dépôt. |
| VCS (Git / SVN) | Votre code est dans un dépôt de gestion de versions. La plateforme clone le dépôt, invoque optionnellement une étape de build, et copie les fichiers sur le serveur applicatif. L’auto-déploiement par interrogation est disponible. |
| Registre (Hub / Docker Hub) | Vous livrez une image de conteneur plutôt que du code source ou un artefact. La plateforme extrait l’image depuis un registre et redéploie le conteneur. |
Points d’entrée
Deux endroits dans le tableau de bord ouvrent la même boîte de dialogue de déploiement :
- Gestionnaire de déploiement — le panneau au bas du tableau de bord. Survolez une archive stockée ou un projet VCS et cliquez sur Deploy to. Consultez la page Gestionnaire de déploiement pour savoir comment ajouter et gérer des archives et des dépôts.
- Serveur applicatif (ligne Deployments) — survolez la ligne Deployments sur le serveur applicatif et cliquez sur Local file, URL ou Git / SVN.
Les deux premières icônes (Local file et URL) ouvrent la boîte de dialogue de déploiement par archive. La dernière (Git / SVN) ouvre celle de déploiement VCS.
Le point d’entrée choisi change uniquement les champs préremplis : partir du Gestionnaire de déploiement présélectionne l’archive ou le dépôt ; partir du serveur applicatif présélectionne l’environnement cible et le serveur.
Déploiement par archive
Le déploiement par archive prend un artefact empaqueté — téléversé directement ou récupéré depuis une URL — et le déploie sur un serveur applicatif. Aucun accès à un dépôt, aucune étape de build.
Déployer — prod-app
Champs
| Champ | Description |
|---|---|
| Local file ou URL | L’archive à déployer. Formats acceptés : .zip, .tar.gz, .tar.bz2, .tar, .war, .jar. Présélectionné quand on démarre depuis le Gestionnaire de déploiement. |
| Environment | L’environnement cible contenant le serveur applicatif. Présélectionné quand on démarre depuis la ligne du serveur applicatif. |
| Path | Le chemin de contexte de déploiement sur le serveur. Les valeurs disponibles peuvent être contraintes par le runtime — Python et Node.js utilisent un seul chemin prédéfini et n’acceptent pas de valeur personnalisée. |
| Hooks | Scripts pré- et post-déploiement. Exécutés avant et après le décompactage de l’archive. Voir Hooks de déploiement. |
| Deploy strategy | Pour les paliers de serveurs applicatifs à l’échelle avec plus d’un nœud : Simultaneous (tous les nœuds mis à jour en même temps — plus rapide, brève interruption) ou Sequential with delay (nœuds mis à jour un à la fois — sans interruption, délai configurable entre les nœuds). |
| Enable zero-downtime deployment | Serveurs applicatifs PHP uniquement. Bascule la racine documentaire de façon atomique afin de ne pas interrompre les requêtes en cours. Voir la particularité PHP zero-downtime ci-dessous. |
Cliquez sur Deploy pour lancer l’opération.
Déploiement VCS
Le déploiement VCS demande à la plateforme de cloner un dépôt (ou de tirer les derniers commits s’il est déjà cloné) et de copier les fichiers sur le serveur applicatif. Le dépôt doit d’abord être enregistré dans le Gestionnaire de déploiement.
Déploiement VCS — prod-app
nodejs-apiSurveille la branche et déploie à chaque nouveau commit.
Les projets Java / Maven se construisent sur un nœud de build dédié. Les journaux de build sont diffusés dans la console d'activité.
Champs
| Champ | Description |
|---|---|
| Repository | Sélectionnez un projet Git ou SVN enregistré depuis le Gestionnaire de déploiement, ou ouvrez le formulaire d’ajout de dépôt depuis le même menu déroulant. |
| Branch | La branche, l’étiquette ou la révision SVN à déployer. master par défaut. |
| Environment | L’environnement cible contenant le serveur applicatif. |
| Path | Le chemin de contexte de déploiement. Mêmes contraintes que pour le déploiement par archive. |
| Build | Serveurs applicatifs Java uniquement. Sélectionne le nœud de build Maven à utiliser pour la compilation et le packaging. Vous pouvez aussi définir un Working Directory personnalisé dans le dépôt si le module à construire n’est pas à la racine. Voir la particularité Java. |
| Hooks | Scripts pré- et post-déploiement. Voir Hooks de déploiement. |
| Deploy strategy | Mêmes options que pour le déploiement par archive : Simultaneous ou Sequential with delay. |
| Check and auto-deploy updates | Active l’interrogation périodique du dépôt. Quand de nouveaux commits sont détectés sur la branche configurée, la plateforme redéploie automatiquement. Voir Auto-déploiement depuis Git / SVN et Auto-déploiement Git & SVN. |
| Auto-resolve conflicts | Quand activé, la plateforme écarte les modifications locales sur le serveur applicatif au profit de la version du dépôt avant d’appliquer la mise à jour. Évite les conflits de fusion causés par des fichiers modifiés directement sur le serveur. |
| Enable zero-downtime deployment | Serveurs applicatifs PHP uniquement. Même comportement que pour le déploiement par archive. |
Cliquez sur Deploy. La plateforme clone ou met à jour le dépôt, exécute le hook pré-déploiement, copie les fichiers, puis exécute le hook post-déploiement.
Particularités de runtime
Java — nœud de build Maven
Le déploiement VCS pour Java n’est pas une simple copie de fichiers. Quand vous déployez une application Java depuis un dépôt, la plateforme envoie le code source vers un nœud de build Maven dédié, qui compile et emballe l’artefact avant de transférer le résultat vers le serveur applicatif. Le champ Build dans la boîte de dialogue VCS sélectionne le nœud de build à utiliser.
Cela implique :
- Un nœud de build Maven doit exister dans votre environnement (ou y être ajouté) avant de pouvoir déployer une application Java depuis un dépôt.
- Les journaux de build apparaissent sur le nœud de build, non sur le serveur applicatif.
- L’option Working Directory permet de cibler un sous-répertoire, utile pour les structures monorepo.
Pour le guide complet, voir Git-Push-Deploy et Déploiement VCS via le CLI.
.NET — flux de déploiement distinct
Le serveur applicatif IIS sous Windows utilise un flux de déploiement distinct de celui décrit sur cette page. Si votre application cible .NET sur IIS, consultez la documentation du runtime .NET pour les étapes applicables.
PHP — déploiement sans interruption
Pour les serveurs applicatifs PHP, la bascule Enable zero-downtime deployment change la façon dont les fichiers sont écrits pendant un déploiement. Plutôt que d’écraser les fichiers dans la racine documentaire active pendant que le serveur traite des requêtes, la plateforme prépare les nouveaux fichiers dans un répertoire distinct et bascule la racine documentaire de façon atomique dès que la préparation est terminée. Les requêtes en cours au moment de la bascule se terminent contre l’ancienne racine ; les nouvelles requêtes voient immédiatement la nouvelle version.
Cela diffère de la stratégie Sequential with delay, qui concerne l’ordre dans lequel les nœuds d’un palier à l’échelle sont mis à jour. Les deux peuvent être utilisés ensemble sur un palier PHP à l’échelle.
Auto-déploiement et gestion des conflits
Quand Check and auto-deploy updates est activé sur un déploiement VCS, la plateforme interroge le dépôt à un intervalle configurable. Quand de nouveaux commits sont détectés sur la branche suivie, elle déclenche automatiquement un redéploiement.
Deux réglages contrôlent le comportement lors de la détection de changements :
- Intervalle d’interrogation — fréquence à laquelle la plateforme consulte le dépôt. Défini lors de l’ajout du projet VCS dans le Gestionnaire de déploiement ou lors de la modification du déploiement.
- Auto-resolve conflicts — si des fichiers locaux sur le serveur applicatif diffèrent du dépôt (par exemple, parce qu’un fichier a été modifié directement via le gestionnaire de fichiers ou SSH), activer ce réglage fait écarter la version locale par la plateforme au profit de la version du dépôt. Le désactiver vous laisse la responsabilité de la résolution des conflits.
Pour un guide détaillé du comportement de l’auto-déploiement — notamment la mise en file d’attente de deux déploiements déclenchés par deux commits rapides — voir Auto-déploiement depuis Git / SVN.
Éditer un déploiement VCS existant
Pour modifier la configuration d’un déploiement VCS actif — changer la branche suivie, mettre à jour l’intervalle d’interrogation, ajouter ou modifier un hook, changer le nœud de build Maven — cliquez sur Edit à côté de la ligne de déploiement sur le serveur applicatif. Les mêmes champs que la boîte de dialogue de déploiement sont disponibles.
Changement d’identifiants : si les identifiants d’accès au dépôt (nom d’utilisateur/mot de passe ou clé SSH) ont été renouvelés, mettez-les à jour d’abord dans le Gestionnaire de déploiement. Après la sauvegarde des nouveaux identifiants, la plateforme propose de les propager à chaque projet VCS qui référence le même dépôt. Acceptez l’invite pour éviter des auto-déploiements défaillants.
Validation post-déploiement
Une fois le déploiement terminé, utilisez ces quatre commandes pour confirmer que l’application fonctionne :
| Action | Comment y accéder |
|---|---|
| Open in Browser | Cliquez sur Open in Browser sur la ligne de l’environnement pour charger l’application dans un nouvel onglet. Vérifiez que la réponse attendue est servie. |
| Logs | Cliquez sur l’icône Log sur le nœud du serveur applicatif. Les journaux applicatifs, de déploiement et d’erreurs sont disponibles. Voir Consultation des journaux. |
| Gestionnaire de fichiers | Cliquez sur l’icône Config sur le nœud du serveur applicatif et ouvrez le gestionnaire de fichiers. Inspectez les fichiers déployés et la structure des répertoires. |
| SSH | Cliquez sur Web SSH sur le nœud du serveur applicatif pour ouvrir une session de terminal. Effectuez des diagnostics, inspectez les processus ou suivez les journaux directement. Voir Ajouter une clé SSH. |
Runtimes et formats d’archive pris en charge
Les déploiements par archive et VCS sont pris en charge pour : Java, PHP, Ruby, Python, Node.js, Go, et .NET (via le flux IIS distinct — voir ci-dessus).
Formats d’archive acceptés : .zip, .tar.gz, .tar.bz2, .tar, .war, .jar.
Python et Node.js contraignent le Path de déploiement à une seule valeur prédéfinie ; il n’est pas possible de spécifier un chemin de contexte personnalisé pour ces runtimes.
Choisir entre archive et VCS
Utilisez le déploiement par archive quand :
- Votre pipeline de build (CI/CD,
mvn packagelocal, un artefact GitHub Actions) produit un fichier empaqueté. - Vous voulez un contrôle total sur l’étape de build en dehors de la plateforme.
- Vous déployez un seul artefact sans connexion à un dépôt.
Utilisez le déploiement VCS quand :
- Vous voulez que la plateforme clone et suive une branche de dépôt.
- Vous voulez l’auto-déploiement sur les commits sans configurer un webhook externe.
- Vous déployez une application Java et voulez que la plateforme gère l’étape de build Maven.
Pour un modèle déclenché par un push — où un commit dans votre dépôt déclenche immédiatement un déploiement sans interrogation — voir Git-Push-Deploy.
Pour les déploiements blue/green avec transfert de trafic entre deux environnements, voir Déploiement blue/green.
Contraintes et cas particuliers
- Paliers à l’échelle et stratégie de déploiement : sur un palier à nœud unique, Deploy strategy n’a aucun effet. Le réglage n’a d’importance que lorsque le palier comporte deux nœuds ou plus.
- PHP zero-downtime et paliers à l’échelle : la bascule atomique de la racine documentaire s’applique par nœud. Sur un palier à l’échelle, combinez Enable zero-downtime deployment avec Sequential with delay pour éviter de servir des versions mixtes pendant une mise à jour progressive.
- Projets VCS et environnements multiples : un même dépôt peut être déployé vers plusieurs environnements. Chaque ligne de déploiement suit sa propre branche, son propre chemin et ses propres paramètres d’auto-déploiement de façon indépendante.
- Redéploiement d’un conteneur (remplacement de son image de base plutôt que de son code applicatif) est une opération distincte. Voir Redéploiement de conteneur et Données préservées lors d’un redéploiement.
Voir aussi
- Aperçu du déploiement applicatif — la carte complète de toutes les méthodes de déploiement.
- Déploiement applicatif — référence approfondie de l’opération de déploiement.
- Gestionnaire de déploiement — gestion des archives stockées et des dépôts VCS.
- Hooks de déploiement — scripts pré- et post-déploiement.
- Auto-déploiement depuis Git / SVN — auto-déploiement par interrogation périodique.
- Auto-déploiement Git & SVN — guide pas à pas de configuration de l’auto-déploiement.
- Git-Push-Deploy — déploiement déclenché par un push git via webhook.
- Déploiement VCS via le CLI — automatisation des déploiements VCS depuis le CLI de la plateforme.
- Déploiement blue/green — transfert de trafic entre deux environnements.
- Redéploiement de conteneur — remplacement de l’image de base d’un conteneur en exécution.
- Données préservées lors d’un redéploiement — ce qui survit à un redéploiement de conteneur.