Ihr Projekt bereitstellen

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…

Sobald ein Repository verbunden ist, wird bei jedem Push in Ihren Produktionszweig auf Orbit bereitgestellt: Es klont den Commit, installiert Abhängigkeiten, führt Ihren Build aus, packt die Ausgabe und beginnt, diese bereitzustellen. Dieses Handbuch behandelt den gesamten Bereitstellungszyklus, wie man einen manuell auslöst, und die Steuerelemente, die entscheiden, wann eine Bereitstellung live gehen darf.

Wie automatische Bereitstellungen funktionieren

Jeder Push in den Zweig, der in Settings unter Git als Production branch festgelegt ist, löst eine Bereitstellung aus. Orbit führt dann folgende Schritte durch:

Erhält das Push-Ereignis von GitHub, GitLab oder Bitbucket.
Stellt eine Bereitstellung in die Warteschlange und weist ihr einen Build-Slot zu.
Klont Ihr Repository bei diesem exakten Commit.
Stellt Ihren gecachten node_modules wieder her, wenn Build-Cache in Ihrem Plan verfügbar ist.
Führt Ihren Install-Befehl aus (npm ci, yarn install oder pnpm install, erkannt aus Ihrer Lockdatei).
Führt Ihren Build-Befehl aus.
Packt das Ausgabeverzeichnis in ein Bereitstellungsartefakt und lädt es hoch.
Schaltet die Umgebung um, um das neue Artefakt bereitzustellen.

Die Seite mit den Bereitstellungsdetails zeigt diese als benannte Build phases: Clone, Cache restore, Install, Cache save, Build, Upload, Done. Die meisten Projekte werden in ein bis drei Minuten abgeschlossen.

Orbit-Projektübersicht mit dem neuesten Build

Bereitstellungsstatus

Status	Bedeutung
Queued	Wartet auf einen Build-Slot. Die Bereitstellungsseite zeigt Ihre Position in der Warteschlange
Awaiting approval	Gehalten, weil Require approval for production aktiviert ist. Jemand muss es genehmigen
Building	Abhängigkeiten werden installiert und Ihr Build-Befehl wird ausgeführt
Deploying	Build beendet, das neue Artefakt wird vor dem Traffic eingesetzt
Succeeded (angezeigt als Live)	Bedient Traffic. Die Bereitstellung trägt ein CURRENT-Abzeichen
Failed	Der Build- oder Bereitstellungsschritt ist fehlgeschlagen. Öffnen Sie das Protokoll, um zu sehen, wo
Cancelled	Vor der Fertigstellung gestoppt, von Ihnen oder durch einen neueren Push in denselben Zweig
Rolled back	Durch einen Rollback zu einem früheren Build ersetzt

Einen Build beim Ausführen verfolgen

Die Projekt-Overview zeigt den aktuellen Build mit einem Live-Streaming-Protokoll im Panel Latest build. Klicken Sie auf Full details, um die Bereitstellungsdetailseite zu öffnen, auf der ein Build-Fortschrittsbalken, eine geschätzte verbleibende Zeit, die Warteschlangenposition und die nach Phase aufgeschlüsselte Build-Zeitleiste angezeigt werden.

Wenn Ihr Plan mehr als einen gleichzeitigen Build zulässt und alle ausgelastet sind, teilt Ihnen die Seite dies deutlich mit: Sie zeigt, wie viele Ihrer gleichzeitigen Build-Slots in Gebrauch sind, und startet Ihre Bereitstellung automatisch, wenn einer frei wird. Sie können alle laufenden Builds über alle Ihre Projekte hinweg unter Orbit und dann Queue sehen.

Eine Bereitstellung manuell auslösen

Es gibt vier Möglichkeiten, ohne einen neuen Commit bereitzustellen.

Den neuesten Commit erneut bereitstellen

