Orbit
Pipeline de déploiement Orbit
The Pipeline tab is a single page that answers "what happens when we push". It shows every way a deploy can be triggered, every gate that can stop one, the state of each environment, and which build…
L'onglet Pipeline est une page unique qui répond à la question « que se passe-t-il quand nous poussons ». Il montre chaque façon dont un déploiement peut être déclenché, chaque barrière qui peut l'arrêter, l'état de chaque environnement, et les fonctionnalités de compilation qui sont activées, tout cela lu à partir de la configuration réelle de votre projet.
Où se trouve le Pipeline
Ouvrez Orbit, cliquez sur le projet, et choisissez Pipeline sous le groupe Deployments dans la bande d'onglets du projet. La page est étiquetée Deployment pipeline.
C'est un tableau de bord en lecture seule. Rien n'est configuré ici ; chaque section renvoie à l'endroit où le paramètre réside réellement. C'est sa valeur : un écran pour comprendre le projet, plutôt que de lire huit cartes de paramètres.
Alertes en haut
Deux bannières s'affichent quand elles s'appliquent :
- Deploy lock active, avec un lien Manage. Les déploiements déclenchés par une poussée sont ignorés.
- N deployments awaiting approval, avec un lien Review. Quelqu'un doit approuver ou rejeter ces déploiements.
Si l'une ou l'autre s'affiche et que vous vous demandez pourquoi une poussée n'a pas déployé, vous avez votre réponse sans lire davantage.
Statistiques de compilation
Un panneau compact affiche, sur les compilations récentes : le taux de réussite, le temps de compilation moyen, et combien ont réussi. C'est une vérification de santé plutôt qu'une analyse. Pour la vue d'ensemble, consultez Orbit Project Analytics et Orbit Build Insights.
Sources de déclenchement
Cette section énumère chaque route vers un déploiement pour ce projet :
| Source | Ce qu'il affiche |
|---|---|
| Git push | Le référentiel connecté, ou No repo connected |
| Branch previews | Si les aperçus sont créés automatiquement sur n'importe quelle branche |
| Git tag | Le modèle de balise, s'il est configuré |
| Manual deploy | Toujours disponible |
Lisez ceci chaque fois que vous êtes surpris par un déploiement. Si une compilation est apparue et personne n'a poussé, l'une de celles-ci en est l'explication : une balise, un hook de déploiement, ou quelqu'un qui appuie sur un bouton.
Portes et sécurité
La plus grande section est la liste des portes, chacune affichant son état actuel avec un lien Configure vers la carte de paramètres pertinente.
| Porte | Ce qu'elle fait |
|---|---|
| Approval gate | Les déploiements en production nécessitent une approbation explicite |
| Staging prerequisite | La production attend la staging au même commit |
| CI checks | Vérifications requises qui doivent réussir, ou No checks required |
| Freeze window | Fins de semaine bloquées, heures personnalisées, ou pas de calendrier de gel |
| Deploy lock | Actif, ou pas de verrou |
| Health check | Le chemin vérifié après le déploiement, ou Disabled |
| Auto-rollback | Revient en arrière en cas d'échec de la vérification de santé |
| Skew protection | La fenêtre de rétention pour les anciens actifs |
| Auto retry | Nombre de fois que les défaillances d'infrastructure sont réessayées |
La plupart de ces portes s'appliquent uniquement aux déploiements déclenchés par une poussée. Les déploiements manuels à partir du panneau et les hooks de déploiement passent directement. L'exception se comporte différemment, et le détail de chaque porte est couvert dans Deploying Your Project. Lisez cela avant de vous fier à une porte comme contrôle.
Lire les portes comme une liste de contrôle
Pour un projet qui compte, une base raisonnable est :
- Health check: défini, pointant vers un chemin qui exerce l'application plutôt qu'un shell en cache.
- Auto-rollback: activé. Sans une vérification de santé, il n'a rien sur lequel agir, donc les deux vont ensemble.
- Auto retry: un ou deux. Il remet en file d'attente les compilations qui ont échoué en raison d'erreurs d'infrastructure telles qu'un problème réseau, et ne réessaie pas les erreurs de code, il ne vous coûte donc rien d'autre que du temps gagné.
- Approval gate: activé pour tout ce où un mauvais déploiement est coûteux, désactivé où cela vous ralentit plus qu'il ne vous protège.
Si la page affiche Health check Disabled et Auto-rollback activé, cette combinaison ne fait rien. C'est l'une des erreurs de configuration les plus faciles à traîner pendant des mois sans le remarquer, et c'est sur cette page que vous la détectez.
Flux d'environnement
La section Environment flow dessine chaque environnement comme une carte avec son état actuel : LIVE, BUILDING ou PAUSED, la branche qu'il suit, et le numéro de tentative si le déploiement actuel est une tentative.
Les badges sur chaque carte montrent ce qui est activé pour cet environnement :
- Smoke tests, des requêtes GET exécutées contre les chemins choisis après chaque déploiement réussi.
- Auto-promote, promouvoir la staging en production après un nombre d'heures saines.
- Canary, le pourcentage du trafic sur un déploiement canary.
- Inherits prod vars, où la staging fusionne les variables d'environnement de production à une priorité inférieure.
- Scheduled rebuild, où la production se reconstruit à un intervalle.
Chaque carte renvoie aux déploiements de cet environnement. Si un environnement dit No deployments yet, il existe dans la configuration mais rien n'y a été déployé.
Fonctionnalités actives
La dernière section résume les paramètres de niveau compilation :
| Fonctionnalité | Valeurs |
|---|---|
| Server mode | SSR activé ou statique uniquement |
| Auto-create on push | Si les poussées de branche créent des environnements |
| Health checks | Activé ou désactivé |
| Build retry | Un maximum, ou désactivé |
| Deploy groups | Regroupé avec d'autres projets, ou autonome |
| Build timeout | La limite par compilation |
| Preview expiry | Jours avant que les aperçus ne soient mis en pause, ou jamais |
Server mode est celui qui prend les gens au dépourvu. Un framework qui effectue le rendu sur le serveur a besoin qu'il soit activé ; une exportation statique ne le fait pas. Si votre projet se compile correctement puis sert une page vide ou un 404 sur chaque route sauf la page d'accueil, vérifiez d'abord cela. Consultez Frameworks Orbit Supports.
Preview expiry est celui de la maintenance. Défini sur jamais, les environnements d'aperçu s'accumulent indéfiniment.
Utilisation de la page Pipeline
Lors de l'intégration de quelqu'un. Envoyez-le ici en premier. C'est un briefing plus rapide et plus précis que tout document, parce qu'il est généré à partir de la configuration live.
Quand un déploiement n'a pas eu lieu. Travaillez de haut en bas : bannières, puis sources de déclenchement, puis portes. L'un des trois l'expliquera.
Avant une version risquée. Vérifiez que la section portes se lit comme vous le pensez. C'est la différence entre croire que vous avez l'auto-rollback et l'avoir.
En cas d'incident. Le flux d'environnement vous indique ce qui est en direct où, et si quelque chose est en cours de compilation.
Dépannage
La page affiche No repo connected. Le projet n'a pas de référentiel. Connectez-en un : consultez Connecting a GitHub Repository.
Une porte est activée mais les déploiements passent quand même. C'est uniquement déclenché par une poussée. Un hook de déploiement ou un déploiement manuel à partir du panneau n'est pas affecté.
Un environnement affiche PAUSED. Les environnements d'aperçu se mettent en pause automatiquement après avoir dépassé leur expiration. Redéployez pour en ramener un.
Auto-promote est affiché mais rien ne se promeut. Cela nécessite le nombre configuré d'heures saines avec les smoke tests réussis, et est évalué périodiquement plutôt qu'instantanément.
Où aller ensuite
- Deploying Your Project pour ce que chaque porte bloque réellement.
- Orbit Project Settings pour changer tout cela.
- Rolling Back a Deployment quand une porte ne vous a pas sauvé.