Orbit

Déploiement de votre projet

Once a repository is connected, Orbit deploys on every push to your production branch: it clones the commit, installs dependencies, runs your build, packages the output and starts serving it. This…

Une fois qu'un référentiel est connecté, Orbit effectue un déploiement à chaque poussée vers votre branche de production : il clone le commit, installe les dépendances, exécute votre compilation, empaquette la sortie et commence à la servir. Ce guide couvre le cycle de déploiement complet, comment en déclencher un manuellement et les contrôles qui décident quand un déploiement est autorisé à être mis en direct.

Comment fonctionnent les déploiements automatiques

Chaque poussée vers la branche définie comme Production branch dans Settings, puis Git, déclenche un déploiement. Orbit effectue alors :

  1. Reçoit l'événement de poussée de GitHub, GitLab ou Bitbucket.
  2. Met en file d'attente un déploiement et lui assigne un créneau de compilation.
  3. Clone votre référentiel à ce commit exact.
  4. Restaure votre cache node_modules si le cache de compilation est disponible sur votre plan.
  5. Exécute votre commande d'installation (npm ci, yarn install ou pnpm install, détectée à partir de votre fichier de verrouillage).
  6. Exécute votre commande de compilation.
  7. Empaquette le répertoire de sortie dans un artefact de déploiement et le télécharge.
  8. Bascule l'environnement pour servir le nouvel artefact.

La page de détail du déploiement affiche ceux-ci comme des phases de compilation nommées : Clone, Cache restore, Install, Cache save, Build, Upload, Done. La plupart des projets se terminent en une à trois minutes.

Orbit project overview showing the latest build

Statuts de déploiement

StatutSignification
QueuedEn attente d'un créneau de compilation. La page de déploiement affiche votre position dans la file d'attente
Awaiting approvalBloqué car Require approval for production est activé. Quelqu'un doit l'approuver
BuildingInstallation des dépendances et exécution de votre commande de compilation
DeployingLa compilation est terminée, le nouvel artefact est mis en avant du trafic
Succeeded (shown as Live)Serveur du trafic. Le déploiement porte un badge CURRENT
FailedL'étape de compilation ou de déploiement a généré une erreur. Ouvrez le journal pour voir où
CancelledArrêté avant la fin, par vous ou par une nouvelle poussée vers la même branche
Rolled backRemplacé par une annulation vers une compilation antérieure

Regarder une compilation en cours

L'Overview du projet affiche la compilation actuelle avec un journal en direct dans le panneau Latest build. Cliquez sur Full details pour ouvrir la page de détail du déploiement, qui ajoute une barre de progression de compilation, un temps estimé restant, la position dans la file d'attente et la chronologie de compilation ventilée par phase.

Si votre plan permet plus d'une compilation simultanée et qu'elles sont toutes occupées, la page vous le dit clairement : elle affiche le nombre de vos créneaux de compilation simultanée utilisés et lance automatiquement votre déploiement quand l'un se libère. Vous pouvez voir chaque compilation en vol dans tous vos projets sur Orbit, puis Queue.

Déclencher un déploiement manuellement

Il y a quatre façons de déployer sans pousser un nouveau commit.

Redéployer le dernier commit

  1. Ouvrez le projet.
  2. Ouvrez l'onglet Deployments.
  3. Cliquez sur le déploiement que vous voulez, pour ouvrir sa page de détail.
  4. Cliquez sur Retry build. Utilisez More retry options, puis Retry with cleared cache, si vous soupçonnez une dépendance cachée obsolète.

Deploy Now

Le bouton Deploy now de l'onglet Deployments met en file d'attente une nouvelle compilation du head actuel de votre branche de production.

Planifier un déploiement

Un déploiement peut être planifié pour un moment ultérieur. Orbit enregistre le commit au moment où vous le planifiez, donc la compilation qui s'exécute plus tard est le code que vous avez approuvé, et non ce qui a atterri entre-temps.

Deploy Hooks

Un hook de déploiement est une URL secrète qui met en file d'attente une compilation quand quelque chose lui envoie une requête POST. Utilisez-les pour reconstruire à partir d'un CMS sans tête, une tâche cron ou un pipeline CI. Configurez-les sur l'onglet Hooks du projet. Voir Triggering Deployments Via Deploy Hooks.

Paramètres de compilation

Orbit détecte les valeurs par défaut sensibles pour la plupart des projets. Remplacez l'une d'elles dans Settings, puis Build settings :

ChampEspace réservé quand videExemples
Install commandnpm ci (auto-detected)npm ci, yarn install --frozen-lockfile, pnpm install
Build commandnpm run build (auto-detected)npm run build, next build, vite build, astro build
Output directorydist (auto-detected)dist, .next, out, build, .output
Root directory/ (monorepo subdirectory)apps/web
Node.js versionPlatform default18, 20, 22