Öffnen Sie das Projekt.
Öffnen Sie die Registerkarte Deployments.
Klicken Sie auf die Bereitstellung, die Sie möchten, um ihre Detailseite zu öffnen.
Klicken Sie auf Retry build. Verwenden Sie More retry options und dann Retry with cleared cache, wenn Sie einen veralteten gecachten Abhängigkeitstyp vermuten.

Deploy now

Die Schaltfläche Deploy now auf der Registerkarte Deployments stellt eine frische Version des aktuellen Heads Ihres Produktionszweigs in die Warteschlange.

Eine Bereitstellung planen

Eine Bereitstellung kann für einen späteren Zeitpunkt geplant werden. Orbit erstellt einen Snapshot des Commits zum Zeitpunkt der Planung, sodass der später ausgeführte Build der Code ist, den Sie genehmigt haben, nicht das, was inzwischen eingegeben wurde.

Deploy Hooks

Ein Deploy Hook ist eine geheime URL, die einen Build in die Warteschlange stellt, wenn etwas eine POST-Anfrage dorthin sendet. Verwenden Sie sie, um von einem kopflosen CMS, einem Cron-Job oder einer CI-Pipeline aus neu zu erstellen. Richten Sie diese auf der Registerkarte Hooks des Projekts ein. Siehe Triggering Deployments Via Deploy Hooks.

Build-Einstellungen

Orbit erkennt sinnvolle Standardeinstellungen für die meisten Projekte. Überschreiben Sie jeden von ihnen in Settings unter Build settings:

Feld	Platzhalter wenn leer	Beispiele
Install command	`npm ci (auto-detected)`	`npm ci`, `yarn install --frozen-lockfile`, `pnpm install`
Build command	`npm run build (auto-detected)`	`npm run build`, `next build`, `vite build`, `astro build`
Output directory	`dist (auto-detected)`	`dist`, `.next`, `out`, `build`, `.output`
Root directory	`/ (monorepo subdirectory)`	`apps/web`
Node.js version	Platform default	`18`, `20`, `22`

Lassen Sie ein Feld leer, um den automatisch erkannten Wert beizubehalten. Vollständige Details, einschließlich Pro-Framework-Werte und Fehler, die dazu führen, dass eine erste Bereitstellung fehlschlägt, finden Sie unter Configuring Your Build Command and Output Directory.

Das Festlegen eines Root directory tut mehr, als nur das Arbeitsverzeichnis zu ändern. Pushes, die nur Dateien außerhalb dieses Pfads ändern, werden automatisch übersprungen, sodass ein Monorepo nicht bei jedem Commit jeden App neu erstellt.

Entscheidung, wann eine Bereitstellung zulässig ist

Orbit hat mehrere unabhängige Gates. Alle befinden sich in Settings.

Bereitstellungssperren

Verwenden Sie eine Sperre, um die Produktion während eines Vorfalls, eines Wartungsfensters oder eines Code-Freeze-Fensters einzufrieren.

Öffnen Sie das Projekt.
Klicken Sie auf Lock deploys.
Fügen Sie einen optionalen Grund hinzu.

Während die Sperre aktiv ist, werden Push-ausgelöste Bereitstellungen stillschweigend übersprungen und ein Banner liest Production deploys are locked mit Ihrem Grund. Manuelle Bereitstellungen funktionieren weiterhin, was beabsichtigt ist: Eine Sperre verhindert versehentliche Bereitstellungen, nicht den Fix, den Sie versuchen, zu versenden. Klicken Sie auf Unlock deploys, um diese aufzuheben.

Genehmigung für Produktion erforderlich

Aktivieren Sie Require approval for production unter Deploy protection. Push-ausgelöste Produktionsbereitstellungen pausieren dann bei Awaiting approval, bis jemand die Bereitstellung öffnet und auf Approve oder Reject klickt. Panel-Bereitstellungen und Deploy Hooks sind nicht betroffen.

Staging-Erfolg zuerst erforderlich

