Orbit
Branch Preview Deployments in Orbit
Branch previews build every non-production, non-staging branch you push to its own isolated URL, so you can click through a change in a real environment before it merges. This guide covers turning…
Branch-Previews aktivieren
- Öffnen Sie Ihr Projekt in Orbit.
- Öffnen Sie die Registerkarte Settings.
- Suchen Sie den Abschnitt Runtime und aktivieren Sie Branch previews.
Nach der Aktivierung löst jeder Push auf einen Branch, der weder Ihr Produktionsbranch noch Ihr Staging-Branch ist, einen Build aus und stellt ihn in seiner eigenen Vorschauumgebung bereit.
Branch previews sind ein projektspezifischer Toggle, kein kostenpflichtiges Add-on. Sie sind auf jedem Orbit-Plan verfügbar, einschließlich des kostenlosen Launch-Plans. Was sich je nach Plan unterscheidet, ist die Anzahl der Umgebungen, die ein einzelnes Projekt gleichzeitig haben kann: Launch erlaubt 2 (Produktion plus eine Vorschau), Liftoff 4 und Apex 11. Sobald ein Projekt sein Umgebungslimit erreicht hat, erhalten weitere Branches keine eigene Vorschau, bis Sie eine löschen.
Preview-URLs
Eine Vorschau erhält einen Hostnamen, der von ihrem Branch-Namen abgeleitet ist: der Name wird in Kleinbuchstaben konvertiert, jedes Zeichen, das kein Buchstabe, keine Ziffer oder kein Bindestrich ist, wird zu einem Bindestrich, Bindestrichfolgen werden zusammengefasst, das Ergebnis wird auf 48 Zeichen gekürzt und mit branch- vorangestellt.
| Branch | Preview hostname |
|---|---|
redesign | branch-redesign.kaps.run |
feat/new-checkout | branch-feat-new-checkout.kaps.run |
JB/Fix_Cart | branch-jb-fix-cart.kaps.run |
Preview-URLs sind öffentlich erreichbar für jeden, der den Link hat. Sie werden nicht indexiert oder beworben, aber sie sind auch nicht zugriffskontrolliert. Verwenden Sie keine Vorschau, um etwas zu überprüfen, das Ihr Team nicht verlassen darf, und verweisen Sie eine Vorschau nicht auf Produktionsdaten. Wenn Sie eine geschützte Vorproduktionsumgebung benötigen, nutzen Sie stattdessen eine Staging-Umgebung: Staging unterstützt ein Passwort und eine IP-Zulassungsliste unter Settings in den Abschnitten Staging: access protection und Staging: IP allowlist.
Wo Vorschauen angezeigt werden
Die Registerkarte Overview des Projekts hat einen Abschnitt Preview deployments, der jede aktive Vorschau auflistet. Jede Zeile zeigt:
- Den Branch-Namen und ein PR #number-Badge, das mit dem Pull Request verlinkt, wenn der Branch einen offenen hat
- Den aktuellen Status (QUEUED, BUILDING oder live)
- Wie lange es her ist, dass es bereitgestellt wurde
- Ein Link zum Öffnen der Preview-URL
- View logs zum Öffnen der Deployment-Detailseite
- Eine Schaltfläche zum Löschen
Jede Vorschau ist eine vollständig isolierte Umgebung mit eigener URL, eigenem Build und eigenen Umgebungsvariablen. Nichts, was sie tut, kann die Produktion beeinflussen.
Die Registerkarte Branches des Projekts bietet dieselben Informationen organisiert pro Branch, was leichter zu scannen ist, wenn Sie mehrere gleichzeitig offen haben.
Umgebungsvariablen in Vorschauen
Dies ist der Teil, den es richtig zu machen gilt. Eine Variable mit dem Geltungsbereich All environments (project-wide) wird in Preview-Builds injiziert, und eine Preview-URL ist öffentlich.
- Halten Sie Produktionsanmeldedaten nur für Ihre Produktionsumgebung in Scope.
- Geben Sie Vorschauen Test-Mode- oder Sandbox-Anmeldedaten für Drittanbieterdienste.
- Hinterlassen Sie niemals eine Produktionsdatenbank-URL oder einen Live-Zahlungsschlüssel im projektweiten Scope.
Die vollständige Mechanik, einschließlich wie man eine produktionsspezifische Variable hinzufügt und wie die Staging-Vererbung funktioniert, finden Sie in Setting Environment Variables Per Environment.
Build-Protokolle für eine Vorschau
Klicken Sie auf View logs neben einer beliebigen Vorschau, um die Deployment-Detailseite zu öffnen. Vorschauen werden gleich wie Produktionsbereitstellungen behandelt: vollständiges Streaming-Build-Protokoll, Build-Phasen, Commit und Autor, Artefaktgröße, Cache-Hit oder Cold Build, erkanntes Framework und Paketmanager, und die KI-Diagnose-Schaltfläche, wenn ein Build fehlschlägt.
Löschen einer Vorschau
Klicken Sie auf die Schaltfläche zum Löschen in der Vorschauzeile und bestätigen Sie.
Das Löschen einer Vorschau entfernt die Umgebung und ihre gesamte Build-Verlauf, nicht nur die aktuelle Bereitstellung. Dies kann nicht rückgängig gemacht werden. Der Branch selbst bleibt unverändert, daher erstellt ein erneuter Push zu diesem Branch eine frische Vorschau von Grund auf mit keinem Verlauf und einem kalten Build-Cache.
Automatische Bereinigung
Sie müssen sich nicht selbst aufräumen.
- Wenn ein Pull Request geschlossen oder zusammengeführt wird, wird seine Vorschauumgebung sofort unterbrochen und stoppt die Bereitstellung. Besucher erhalten einen 404 statt eines veralteten Builds.
- Das Löschen eines Branchs setzt diesen Branch-Preview auf die gleiche Weise aus.
- Unterbrochene Vorschauen werden etwa einen Tag später bereinigt: die Quell-Tarballs, Build-Artefakte und Build-Caches werden gelöscht und die Umgebung wird archiviert.
Sie können Vorschauen auch nach einem Zeitplan ablaufen lassen. Suchen Sie in Settings nach Preview expiry und wählen Sie Never, 7, 14, 30 oder 60 days. Vorschauen, die älter als das sind, werden automatisch unterbrochen und innerhalb von 24 Stunden bereinigt.
Legen Sie in einem ausgelasteten Repository Preview expiry auf 14 oder 30 days fest. Jede aktive Vorschau zählt gegen Ihr Projektumgebungslimit, und abgelaufene sind der übliche Grund, warum ein neuer Branch unauffällig keine Vorschau erhält.
Genehmigung und Vorschauen
Wenn Require approval for production unter Deploy protection aktiviert ist, gilt dies nur für die Produktion. Preview-Builds werden nicht zur Genehmigung zurückgehalten.
Um zu verhindern, dass eine bestimmte Vorschau weitere Änderungen bereitstellt, ohne sie zu löschen, unterbrechen Sie die Umgebung in der Registerkarte Environments. Neue Bereitstellungen in einer unterbrochenen Umgebung werden übersprungen, bis Sie sie fortsetzen.
Fehlerbehebung
Ein Branch wurde gepusht, aber keine Vorschau erschien. Überprüfen Sie in dieser Reihenfolge: Ist Branch previews in Settings dann Runtime aktiviert? Ist der Branch tatsächlich Ihr Staging-Branch (Staging wird auf Staging bereitgestellt, nicht in eine Vorschau)? Stimmt der Branch mit einem Ihrer Branch ignore patterns überein, zum Beispiel dependabot/*? Ist das Projekt bereits am Umgebungslimit für Ihren Plan?
Die Vorschau wurde erstellt, zeigt aber einen 404. Der Build war erfolgreich, aber das Output-Verzeichnis ist wahrscheinlich für diesen Branch falsch. Überprüfen Sie Output directory in Settings, und bedenken Sie, dass ein Branch die Build-Ausgabe ändern kann, ohne die Einstellung zu ändern. Siehe Configuring Your Build Command and Output Directory.
Die Vorschau zeigt einen älteren Commit. Das Pushen eines neuen Commits während ein Build für denselben Branch noch läuft, bricht den laufenden Build ab und startet einen neuen. Wenn Sie eine abgebrochene Bereitstellung gefolgt von einer laufenden sehen, ist das erwartet. Warten Sie auf den zweiten Build.
Die Vorschau eines geschlossenen PR ist immer noch erreichbar. Das Unterbrechen erfolgt beim Webhook-Ereignis. Wenn die Anbieterverbindung getrennt wurde, als Sie den PR geschlossen haben, traf das Ereignis nie ein. Löschen Sie die Vorschau manuell in der Übersichtsregisterkarte.
Weiterführende Lektüre
- Deploying Your Project
- Setting Environment Variables Per Environment
- Orbit Plan Limits für die Umgebungszuteilung in jedem Plan