Im Juni liefen unsere generierten Apps in Vorschauumgebungen. Ich konnte mir einen Bildschirm ansehen, während die Pipeline ihn veränderte. Beim Entwickeln war das nützlich. Die Kundschaft würde ich aber nicht in dieselbe Umgebung lassen. Wir haben uns vorgenommen, die Produktion von dieser Bearbeitungsschleife zu trennen und Projekte an GitHub übergeben zu können.
In der ursprünglichen Mitteilung zum Release habe ich Teile davon zu selbstsicher beschrieben. Diese Überarbeitung trennt das Design von dem, was wir am 15. Oktober 2026 überprüfen können. Implementierung und Dokumentation sehen Wege für Deployment und GitHub vor. Das allein bestätigt aber nicht jeden Live-Rollout, jede Domainänderung oder jedes Rollback.
Die Grenze zur Produktion
Eine Vorschau wird laufend neu gebaut, während du arbeitest. Das Design setzt eine bewusste Freigabe zwischen diese veränderliche Umgebung und die App, mit der Menschen arbeiten. Ein Produktions-Deployment sollte die Version ausliefern, die du ausgewählt hast.
Der Produktionshost ist dafür ausgelegt, vorgebaute Artefakte zu nutzen, ohne die Bearbeitungswerkzeuge der Vorschau. Produktionskonfiguration und Zugangsdaten haben ihren eigenen Geltungsbereich. Die Nutzerschaft der App braucht außerdem eine eigene Identitätskonfiguration, getrennt von den Konten, die während der Entwicklung im Einsatz sind.
Dass eine Einstellung getrennt gespeichert ist, beweist noch nicht, dass jeder Codepfad richtig damit umgeht. Prüfe die Produktionswerte, die erlaubten Weiterleitungen und die Zugriffsregeln, bevor du deiner Kundschaft einen Link schickst.
Sieh dir die Vorschau genau an, auch die Berechtigungen und die Ansichten ohne Daten. Konfiguriere die Produktionsumgebung, veröffentliche, warte, bis sie bereit ist, und spiele die wichtigen Abläufe in der deployten App durch.
Die aktuelle Anleitung zum Veröffentlichen beschreibt diese Schritte und wie du die Kapazität deines Tarifs prüfst. Betrachte einen erfolgreichen Vorgang in der Oberfläche als einen Schritt des Releases und teste danach den Dienst, der dabei entsteht.
Die Domain
Der Ablauf für eigene Domains verbindet einen Hostnamen der App mit einer Domain, über die du verfügst. Dafür brauchst du die passenden DNS-Einträge und musst die Verbindung verifizieren.
Im ursprünglichen Artikel hieß es verkürzt: CNAME setzen, und alles funktioniert. Das Warten und Prüfen, das eine Domainänderung verlangt, fiel dabei unter den Tisch.
Halte dich an die Werte, die für das Deployment angezeigt werden. Prüfe Hostnamen, Zertifikat und Anwendung, sobald die DNS-Auflösung funktioniert. Teste die Weiterleitungen nach der Anmeldung noch einmal unter der öffentlichen Adresse. Eine funktionierende Vorschau-URL sagt dir über diesen letzten Punkt wenig.
Für die Einrichtung von Domains haben wir implementierte Wege. Einen aktuellen Live-Test von DNS oder TLS dokumentiert diese Neufassung aber nicht.
Die Übergabe an GitHub
Ich möchte, dass ein Projekt auch außerhalb der Sitzung, die es erzeugt hat, sinnvoll weiterlebt. In einem Repository lassen sich Änderungen am Quellcode prüfen und pflegen.
Die GitHub-Integration bietet Wege, ein Konto zu verbinden, den Quellcode zu veröffentlichen und Änderungen mit einem verbundenen Repository auszutauschen. Den Code des Projekts und die zugehörigen Dokumente kannst du dir dann mit vertrauten Werkzeugen ansehen.
Code auf GitHub zu veröffentlichen und eine laufende App zu veröffentlichen, sind zwei getrennte Vorgänge. Ein Repository betreibt keine Datenbank, konfiguriert deine Secrets nicht und reagiert auf keinen Vorfall in der Produktion.
Das Design für den Verlauf sieht einen einzigen Hauptbranch vor, gewöhnliche Pushes und vorwärtsgerichtete Revert-Commits, um Änderungen rückgängig zu machen. Force-Push als normale Aktion der Plattform anzubieten, vermeiden wir.
Damit gibt es weniger Wege, auf denen unser eigener Ablauf den Verlauf umschreibt. Ein Versprechen, dass nie jemand Code verliert, lässt sich damit aber nicht rechtfertigen. Auf Berechtigungen im Repository, Änderungen von außen und Wiederherstellungsverfahren kommt es weiterhin an.
Stand Oktober fehlen für Teile der Verlaufsansicht und des Rollback-Verhaltens noch aktuelle Prüfungen im laufenden Betrieb. Halte deinen eigenen Wiederherstellungsplan bereit. Folgere aus einem Button oder einem implementierten Weg nicht, dass eine Wiederherstellung getestet ist.
Zugangsdaten und Konfiguration
Laut Design speichert die Integration verschlüsselte GitHub-Zugangsdaten pro Projekt, außerhalb des Projektspeichers der App. Damit die Verbindung funktioniert, sollte die App kein persönliches Zugriffstoken in ihrem Quellcode brauchen. Diese Entscheidung zur Speicherung heißt aber nicht, dass das gesamte Deployment ein Sicherheitsaudit bestanden hat.
Willst du ein Projekt woandershin umziehen, reicht es nicht, den Quellcode herunterzuladen. Du musst die Laufzeitkonfiguration, die Datendienste und die Identitätseinstellungen bereitstellen, die sein Code erwartet. Sieh dir diese Abhängigkeiten an, bevor du dich für ein Hosting entscheidest.
Die Dokumentation zu Git und GitHub erklärt den Ablauf für den Quellcode. Warum die Anmeldung nur ein Teil der Zugriffsgrenze einer Anwendung ist, steht im Artikel über Identität.
Die Arbeit am Release
Für die Versprechen zum Betrieb brauche ich weiterhin Belege: einen abgeschlossenen Rollout, eine funktionierende Domain, eine Wiederherstellung, die am echten Dienst geübt wurde. Ein Code-Review kann diese Belege nicht liefern.
Die Arbeit vom Juni hat uns Wege für diese Aufgaben gegeben. Die Prüfungen aufzuschreiben, die noch fehlen, ist weniger befriedigend, als das Problem für gelöst zu erklären. Es ist aber auch nützlicher, bevor das erste Kundenprojekt davon abhängt.
Erstmals veröffentlicht am 16. Juni 2026. Am 15. Oktober 2026 überarbeitet: Die absoluten Aussagen zu Deployment und Wiederherstellung sind korrigiert, und implementierte Wege sind von einer Überprüfung im Live-Betrieb getrennt.