Eine statische Website mit Pages veröffentlichen

Opfield Pages veröffentlicht eine statische Website als unveränderliches Artefakt mit einem ausdrücklichen Übernahmezeiger. Ein Deployment ist ein fester Satz von Dateien; ein Tag ist ein verschiebbarer Name wie production; eine Route leitet eine öffentliche Domain auf diesen Tag. Diese Trennung erlaubt es einem Team, ein Release zu prüfen und durch Verschieben eines Zeigers zurückzusetzen, statt Dateien an Ort und Stelle zu ändern.

Pages ist für statische Ausgaben gedacht – HTML, JavaScript, CSS, Bilder, Schriftarten und andere Dateien, die nginx ausliefert. Es bietet keine serverseitige Anwendungslaufzeit. Ein Framework kann während des Builds verwendet werden, seine Ausgabe muss aber ein statisches Artefakt sein, das zum konfigurierten Artefaktverzeichnis passt.

Die Opfield-Landingpage und dieses Dokumentationsportal laufen auf Opfield Pages, mit denselben Deployments, Tags, Routen und demselben Rollback, die hier beschrieben sind.

Beginnen Sie mit der Pages-Übersicht. Bereiten Sie für die Git-Auslieferung Pages-Git-Deployments und eine Integration der Quellcodeverwaltung vor. Eine eigene Domain erfordert außerdem den Weg über Domain, Route und TLS.

Den Release-Vertrag festlegen

Entscheiden Sie vor dem Erstellen des Projekts:

• welcher Ingress Node bzw. welche Platzierung für die statischen Dateien zuständig ist;
• wer Deployments hochladen oder bauen darf;
• welcher Tag die Produktion darstellt und wer ihn verschieben darf;
• welche Domain, welches Zertifikat und welche Route den Tag veröffentlichen;
• ob Quelländerungen automatische Builds oder automatische Deployments auslösen;
• welche für Clients sichtbaren Laufzeitwerte erlaubt sind;
• Aufbewahrungsanforderungen für Vorschau- und Rollback-Deployments.

Das Projekt ist für den Deployment-Verlauf, Tags, Laufzeitkonfiguration, Routen und das Aufbewahrungsverhalten zuständig. Das Quell-Repository – sofern verwendet – ist für den Quellcode zuständig, aber nicht direkt für die öffentliche Route.

Das statische Artefakt vorbereiten

Bauen Sie die Website in einer sauberen Umgebung und bestätigen Sie, dass das Ausgabeverzeichnis die Einstiegsdokumente und alle referenzierten Assets enthält. Testen Sie clientseitiges Routing und Basispfade mit einem statischen Server statt mit einem Entwicklungsserver. Entwicklungsserver können fehlende Dateien, Rendering nur auf dem Server oder falsche Asset-URLs verdecken.

Nehmen Sie keine Source Maps, Testdaten, Umgebungsdateien, privaten Repository-Metadaten, Zugangsdaten, interne Topologie oder Build-Caches auf, sofern sie nicht bewusst öffentlich sind. Alles innerhalb eines Pages-Artefakts muss als herunterladbarer öffentlicher Inhalt behandelt werden, auch wenn die Benutzeroberfläche nicht auf eine Datei verlinkt.

Weg mit manuellem Artefakt

1. Aktivieren Sie Pages in den Funktionseinstellungen und bestätigen Sie, dass der aktuelle Tarif die Verwaltung von Pages erlaubt.
2. Erstellen Sie ein Pages-Projekt und wählen Sie einen geeigneten Ingress Node.
3. Konfigurieren Sie Projektkontingente, Aufbewahrung und Zugriff, bevor Sie ein Produktionsartefakt hochladen.
4. Laden Sie das vorbereitete Artefakt über die Konsole, die fortsetzbare Deployment-API oder den authentifizierten Upload-Link von Remote-MCP hoch. Ein Artefakt darf so groß sein wie das File upload limit, standardmäßig 100 MB und höchstens 500 MB; siehe Pages-Übersicht.
5. Schließen Sie den Upload ab. Opfield validiert und erstellt ein neues unveränderliches Deployment, statt ein älteres zu ändern.
6. Öffnen Sie die unveränderliche Vorschau und prüfen Sie das genaue Artefakt.
7. Verschieben Sie den systemverwalteten Tag latest oder einen eigenen Release-Tag erst nach der Freigabe auf dieses Deployment.
8. Erstellen oder aktualisieren Sie eine Pages-Route für die öffentliche Domain und den ausgewählten Tag.

Ein unterbrochener Upload ist kein Release. Setzen Sie den Upload über den unterstützten Ablauf fort oder starten Sie ihn neu und schließen Sie ihn einmal ab; kopieren Sie keine unvollständigen Dateien manuell auf einen Ingress Node.

Weg mit Git-Build

Verbinden Sie in Business und Enterprise ein GitLab-, GitHub- oder generisches Git-Repository von der Allowlist mit dem Pages-Projekt. Wählen Sie den Branch und das Anwendungsverzeichnis, lassen Sie Opfield gegebenenfalls package.json erkennen und konfigurieren Sie den Paketmanager, die Node-Version, das Build-Skript und das Artefaktverzeichnis.

