Pages-Git-Deployments

Verbinden und beschränken Sie zuerst das Repository über Git-Hosting. Connector-Zugriff, Berechtigungen für Pages-Deployments und die Berechtigung zum Ansehen des Build-Verlaufs sind getrennte Prüfungen.

Ein Pages-Git-Deployment macht aus einer ausgewählten Repository-Revision ein neues unveränderliches Deployment einer statischen Website. Die Git-Quelle und der Build Worker erzeugen das Artefakt; das Pages-Projekt besitzt den veröffentlichten Deployment-Verlauf; Tags und Routen steuern, wann dieses Artefakt die Benutzer erreicht.

Entscheiden Sie, ob ein erfolgreicher Build nur einen Kandidaten zur Prüfung erstellt oder auch automatisch einen Veröffentlichungs-Tag verschiebt. Halten Sie die Veröffentlichung manuell, bis Vorschau, Prüfung und Rollback für die Website funktionieren. Ein grüner Build beweist, dass ein Artefakt erzeugt wurde; er beweist nicht, dass die öffentliche Domain, die TLS-Route oder das Laufzeitverhalten auf dem Client korrekt sind.

Git-basierte Pages-Builds erfordern einen Business- oder Enterprise-Tarif. Manuelle statische Uploads funktionieren ab Personal. Beide verwenden dieselben unveränderlichen Deployments, daher funktionieren Prüfung, Veröffentlichung und Rollback gleich.

Bevor Sie beginnen

Verbinden Sie eine unterstützte Git-Integration und wählen Sie ein Repository und einen Branch, den die Integration lesen darf. Bestätigen Sie, dass ein dedizierter Build Worker online ist, das Projekt die richtige Build-Definition hat und benötigte quellbezogene Build Secrets verfügbar sind. Build Secrets sind für die isolierte Build-Grenze gedacht; die Laufzeitkonfiguration ist öffentlich und darf diese Secrets nicht enthalten.

Prüfen Sie die package.json des Repositorys, wenn sie für die Build-Erkennung verwendet wird, wählen Sie den passenden Paketmanager und Build-Befehl und stellen Sie sicher, dass die Ausgabe ein Artefakt einer statischen Website ist. Ein Git-Deployment macht über Pages keine serverseitige Anwendungslaufzeit verfügbar.

Der Connector sollte nur Lesezugriff auf die ausgewählten Repositories haben. Der Build Worker benötigt genug Kapazität für die Installation von Abhängigkeiten und den statischen Build, sollte sich aber keinen veränderlichen Arbeitsbereich mit Produktions-Workloads teilen. Quellbezogene Build Secrets sind nur innerhalb der isolierten Build-Grenze verfügbar und dürfen niemals in generierte statische Dateien oder öffentliche Laufzeitkonfiguration kopiert werden.

Erfolg vor dem Aktivieren der Automatisierung festlegen

Halten Sie den erwarteten Branch, das Anwendungsverzeichnis, den Paketmanager, die Node.js-Version, das Build-Skript, das Artefaktverzeichnis, den Veröffentlichungs-Tag und den Verantwortlichen fest. Legen Sie dann die Abnahmeprüfung für die erzeugte Website fest: erwartetes Einstiegsdokument, Verhalten bei direkter Navigation, Laden von Assets, Metadaten, Sprachrouten, Sitemap oder Suchindex, sofern zutreffend, und dass keine Secrets im Artefakt stehen.

Aktivieren Sie automatische Builds, wenn jede relevante Quelländerung einen Kandidaten erzeugen soll. Aktivieren Sie das automatische Deployment nur, wenn jeder erfolgreiche Kandidat den konfigurierten Tag sicher verschieben darf. Bei Dokumentations- und Marketing-Websites erlaubt ein automatischer Build mit ausdrücklicher Übernahme in die Produktion, zuerst die unveränderliche Vorschau zu prüfen. Builds verwenden die Zugangsdaten des Connectors und hängen nicht von den aktuellen Git-Scopes einer Person ab; integrations:<provider>:use auf dem Repository wird nur benötigt, um die Quelle zu verbinden oder ihren Connector, ihr Repository oder ihren Branch zu ändern. Siehe Wer darf bauen und Ergebnisse ansehen?.

Ein Deployment bauen

1. Wählen Sie Repository, Branch und vorgesehene Revision für das Pages-Projekt.
2. Konfigurieren Sie Build-Erkennung, Paketmanager, Build-Befehl und quellbezogene Build Secrets.
3. Starten Sie den Build und verfolgen Sie die Operation auf ihrem zugewiesenen isolierten Build Worker.
4. Prüfen Sie das geschwärzte Build-Log, das Richtlinienergebnis, die Quellrevision und die unveränderliche Ausgabe.
5. Erstellen oder wählen Sie das resultierende Deployment und testen Sie es dann, bevor Sie einen Produktions-Tag verschieben.

Der Build ist bewusst von der Veröffentlichung getrennt. Ein abgeschlossener Build erstellt ein unveränderliches Kandidaten-Deployment; er ändert weder einen eigenen Tag noch eine Route. Automatischer Build und automatisches Deployment sollten als unabhängige Steuerungen behandelt werden, wobei das automatische Deployment erst aktiviert wird, wenn der Weg aus Health-Zustand, Übernahme und Rollback verstanden ist.

Übernehmen und prüfen

