Orbit Projekteinstellungen

Jede Einstellung für ein Orbit-Projekt befindet sich auf der Registerkarte „Settings" (Einstellungen), gruppiert damit Sie alles leicht finden können: allgemeine Informationen, Build und Bereitstellung, Sicherheit, Benachrichtigungen, Integrationen, Nutzungslimits, Bereitstellungsautomation, Netzwerk, Observability, Freigabe und eine Gefahrenzone am unteren Ende.

Wo sich die Einstellungen befinden

Öffnen Sie Orbit, klicken Sie auf das Projekt und wählen Sie Settings in der Registerkarte des Projekts. Die Seite beschreibt sich selbst als Konfiguration Ihres Projektnamens, Build-Befehle und Git-Integration, was damit nicht im Entferntesten beschrieben ist.

Diese Anleitung ist eine Orientierungshilfe. Wenn ein Thema einen eigenen Artikel hat, wird darauf verlinkt, anstatt ihn zu wiederholen.

Allgemein

Project info zeigt den URL-Slug, das Erstellungsdatum, das verbundene Repository und die Production-URL an. Sie können den Projektnamen (Name) und die Beschreibung (Description) ändern.

Git enthält den Production branch. Pushes zu diesem Branch lösen Production-Bereitstellungen aus.

Status badge liefert Ihnen ein Live-Deploy-Status-SVG mit Kopierschaltflächen für die URL, Markdown und HTML, bereit zum Einfügen in Ihre README. Siehe Viewing Your Project README In Orbit.

Public status page verlinkt zur Statusseiten-Konfiguration. Siehe Orbit Status Page.

Build und Bereitstellung

Build settings sind die fünf Felder, die Orbit automatisch erkennt und die Sie überschreiben können: Install-Befehl, Build-Befehl, Ausgabeverzeichnis, Root-Verzeichnis und Node.js-Version. Lassen Sie ein Feld leer, um den erkannten Wert zu behalten. Vollständige Details finden Sie unter Configuring Your Build Command and Output Directory.

Runtime hat vier Schalter, die es zu verstehen gibt:

• Server mode hält die Build-Maschine am Leben und führt Ihren Start-Befehl nach jeder Bereitstellung aus. Erforderlich für alles, das auf dem Server gerendert wird, anstatt statische Dateien zu exportieren.
• Branch previews erstellen automatisch für jeden Branch-Push, der nicht Production oder Staging ist, eine Umgebung auf ihrer eigenen URL unter branch-*.kaps.run. Siehe Branch Previews.
• Auto-rollback on failure stellt die letzte fehlerfreie Production-Bereitstellung wieder her, falls eine Bereitstellung fehlschlägt.
• Scheduled rebuild erstellt Production in regelmäßigen Abständen neu, von stündlich bis wöchentlich, was sich für inhaltsverwaltete Websites eignet, die eine Aktualisierung ohne Git-Push benötigen.

Build auto-retry stellt fehlgeschlagene Builds erneut in die Warteschlange, die auf Infrastrukturfehlern wie einem Netzwerkproblem oder einem Timeout basieren, bis zu dreimal. Es wiederholt keine Code-Fehler, daher kann es einen unterbrochenen Build nicht maskieren.