Laissez un champ vide pour conserver la valeur détectée automatiquement. Pour plus de détails, notamment les valeurs par framework et les erreurs qui font échouer un premier déploiement, voir Configuring Your Build Command and Output Directory.

Définir un Root directory fait plus que changer le répertoire de travail. Les poussées qui ne modifient que les fichiers en dehors de ce chemin sont automatiquement ignorées, donc un monorepo ne se recompile pas à chaque commit.

Décider quand un déploiement est autorisé

Orbit a plusieurs portes indépendantes. Toutes se trouvent dans Settings.

Deploy Locks

Utilisez un verrou pour geler la production lors d'un incident, une fenêtre de maintenance ou une période de gel du code.

  1. Ouvrez le projet.
  2. Cliquez sur Lock deploys.
  3. Ajoutez une raison facultative.

Tant que le verrouillage est actif, les déploiements de production déclenchés par une poussée sont silencieusement ignorés et une bannière lit Production deploys are locked avec votre raison. Les déploiements manuels fonctionnent toujours, ce qui est intentionnel : un verrou arrête les déploiements accidentels, pas le correctif que vous essayez d'expédier. Cliquez sur Unlock deploys pour le lever.

Exiger une approbation pour la production

Activez Require approval for production sous Deploy protection. Les déploiements de production déclenchés par une poussée s'arrêtent ensuite à Awaiting approval jusqu'à ce que quelqu'un ouvre le déploiement et clique sur Approve ou Reject. Les déploiements de panneaux et les hooks de déploiement ne sont pas affectés.

Exiger que le succès de l'intermédiaire en premier

Require staging success before production retient un déploiement de production déclenché par une poussée jusqu'à ce que l'environnement d'intermédiaire ait déployé avec succès le même commit. Quelqu'un peut toujours approuver manuellement pour ignorer l'attente.

Contrôles CI requis

Déployez les portes sur votre propre CI sous CI required checks. Sur GitHub, entrez les noms des tâches Actions séparés par des virgules et tous doivent réussir. Sur GitLab, toute valeur non vide attend l'ensemble du pipeline. Un échec CI annule automatiquement le déploiement Orbit.

Planning de gel des déploiements

Deploy freeze schedule bloque les déploiements déclenchés par une poussée en dehors des fenêtres approuvées : un blocage en fin de semaine, une plage d'heures autorisée, ou les deux. Tous les horaires sont en UTC. Les déploiements manuels et les hooks de déploiement ne sont pas affectés.

Chaque porte ci-dessus sauf le planning de gel des déploiements bloque uniquement les déploiements déclenchés par une poussée. Les hooks de déploiement et les déploiements manuels du panneau passent directement. Si une URL de hook est divulguée, aucun de ces paramètres ne l'empêchera de mettre en file d'attente une compilation. Traitez les URL de hook comme des identifiants de connexion.

Ignorer les compilations dont vous n'avez pas besoin

  • Ignored paths : modèles glob séparés par des virgules. Si chaque fichier d'une poussée correspond, la compilation est ignorée. *.md,docs/** arrête les commits de documentation qui déclenchent des déploiements.
  • Branch ignore patterns : les poussées des branches correspondantes sont complètement ignorées. dependabot/*,renovate/* est le cas courant.
  • Git tag deploys : déployer en production quand une balise correspondante est poussée, en utilisant un glob comme v*.

Cache de compilation

Orbit cache node_modules entre les compilations sur les plans Liftoff et Apex. Quand une installation en cache est utilisée, le déploiement affiche un badge Cache hit et la phase d'installation est considérablement plus courte. Une compilation froide affiche Cold build à la place.

Pour forcer une réinstallation complète, ouvrez Settings, puis Clear build cache, et confirmez. Le déploiement suivant pour chaque environnement exécute une installation complète à partir de zéro.

Si une compilation échoue d'une manière que vous ne pouvez pas expliquer et que le code est correct localement, réessayez-la avec le cache effacé avant de commencer à changer quoi que ce soit. Un arbre de dépendances en cache obsolète est une cause courante et très confuse.

Quand un déploiement tourne mal

Orbit peut vous intercepter un mauvais déploiement plutôt que de le laisser en direct :

  • Auto-rollback on failure restaure automatiquement le dernier déploiement sain si un déploiement de production échoue.
  • Health check récupère un chemin que vous choisissez après chaque déploiement de production. Une réponse autre que 2xx dans les 15 secondes restaure le déploiement sain précédent.
  • Smoke tests exécute des demandes GET contre jusqu'à 10 chemins après chaque déploiement réussi et enregistre la réussite ou l'échec. Combiné avec l'auto-rollback, un test de fumée défaillant annule le déploiement.

Pour annuler un déploiement vous-même, voir Rolling Back a Deployment. Pour savoir pourquoi une compilation a échoué, voir Troubleshooting Failed Builds.

Vous avez besoin d'aide?

Envoyez-nous un email à support@kapsulehost.com ou ouvrez un chat dans KPanel.

Ouvrir KPanel
Déploiement de votre projet