Require staging success before production hält eine Push-ausgelöste Produktionsbereitstellung auf, bis die Staging-Umgebung denselben Commit erfolgreich bereitgestellt hat. Jemand kann trotzdem manuell genehmigen, um das Warten zu überspringen.

CI erforderliche Checks

Gate-Bereitstellungen bei Ihrem eigenen CI unter CI required checks. Geben Sie auf GitHub durch Kommas getrennte Actions-Jobnamen ein, und alle müssen bestanden werden. Auf GitLab wartet jeder nicht leere Wert auf die gesamte Pipeline. Ein CI-Fehler bricht die Orbit-Bereitstellung automatisch ab.

Bereitstellungs-Einfrierplan

Deploy freeze schedule blockiert Push-ausgelöste Bereitstellungen außerhalb genehmigter Fenster: ein Wochenendblock, ein zulässiger Stundenbereich oder beides. Alle Zeiten sind UTC. Manuelle Bereitstellungen und Deploy Hooks sind nicht betroffen.

Jedes oben beschriebene Gate außer dem Bereitstellungs-Einfrierplan blockiert nur Push-ausgelöste Bereitstellungen. Deploy Hooks und manuelle Panel-Bereitstellungen gehen direkt durch. Wenn eine Hook-URL durchgesickert ist, blockiert keine dieser Einstellungen das Queuing eines Builds. Behandeln Sie Hook-URLs wie Anmeldedaten.

Builds überspringen, die Sie nicht benötigen

Ignored paths: durch Kommas getrennte Glob-Muster. Wenn jede Datei in einem Push übereinstimmt, wird der Build übersprungen. *.md,docs/** stoppt, dass Dokumentations-Commits Bereitstellungen auslösen.
Branch ignore patterns: Pushes von übereinstimmenden Branches werden vollständig übersprungen. dependabot/*,renovate/* ist der häufige Fall.
Git tag deploys: Bereitstellen in der Produktion, wenn ein übereinstimmendes Tag gepusht wird, mit einem Glob wie v*.

Build-Cache

Orbit cacht node_modules zwischen Builds auf den Liftoff- und Apex-Plänen. Wenn ein gecachter Install verwendet wird, zeigt die Bereitstellung ein Cache hit-Abzeichen und die Install-Phase ist dramatisch kürzer. Ein kalter Build zeigt stattdessen Cold build.

Um eine vollständige Neuinstallation zu erzwingen, öffnen Sie Settings, dann Clear build cache, und bestätigen Sie. Die nächste Bereitstellung für jede Umgebung führt eine vollständige Installation von Grund auf durch.

Wenn ein Build auf eine Weise fehlschlägt, die Sie nicht erklären können, und der Code ist lokal in Ordnung, versuchen Sie es mit gelöschtem Cache erneut, bevor Sie etwas ändern. Ein veralteter gecachter Abhängigkeitsstamm ist eine häufige und sehr verwirrende Ursache.

Wenn eine Bereitstellung schiefgeht

Orbit kann eine schlechte Bereitstellung für Sie abfangen, anstatt sie live zu belassen:

Auto-rollback on failure stellt die letzte fehlerfreie Bereitstellung automatisch wieder her, wenn eine Produktionsbereitstellung fehlschlägt.
Health check ruft einen von Ihnen gewählten Pfad nach jeder Produktionsbereitstellung ab. Eine nicht-2xx-Antwort innerhalb von 15 Sekunden stellt die vorherige fehlerfreie Bereitstellung wieder her.
Smoke tests führen GET-Anfragen für bis zu 10 Pfade nach jedem erfolgreichen Deploy durch und verzeichnen erfolgreiche oder fehlgeschlagene. In Kombination mit Auto-Rollback wird ein fehlgeschlagener Smoke Test die Bereitstellung zurückgerollt.

Um eine Bereitstellung selbst rückgängig zu machen, siehe Rolling Back a Deployment. Um herauszufinden, warum ein Build fehlgeschlagen ist, siehe Troubleshooting Failed Builds.