Ignored paths und Branch ignore patterns verhindern Builds, die Sie nicht benötigen: Glob-Muster für Dateien, deren Änderungen nicht bereitgestellt werden sollten, und für Branches wie dependabot/*, die niemals einen auslösen sollten.

Git tag deploys setzt das Tag-Muster, das einen Tag-Push in eine Production-Bereitstellung umwandelt. Siehe Orbit Releases.

Bereitstellungsautomation und Schutz

Deploy protection hat zwei Gates: Require approval for production, das durch Push ausgelöste Production-Bereitstellungen pausiert, bis jemand zustimmt, und Require staging success before production, das Production wartet, bis Staging denselben Commit erfolgreich bereitgestellt hat.

CI required checks gates Bereitstellungen in Ihrem eigenen CI. Auf GitHub listen Sie Jobnamen auf, die alle bestanden sein müssen; auf GitLab wartet jeder nicht leere Wert auf die gesamte Pipeline. Ein CI-Fehler bricht die Bereitstellung ab.

Deploy freeze schedule blockiert durch Push ausgelöste Bereitstellungen außerhalb genehmigter Fenster, entweder an Wochenenden oder in einem UTC-Stundenbereich. Manuelle Bereitstellungen und Deploy Hooks sind nicht betroffen.

Branch protection fügt Glob-Pattern-Regeln hinzu, die Bereitstellungen auf passenden Branches blockieren, bis erforderliche externe Überprüfungen bestanden sind und optional ein Mensch zustimmt.

Auto-promote staging leitet Staging automatisch an Production weiter, sobald es für eine konfigurierte Anzahl von Stunden ohne Fehler ausgeführt wurde und Smoke Tests bestanden wurden.

All diese sind in einer Ansicht auf der Registerkarte Orbit Deployment Pipeline zusammengefasst.

Zustand und Qualitätsgates

Health check ruft nach jeder Production-Bereitstellung einen Pfad ab, den Sie auswählen. Eine Nicht-2xx-Antwort innerhalb von 15 Sekunden stellt die vorherige fehlerfreie Bereitstellung wieder her.

Smoke tests führen GET-Anfragen gegen bis zu zehn komma getrennte Pfade nach jeder erfolgreichen Bereitstellung aus und erfassen Bestehen oder Fehlschlag. In Kombination mit Auto-Rollback führt ein fehlgeschlagener Smoke Test zu einem Rollback der Bereitstellung.

Performance budgets warnen oder unterbrechen Builds, die einen Schwellwert überschreiten: Gesamtartefaktgröße in MB, individuelle Dateigröße in kB, die mit einem Glob übereinstimmt, oder Build-Zeit in Sekunden. Jedes Budget ist entweder auf Warnung oder Fehler beim Build eingestellt.

Staging

Staging hat einen eigenen Satz von Karten: den staging branch, access protection mit einem Passwort, eine IP allowlist mit IPv4-Adressen und CIDR-Bereichen je pro Zeile, auto-rollback on failure, ob Staging inherits production environment variables mit niedrigerer Priorität und build overrides für Install, Build, Ausgabe und Root-Verzeichnis.

Passwort und IP-Allowlist sind die beiden, die auf jeder Staging-Umgebung festgelegt werden sollten, die nicht öffentlich sein soll. Lassen Sie beide leer und die Staging-URL ist für jeden erreichbar, der sie hat.

Netzwerk

Custom domains fügt Domänen für die Production-Umgebung hinzu und überprüft sie, einschließlich Zertifikatbereitstellung. Siehe Adding a Custom Domain to Orbit.

Redirects and rewrites sind pfadbasierte Regeln, die vor dem Serving angewendet und in Reihenfolge getestet werden, wobei der erste Match gewinnt. Eine Umleitung sendet den Browser als 301 oder 302 zu einer neuen URL; ein Rewrite bedient einen anderen Pfad lautlos ohne URL-Änderung. Muster unterstützen exakte Übereinstimmungen, Wildcards, benannte Parameter und Splats. Siehe Redirects and Rewrites in Orbit.

Response headers wenden benutzerdefinierte HTTP-Header auf passende Pfade an, mit voreingestellten Einstellungen für HSTS, CSP, No-Embed, No-Sniff, Referrer Policy und CORS. Alle passenden Regeln werden angewendet, und später eingegebene Einträge überschreiben frühere Einträge für denselben Schlüssel.

Skew protection bewahrt alte Build-Artefakte im Speicher für ein Aufbewahrungsfenster auf, nachdem eine neue Bereitstellung aktiviert wird, damit ein Besucher, der die vorherige Version geladen hat, deren Assets weiterhin abrufen kann, anstatt einen 404 zu erhalten.

The config store enthält Schlüssel/Wert-Einstellungen, die Ihre Bereitstellung zur Laufzeit liest, für Feature Flags und Einstellungen, die sich ohne erneute Bereitstellung ändern. Es wird unter „Storage" verwaltet, nicht hier, und es ist kostenlos: es gibt keine Lesegebühr und keine Schreibgebühr. Werte werden als Klartext gespeichert, daher sollten Sie niemals ein Geheimnis in einen eintragen. Bis zu 100 Einträge pro Projekt, Schlüssel bis zu 200 Zeichen und Werte bis zu 4096. Jede Nacht wird ein Snapshot von jedem Eintrag erstellt und 30 Nächte werden bei jedem Plan beibehalten, sodass ein gelöschter Eintrag wiederhergestellt werden kann: siehe Snapshots and restore.

Nutzung und Limits

Build usage zeigt die Builds an, die dieses Projekt ausgeführt hat.

Spending cap setzt die maximale monatliche Überziehungsausgaben, die Build-Minuten und Bandbreitenüberziehungen über Ihre Planzuteilung hinaus abdecken. Das Minimum ist US$6.32 und das Maximum US$6,315.79. Warnungen werden bei 50% und 80% angezeigt, und bei 100% wird das Serving pausiert, bis Sie die Obergrenze erhöhen. Siehe Orbit Spending Cap.

Build spending cap ist das separate, stumpfere Limit: eine monatliche Obergrenze für die Gesamtzahl der Build-Minuten, nach der neue Builds nicht mehr in die Warteschlange eingereiht werden, bis nächsten Monat oder Sie erhöhen es.

Artifact retention setzt, wie viele erfolgreiche Build-Artefakte pro Umgebung beibehalten werden sollen. Ältere werden täglich gelöscht, und die derzeit aktive Bereitstellung wird unabhängig vom Limit immer beibehalten.

Preview expiry pausiert Preview-Umgebungen nach 7, 14, 30 oder 60 Tagen oder nie. Pausierte Previews haben ihren Speicher innerhalb von 24 Stunden zurückgefordert.

Artifact size alert sendet Ihnen eine E-Mail, wenn ein Build-Artefakt eine von Ihnen festgelegte Größe überschreitet.

Benachrichtigungen, Integrationen und Observability

Deploy email notifications hat drei Einstellungen: alle Bereitstellungen, nur Fehler oder aus. Eine notification webhook URL kann daneben eingestellt werden und wird bei jedem Erfolg oder Fehler gepostet.

Notification channels ist die umfangreichere Version mit Auswahl pro Ereignis, Lieferverlauf und einer Test-Schaltfläche. Die vollständige Webhook-Kontrolle befindet sich auf einer eigenen Registerkarte: siehe Orbit Webhooks.

Deploy hooks erstellt geheime URLs, die eine Bereitstellung auslösen, wenn etwas an sie gepostet wird. Siehe Triggering Deployments Via Deploy Hooks.

Log drains versenden Build-Protokolle nach jeder Bereitstellung an Ihre Observability-Plattform, mit integrierter Unterstützung für Datadog, Logtail, Axiom und New Relic oder einen benutzerdefinierten Webhook, optional gefiltert auf eine Umgebung.

Web Analytics gibt Ihnen das Core Web Vitals-Erfassungs-Snippet. Siehe Orbit Web Vitals.

Cron triggers plant HTTP-Anfragen an eine gewählte Umgebung, bis zu zehn pro Projekt. Die größere, nur Production-Version befindet sich auf einer eigenen Registerkarte: siehe Orbit Cron Jobs.

Freigabe und Team

Team verwaltet Mitarbeiter mit drei Rollen: Admin, Developer und Viewer.

Share links generieren temporäre kennwortlose Links, damit ein externer Reviewer eine Umgebung ohne Passwort oder Konto anzeigen kann. Jeder Link kann in 1 Stunde, 24 Stunden oder 7 Tagen oder nie ablaufen und zeigt die Besucherzahl an. Widerrufen Sie ihn jederzeit.

Deployment group verbindet dieses Projekt mit einer Gruppe, damit zusammenhängende Projekte zusammen bereitgestellt werden, optional gefiltert nach Branch.

Clone environment und Clone project duplizieren die Konfiguration. Das Klonen eines Projekts kopiert Build-Einstellungen, Umgebungskonfiguration und nicht geheime Umgebungsvariablen; Geheimnisse werden nicht kopiert.

Gefahrenzone

Clear build cache löscht die zwischengespeicherten Abhängigkeiten für jede Umgebung, damit die nächste Bereitstellung eine vollständige Installation von Grund auf ausführt. Es kann nicht rückgängig gemacht werden, obwohl sich der Cache beim nächsten Build selbst regeneriert.

Transfer project verschiebt das Projekt zu einem anderen Kapsule-Konto. Siehe Transferring an Orbit Project.

Archive project stoppt die Verkehrsbedienung sofort. Es kann innerhalb von 30 Tagen aus der Orbit-Liste wiederhergestellt werden, danach wird es dauerhaft gelöscht.

Wo es weiter geht

• Orbit Deployment Pipeline zum Anzeigen der Auswirkung aller Einstellungen in einer Ansicht.
• Shared Environment Variable Groups für Werte, die über Projekte hinweg verwendet werden.
• Orbit Plan Limits für das, was Ihr Plan zulässt.