Orbit
Orbit Deployment Pipeline
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…
Die Pipeline-Registerkarte ist eine einzelne Seite, die die Frage beantwortet: "Was passiert, wenn wir pushen". Sie zeigt alle Wege, wie ein Deployment ausgelöst werden kann, jede Gate, die eines stoppen kann, den Status jeder Umgebung und welche Build-Features aktiviert sind. Alles wird aus der echten Konfiguration Ihres Projekts gelesen.
Wo die Pipeline zu finden ist
Öffnen Sie Orbit, klicken Sie auf das Projekt und wählen Sie Pipeline unter der Gruppe Deployments in der Projektreihe der Registerkarten. Die Seite ist mit Deployment pipeline gekennzeichnet.
Dies ist ein Nur-Lese-Dashboard. Hier wird nichts konfiguriert; jeder Abschnitt verlinkt zu dem Ort, an dem die Einstellung tatsächlich vorhanden ist. Das ist sein Wert: ein Bildschirm zum Verständnis des Projekts, anstatt acht Einstellungskarten zu lesen.
Benachrichtigungen oben
Zwei Banner werden angezeigt, wenn sie zutreffen:
- Deploy lock active, mit einem Link Manage. Push-ausgelöste Deployments werden übersprungen.
- N deployments awaiting approval, mit einem Link Review. Jemand muss sie genehmigen oder ablehnen.
Wenn einer davon angezeigt wird und Sie sich fragen, warum ein Push nicht bereitgestellt wurde, haben Sie Ihre Antwort, ohne weiter zu lesen.
Build-Statistiken
Ein kompaktes Panel zeigt über die letzten Builds: Erfolgsquote, durchschnittliche Build-Zeit und wie viele erfolgreich waren. Dies ist eine Gesundheitsprüfung und nicht eine Analyse. Für das vollständige Bild siehe Orbit Project Analytics und Orbit Build Insights.
Trigger-Quellen
Dieser Abschnitt listet alle Wege zu einem Deployment für dieses Projekt auf:
| Quelle | Was es zeigt |
|---|---|
| Git push | Das verbundene Repository oder No repo connected |
| Branch previews | Ob Vorschauversionen automatisch auf jedem Branch erstellt werden |
| Git tag | Das Tag-Muster, falls eines konfiguriert ist |
| Manual deploy | Immer verfügbar |
Lesen Sie dies jedes Mal, wenn Sie von einer Bereitstellung überrascht sind. Falls ein Build auftauchte und niemand gepusht hat, ist einer davon die Erklärung: ein Tag, ein Deploy-Hook oder jemand, der einen Button drückt.
Gates und Sicherheit
Der größte Abschnitt ist die Liste der Gates, von denen jedes seinen aktuellen Status mit einem Link Configure zur relevanten Einstellungskarte anzeigt.
| Gate | Was es bewirkt |
|---|---|
| Approval gate | Production-Deployments erfordern explizite Genehmigung |
| Staging prerequisite | Production wartet auf Staging beim gleichen Commit |
| CI checks | Erforderliche Checks, die bestanden werden müssen, oder No checks required |
| Freeze window | Wochenenden blockiert, benutzerdefinierte Stunden oder kein Freeze-Plan |
| Deploy lock | Aktiv oder kein Lock |
| Health check | Der nach dem Deployment überprüfte Pfad oder Disabled |
| Auto-rollback | Setzt bei Health-Check-Fehler zurück |
| Skew protection | Das Aufbewahrungsfenster für alte Assets |
| Auto retry | Wie oft Infrastrukturausfälle erneut versucht werden |
Die meisten dieser Gates gelten nur für Push-ausgelöste Deployments. Manuelle Deployments aus dem Panel und Deploy-Hooks gehen direkt durch. Die Ausnahme verhält sich anders, und die Details der einzelnen Gates werden in Deploying Your Project behandelt. Lesen Sie dies, bevor Sie sich auf ein Gate als Kontrolle verlassen.
Die Gates als Checkliste lesen
Für ein Projekt, das wichtig ist, ist eine sinnvolle Grundlage:
- Health check: gesetzt, verweist auf einen Pfad, der die App trainiert, anstatt einer gecachten Shell.
- Auto-rollback: an. Ohne einen Health Check hat er nichts zu tun, daher gehen die beiden zusammen.
- Auto retry: eins oder zwei. Es setzt Builds erneut in die Warteschlange, die bei Infrastrukturfehlern wie Netzwerkfehlern fehlgeschlagen sind, und versucht nicht, Code-Fehler erneut zu versuchen, daher kostet es Sie nichts als eingesparte Zeit.
- Approval gate: an für alles, wo ein schlechtes Deployment teuer ist, aus, wenn es Sie mehr verlangsamt als schützt.
Wenn die Seite Health check Disabled und Auto-rollback an zeigt, tut diese Kombination nichts. Dies ist eine der einfachsten Fehlkonfigurationen, die man monatelang tragen kann, ohne es zu bemerken, und auf dieser Seite können Sie es erkennen.
Umgebungsfluss
Der Abschnitt Environment flow stellt jede Umgebung als Karte mit ihrem aktuellen Status dar: LIVE, BUILDING oder PAUSED, den Branch, den sie verfolgt, und die Wiederholungsnummer, wenn das aktuelle Deployment eine Wiederholung ist.
Badges auf jeder Karte zeigen, was für diese Umgebung aktiviert ist:
- Smoke tests, GET-Anfragen, die nach jedem erfolgreichen Deployment gegen ausgewählte Pfade ausgeführt werden.
- Auto-promote, das Staging nach einer Anzahl gesunder Stunden in Production hochstuft.
- Canary, der Prozentsatz des Verkehrs auf einer Canary-Bereitstellung.
- Inherits prod vars, wo Staging Production-Umgebungsvariablen mit niedrigerer Priorität zusammenführt.
- Scheduled rebuild, wo Production in einem Intervall neu erstellt wird.
Jede Karte verlinkt zu den Deployments dieser Umgebung. Wenn eine Umgebung No deployments yet sagt, existiert sie in der Konfiguration, aber nichts wurde dorthin versendet.
Aktive Features
Der letzte Abschnitt fasst Build-Level-Einstellungen zusammen:
| Feature | Werte |
|---|---|
| Server mode | SSR aktiviert oder nur statisch |
| Auto-create on push | Ob Branch-Pushes Umgebungen erstellen |
| Health checks | An oder aus |
| Build retry | Ein Maximum oder aus |
| Deploy groups | Gruppiert mit anderen Projekten oder eigenständig |
| Build timeout | Das Pro-Build-Limit |
| Preview expiry | Tage bis Vorschauversionen angehalten werden oder nie |
Server mode ist das, bei dem sich Leute verfangen. Ein Framework, das auf dem Server rendert, benötigt es an; ein statischer Export nicht. Wenn Ihr Projekt gut erstellt wird und dann auf jeder Route außer der Startseite eine leere Seite oder eine 404 bereitstellt, überprüfen Sie dies zuerst. Siehe Frameworks Orbit Supports.
Preview expiry ist die Housekeeping-Einstellung. Auf "nie" gesetzt, sammeln sich Vorschauumgebungen unbegrenzt an.
Verwenden der Pipeline-Seite
Beim Onboarding von jemandem. Senden Sie ihn zuerst hierher. Dies ist eine schnellere und genauere Briefing als jedes Dokument, da es aus der Live-Konfiguration generiert wird.
Wenn ein Deployment nicht passiert ist. Arbeiten Sie von oben nach unten: Banner, dann Trigger-Quellen, dann Gates. Eines der drei wird es erklären.
Vor einer riskanten Veröffentlichung. Überprüfen Sie, ob der Abschnitt "Gates" das anzeigt, was Sie denken. Dies ist der Unterschied zwischen der Überzeugung, dass Sie Auto-Rollback haben, und dass Sie es haben.
Während eines Vorfalls. Der Umgebungsfluss zeigt Ihnen, was wo live ist und ob etwas gerade erstellt wird.
Fehlerbehebung
Die Seite zeigt No repo connected. Das Projekt hat kein Repository. Verbinden Sie eines: siehe Connecting a GitHub Repository.
Ein Gate ist an, aber Deployments gehen trotzdem durch. Dies ist nur Push-ausgelöst. Ein Deploy-Hook oder ein manuelles Panel-Deployment ist nicht betroffen.
Eine Umgebung zeigt PAUSED. Vorschauumgebungen werden automatisch angehalten, sobald sie abgelaufen sind. Erneut bereitstellen, um eine zurückzubringen.
Auto-promote wird angezeigt, aber nichts wird hochgestuft. Es erfordert die konfigurierte Anzahl gesunder Stunden mit bestandenen Smoke Tests und wird regelmäßig ausgewertet, nicht sofort.
Wo es weitergeht
- Deploying Your Project für das, was jedes Gate tatsächlich blockiert.
- Orbit Project Settings um etwas davon zu ändern.
- Rolling Back a Deployment wenn ein Gate Sie nicht rettete.