Stack Harbor PaaS expose plusieurs moyens de pousser du code applicatif dans un environnement en exécution. Vous pouvez téléverser une archive, fournir une URL Git ou SVN à la plateforme, tirer une image de conteneur depuis un registre, ou déclencher l’une de ces actions via le CLI ou l’API. Cette page est l’index des surfaces de déploiement — chacune fait l’objet d’une documentation distincte.
Ce que cette section couvre
- Déploiement applicatif — le parcours complet entre archives, projets VCS et déploiements Docker.
- Gestionnaire de déploiement — le panneau du tableau de bord qui stocke les archives réutilisables et les dépôts VCS enregistrés.
- Guide de déploiement — la référence de configuration pour la boîte de dialogue de déploiement : chemins, branches, hooks, stratégie de déploiement, bascules zéro interruption.
- Hooks de déploiement — scripts pré- et post-déploiement exécutés à chaque déploiement.
- Auto-déploiement depuis Git / SVN — interrogation périodique d’un dépôt distant, avec déploiement automatique sur les changements détectés.
- Git-Push-Deploy — déploiement déclenché par push via webhooks de dépôt, intégré à GitHub et GitLab.
- Déploiement blue/green — version sans interruption à l’aide de deux environnements parallèles derrière un répartiteur de trafic.
- Déploiement VCS par CLI — gérer les projets VCS depuis la ligne de commande.
- Redéploiement — changer un conteneur vers une nouvelle étiquette d’image en préservant la configuration et les données.
Surfaces de déploiement
Trois sources principales alimentent le pipeline de déploiement :
- Archive — un build empaqueté (
.zip,.tar.gz,.tar.bz2,.tar,.war,.jar) téléversé depuis un fichier local ou récupéré depuis une URL. Supporté pour tous les runtimes (Java, PHP, Ruby, Python, Node.js, .NET, Go). - VCS — un dépôt Git ou SVN enregistré dans le gestionnaire de déploiement. La plateforme clone le dépôt dans le serveur applicatif, avec interrogation optionnelle des nouveaux commits.
- Registre de conteneur — pour les serveurs applicatifs basés sur Docker, la plateforme tire une image depuis un registre public ou privé et l’exécute.
Pour les applications Java, le déploiement depuis VCS utilise un nœud de build Maven qui compile le projet et pousse l’artefact résultant vers le serveur applicatif. Pour PHP, Ruby, Python, Node.js et Go, le serveur applicatif exécute les sources du projet directement.
Éviter l’interruption
Deux stratégies sont disponibles, selon le serveur applicatif :
- Déploiement séquentiel avec délai — pour les paliers de serveur applicatif mis à l’échelle, les instances sont redéployées une à la fois avec un délai configurable. Les autres instances continuent de servir le trafic.
- Déploiement zéro interruption (PHP) — pour les serveurs applicatifs Apache PHP et NGINX PHP, le flux de déploiement bascule la racine documentaire de façon atomique et évite d’interrompre les requêtes en cours.
Pour des modèles de release plus substantiels, l’approche blue/green utilise deux environnements parallèles derrière un répartiteur de trafic, avec basculement du trafic entre eux.
Voies d’automatisation
- Auto-déploiement — enregistrer un dépôt Git ou SVN avec l’option Check and auto-deploy updates activée. La plateforme interroge à un intervalle configurable et redéploie quand de nouveaux commits sont détectés.
- Git-Push-Deploy — pour GitHub et GitLab, un webhook sur le dépôt déclenche le redéploiement à chaque push. Pas de délai d’interrogation.
- CLI — chaque action de déploiement exposée dans le tableau de bord est disponible via le CLI, adaptée aux pipelines de build.
- API — les mêmes opérations sont accessibles par programme via l’API REST.