Versionen und Veröffentlichung

Bauen und Ausliefern sind zwei verschiedene Dinge, und die Plattform trennt sie mit zwei Bauteilen: den Versionen (Zweige der App, jeder mit eigenem Entwurf und eigenen Daten) und der Veröffentlichung (welche Adresse welche Version ausliefert).

Die Regel, die alles zusammenfasst: Jeder Host liefert EINE Version dieser App aus. Veröffentlichen heißt nicht „online stellen“ — es heißt wählen, welche Version eine Adresse ausliefert.

#Die Versionen einer App

Eine Version ist ein vollständiger Zweig der Anwendung: die Bildschirme, das Modell, die APIs, die Skripte, die Workflows, die Berichte und die Daten. Zwei Versionen teilen sich nichts — in einer etwas anzufassen berührt die andere nicht.

Das Versionsmenü liegt in der Kopfzeile des App-Baums, neben der Schaltfläche für die Einstellungen. Was es zeigt, ist Ihre Arbeitsversion:

Element	Was es tut
Die Liste der Versionen	Ein Klick auf eine Zeile wechselt Ihre Arbeitsversion dorthin. Der Haken markiert die aktuelle.
⟲ (in jeder Zeile)	Öffnet die Historie dieser Version — was sich geändert hat, wann und durch wen.
🗑 (in jeder Zeile)	Löscht die Version.
Neue Version…	Erstellt einen Zweig.
Selektiver Merge…	Bringt ausgewählte Änderungen von einer Version in eine andere.

In einer App, die nie Versionen hatte, sagt das Menü „Diese App hat noch keine Historie.“.

#Eine Version erstellen

1. Öffnen Sie das Versionsmenü und klicken Sie auf Neue Version….
2. Füllen Sie den Namen aus (zum Beispiel 1.1) und wählen Sie Ausgehend von — die Ursprungsversion.
3. Klicken Sie auf Version erstellen.

„Erstellt einen Zweig ausgehend von der Ursprungsversion, mit kopierten Daten. Die neue Version wird von keinem Host ausgeliefert, bis ihr einer zugewiesen wird.“

Zwei Konsequenzen, die man sich merken sollte:

• Die Daten werden kopiert, nicht geteilt. Die 1.1 entsteht mit einer Kopie dessen, was die main in jenem Augenblick hatte; ab da führen sie getrennte Leben.
• Niemand sieht sie, bis Sie eine Adresse veröffentlichen, die auf sie zeigt. Sie können Monate in einer Version arbeiten, ohne dass ein Benutzer davon merkt.

Sobald die Version erstellt ist, arbeiten Sie in ihr („Version «1.1» erstellt — Sie arbeiten jetzt darin.“).

#Eine Version löschen

Das 🗑 einer Zeile löscht „Design, Datenbank und Historie dieser Version. Die anderen Versionen bleiben unangetastet“. Zwei Schutzmaßnahmen:

• die Version main lässt sich nicht löschen;
• die Version, in der Sie gerade arbeiten, auch nicht — „wechseln Sie zu einer anderen, bevor Sie sie löschen“.

#Veröffentlichen

Die Veröffentlichung wohnt in Einstellungen der App → Allgemein, im Abschnitt Veröffentlichung.

Jede Zeile ist eine veröffentlichte Adresse: der Host, die Version, die er liefert, und das ✕ für Veröffentlichung aufheben.

Um eine neue Adresse zu veröffentlichen:

1. Schreiben Sie den Host in das Feld (das Beispiel sagt z. B. karten.firma.de) — nur der Name, ohne https:// und ohne Pfade.
2. Wählen Sie die Version, die er fortan ausliefert.
3. Klicken Sie auf Veröffentlichen.

Nach der Bestätigung erscheint „Host veröffentlicht.“ und die neue Zeile gesellt sich zur Liste.

#Bevor es überhaupt eine Adresse gibt

„Keine veröffentlichten Hosts — die App antwortet unter /app/{slug} mit der Arbeitsversion.“ Das ist die immer gleiche interne Adresse, und so probiert man eine App aus, bevor man ihr einen eigenen Namen gibt.

Beachten Sie den Unterschied: Unter /app/{slug} läuft die Arbeitsversion dessen, der gerade hinsieht; auf einem veröffentlichten Host läuft die Version, die der Host ausliefert, für alle. Deshalb veröffentlicht man in der Produktion immer einen Host — damit das, was die Benutzer sehen, nicht davon abhängt, in welchem Zweig gerade jemand arbeitet.

#Veröffentlichung aufheben

Das ✕ der Zeile (Veröffentlichung aufheben) nimmt die Adresse weg. Die Version bleibt unangetastet — sie wird dort nur nicht mehr ausgeliefert.

Um bei einer bereits veröffentlichten Adresse die Version zu wechseln, heben Sie die Veröffentlichung auf und veröffentlichen erneut mit der neuen Version. Das ist der Vorgang „die 1.1 in Produktion bringen“, und er dauert Sekunden.

#Die laufende App

Eine veröffentlichte Adresse liefert die gebaute Anwendung aus. Wer dort ankommt, sieht nicht die Plattform: Er sieht den Einstiegsbildschirm der App, mit deren Design.

Was jede Person von da an tun kann, hängt vom Konto ab, mit dem sie sich anmeldet, und von ihren Rollen — Stoff der Seite Benutzer der App. Die Bildschirme für Anmeldung, Registrierung und Wiederherstellung sind entwerfbar und haben eine eigene Seite: Öffentliche Bildschirme und Registrierung.

#Ein gesunder Arbeitsablauf

Eine verbreitete Art, das im Team zu organisieren:

1. main ist die Version in Produktion. Der offizielle Host (crm.empresa.pt) liefert die main aus.
2. Für eine größere Änderung erstellt man eine Version (1.1) ausgehend von der main und arbeitet dort.
3. Um sie jemandem vorab zu zeigen, veröffentlicht man einen zweiten Host (crm-teste.empresa.pt), der die 1.1 ausliefert.
4. Ist sie fertig, liefert der Produktions-Host fortan die 1.1 aus — oder man holt sich das Interessante mit dem Selektiven Merge… in die main.

#Was nicht mit der App reist

Wenn Sie eine App als Paket exportieren, bleibt der Host außen vor — er gehört zu dieser Installation, und dasselbe Paket, anderswo installiert, wird seine eigenen Adressen haben. Außen vor bleiben auch die Ausführungshistorie und die API-Schlüssel. Siehe Apps importieren und exportieren.

#Häufige Fragen

Ich habe die Version gewechselt und die App wirkt leer. Jede Version hat ihre eigenen Daten. Die 1.1 hat nur das, was im Ursprung im Moment ihrer Erstellung vorhanden war, plus das, was seitdem dort getan wurde.

Ich habe den Host veröffentlicht und der Browser findet nichts. Es fehlt das DNS: Der Name muss auf diese Installation zeigen. Bis das geschieht, verwenden Sie /app/{slug} zum Ausprobieren.

Kann ich zwei Hosts haben, die dieselbe Version ausliefern? Ja. Ein Host liefert eine Version aus, aber nichts hindert mehrere daran, auf dieselbe zu zeigen — zum Beispiel eine kurze und eine vollständige Adresse.

Ich habe versehentlich eine Version gelöscht. Es gibt kein Zurück: Es löscht deren Entwurf, deren Daten und deren Historie. Das ist der Grund, warum Versionen in Produktion immer einen zugewiesenen Host haben sollten — eine Version, die von einem Host ausgeliefert wird, ist eine Version, die niemand aus Unachtsamkeit löscht.