Der Build läuft auf einem isolierten Build Worker. Fügen Sie quellbezogene Build Secrets nur für den Zugriff zur Build-Zeit hinzu; sie dürfen nicht in die statische Ausgabe gelangen. Prüfen Sie vor der Veröffentlichung den genauen Commit, die Logs, gegebenenfalls das Ergebnis der Schwachstellen- bzw. Richtlinienprüfung, den Worker und das erzeugte Artefakt.

Halten Sie automatischen Build und automatisches Deployment getrennt. Ein automatischer Build kann bei jedem freigegebenen Quellereignis einen Vorschaukandidaten vorbereiten. Ein automatisches Deployment verschiebt einen Tag und ändert, was eine Route ausliefert; aktivieren Sie es nur, wenn Branch-Schutz und Abnahmeprüfungen für dieses Risiko stark genug sind.

Laufzeitkonfiguration

Pages kann für Clients sichtbare Laufzeitkonfiguration unter /_opfield/pages/config.js als window.runtime.config ausliefern. Der Wert ist öffentlich, auf 64 KiB begrenzt und wird mit no-store ausgeliefert. Ein Default-Objekt gilt allgemein, und Tag-spezifische Überschreibungen des gesamten Objekts können es für einen gerouteten Tag ersetzen. Unveränderliche Vorschauen verwenden Default.

Verwenden Sie die Laufzeitkonfiguration für nicht geheime Werte, die sich berechtigterweise je nach Umgebung unterscheiden, etwa öffentliche API-Origins, die Darstellung von Funktionen oder Analytics-Kennungen. Legen Sie niemals Passwörter, API-Schlüssel, private Endpunkte, Signaturmaterial, Daten nur für Kunden oder Netzwerktopologie darin ab.

Eine Änderung der Laufzeitkonfiguration erstellt kein neues Deployment und ändert nicht den Hash des Artefakts. Halten Sie die Konfiguration abwärtskompatibel, solange ein Tag zwischen alten und neuen Releases wechseln kann.

Die Domain veröffentlichen

Erstellen oder wählen Sie die Domain und das Zertifikat und erstellen Sie dann eine Pages-Route, die auf das gewählte Projekt und den Tag zielt. Routen zielen auf Tags, nicht auf rohe Deployments. So bleiben Übernahme und Rollback ausdrücklich und werden erfasst.

Prüfen Sie DNS, TLS, das zurückgegebene Einstiegsdokument, verschachtelte Assets, die clientseitige Navigation, das Caching-Verhalten, window.runtime.config und Fehlerseiten. Testen Sie aus einer sauberen Browsersitzung und aus einem externen Netzwerk. Eine unveränderliche Vorschau weist das Artefakt nach; die öffentliche Route weist zusätzlich DNS, TLS, die Tag-Auswahl und die Bereitstellung auf dem Ingress nach.

Erfolgskriterien

• Das Pages-Deployment ist Ready und hat eine unveränderliche Vorschau.
• Der vorgesehene Tag zeigt auf das geprüfte Deployment.
• Die öffentliche Route liefert diesen Tag über vertrauenswürdiges TLS aus.
• Statische Assets und clientseitige Routen funktionieren über direkte Einstiegs-URLs.
• Weder im Artefakt noch in der Laufzeitkonfiguration befindet sich ein Secret oder eine nur intern bestimmte Datei.
• Der Commit- bzw. Build-Eintrag des Deployments ist sichtbar, wo Git-Auslieferung verwendet wird.
• Ein früheres, bekannt fehlerfreies Deployment bleibt für ein Rollback verfügbar.

Rollback und Bereinigung

Verschieben Sie für ein Rollback den öffentlichen Tag auf das vorherige geprüfte Deployment. Testen Sie danach Route, Assets, Laufzeitkonfiguration und Browserverhalten erneut. Bearbeiten oder ersetzen Sie das fehlerhafte Deployment nicht an Ort und Stelle; sein unveränderlicher Eintrag ist für die Diagnose nützlich und weist nach, was tatsächlich veröffentlicht wurde.

Das Löschen eines Deployments kann ein Rollback-Ziel entfernen. Prüfen Sie zuerst Tag-Referenzen und Aufbewahrungsanforderungen. Das Löschen eines Tags oder einer Route ändert die Erreichbarkeit, aber nicht das unveränderliche Artefakt. Deaktivieren Sie Pages global nur nach einer ausdrücklichen Produktentscheidung; das Deaktivieren der Navigation ersetzt nicht die Außerbetriebnahme öffentlicher Routen und das Aufbewahren benötigter Belege.

Diagnoseübersicht

Symptom	Zuerst prüfen	Ausführliche Anleitung
Upload wurde unterbrochen	Upload-Status und Task; keine unvollständigen Dateien manuell kopieren	Tasks, Ereignisse und Audit
Git-Build ist fehlgeschlagen	Quelleinstellungen, Build Worker, Logs und Richtlinienentscheidung	Pages-Git-Deployments
Vorschau funktioniert, öffentliche Route schlägt fehl	Tag, Domain, DNS, TLS und Ingress-Platzierung	Fehlerbehebung beim Ingress
Direkte URL liefert 404	Einstiegsdokument, Basispfad und clientseitiges Routing	Pages-Git-Deployments
Laufzeitkonfiguration ist falsch	Default, Tag-Überschreibung des gesamten Objekts und Versionskompatibilität	Pages-Übersicht
Kein Rollback-Ziel mehr vorhanden	Tag-Referenzen und Aufbewahrung von Deployments	Pages-Übersicht