Verschieben Sie den vorgesehenen Tag auf das freigegebene Deployment. Routen zielen auf diesen Tag, daher ist das Verschieben das Übernahmeereignis. Prüfen Sie das DNS- und TLS-Verhalten der öffentlichen Domain, das zurückgegebene Dokument und die statischen Assets, das für Clients sichtbare window.runtime.config und den Status der Projektoperation. Verwenden Sie, wo konfiguriert, eine unveränderliche Vorschau, um ein bestimmtes Artefakt zu prüfen, ohne einen öffentlichen Tag zu verschieben.

Halten Sie für das Rollback-Fenster ein früheres bekannt fehlerfreies Deployment verfügbar. Die Laufzeitkonfiguration muss kompatibel bleiben, solange derselbe Tag eines der beiden Releases auswählen kann: Ihre Änderung kann das Verhalten der Website ändern, ohne ein neues Deployment zu erstellen oder Artefakt-Hashes zu ändern.

Fehlgeschlagener Build, Abbruch und Rollback

Ein fehlgeschlagener oder abgebrochener Build darf das aktive öffentliche Release nicht ändern. Prüfen Sie die Worker-Zuweisung und die Logs, um Fehler bei Quellautorisierung, Abhängigkeiten, Build-Befehl, Build Secret, Richtlinie oder Artefaktausgabe zu unterscheiden. Beheben Sie die Ursache und versuchen Sie es erneut; jede Wiederholung erstellt eine neue Operation, statt das historische Ergebnis zu verändern.

Während eines Opfield-Updates werden Builds, die von Webhooks oder Polling ausgelöst werden, zurückgestellt und starten einmal, nachdem das Update abgeschlossen ist.

Verursacht ein übernommenes Release einen Vorfall, verschieben Sie den Tag der Route zurück auf das vorherige geprüfte Deployment. Prüfen Sie dann die Antwort der Route, die Assets, die Laufzeitkonfiguration und den Anwendungszustand in nginx. Bearbeiten oder ersetzen Sie das fehlerhafte Deployment nicht an Ort und Stelle: Sein unveränderlicher Eintrag ist wichtig für die Diagnose und als Beleg für das Rollback.

Details für Betreiber: Einordnung von Build-Fehlern

Ordnen Sie den Fehler ein, bevor Sie es erneut versuchen:

Fehlerbereich	Typischer Beleg	Sicherer nächster Schritt
Quellautorisierung	Repository oder Revision kann nicht gelesen werden	Reparieren Sie die Berechtigungen des Connectors; erweitern Sie den Zugriff nicht standardmäßig auf die ganze Organisation
Installation der Abhängigkeiten	Fehler bei Lockfile, Registry oder Paketmanager	Reproduzieren Sie mit demselben Paketmanager und Lockfile; prüfen Sie nur das benötigte Registry-Secret
Build-Befehl	Skript endet mit einem Exit-Code ungleich null oder Framework-Ausgabe fehlt	Beheben Sie den Build im Repository und behalten Sie den fehlgeschlagenen Job zum Vergleich
Artefaktvertrag	Ausgabeverzeichnis fehlt, ist leer oder nicht statisch	Korrigieren Sie das Artefaktverzeichnis oder die Build-Ausgabe; veröffentlichen Sie kein unvollständiges Verzeichnis
Richtlinie oder Zulassung	Build vor der Veröffentlichung abgelehnt	Lösen Sie den gemeldeten Richtlinienbefund oder holen Sie eine ausdrücklich freigegebene Ausnahme ein
Veröffentlichung	Deployment existiert, aber Tag oder Route wurde nicht verschoben	Prüfen Sie die Einstellungen für automatisches Deployment und die Pages-Operation; bauen Sie ein gültiges Artefakt nicht neu

Ein Abbruch stoppt die aktive Build-Operation, löscht aber keine früheren Deployments und verschiebt keinen bestehenden Produktions-Tag. Das Wiederholen eines Builds behält den genauen Commit-SHA des ursprünglichen Builds bei, was die Wiederholung reproduzierbar macht, auch wenn sich der konfigurierte Branch bewegt hat. Starten Sie einen neuen Quell-Build, wenn der neuere Branch-Stand die vorgesehene Eingabe ist.

Manuelle Releases und Bereinigung

Ein manuelles Pages-Release folgt demselben Übernahmemodell: Erstellen Sie aus dem vorbereiteten statischen Artefakt ein neues unveränderliches Deployment, prüfen Sie es und verschieben Sie einen Tag erst, wenn es bereit ist. Der Git-Verlauf ist für die Herkunft nützlich, aber nicht erforderlich, damit ein manuelles Artefakt am selben Tag- und Routen-Lebenszyklus teilnimmt.

Entscheiden Sie beim Trennen einer Git-Quelle, welche bestehenden Deployments für ein Rollback erforderlich bleiben. Das Entfernen der Quelle stoppt künftige quellgesteuerte Builds; es hebt die Veröffentlichung eines bestehenden Tags nicht automatisch auf und löscht kein bereitgestelltes Artefakt. Prüfen Sie Tag-Referenzen und Aufbewahrung, bevor Sie ein Deployment löschen.

Prüfen Sie bei sensiblen Repositories die Build-Logs, bevor Sie sie teilen. Opfield schwärzt verwaltete Build Secrets, aber Build-Skripte können dennoch Repository-Inhalte ausgeben oder sensible Werte ableiten. Behandeln Sie die Build-Definition als Produktionscode und halten Sie Secrets aus Befehlen, Dateinamen, generierten Manifesten und Client-Bundles heraus.