Versies en publicatie

Bouwen en serveren zijn twee verschillende dingen, en het platform scheidt ze met twee onderdelen: de versies (vertakkingen van de app, elk met een eigen ontwerp en eigen gegevens) en de publicatie (welk adres welke versie serveert).

De regel die alles samenvat: elke host serveert ÉÉN versie van deze app. Publiceren is niet "online zetten" — het is kiezen welke versie een adres serveert.

#De versies van een app

Een versie is een volledige vertakking van de applicatie: de schermen, het model, de API's, de scripts, de workflows, de rapporten en de gegevens. Twee versies delen niets — in de ene werken raakt de andere niet aan.

Het menu met de versies staat in de kop van de boomstructuur van de app, naast de knop met de instellingen. Wat het toont, is uw werkversie:

Element	Wat dat doet
De lijst met versies	Klikken op een regel schakelt uw werkversie naar die versie. Het vinkje markeert de huidige.
⟲ (op elke regel)	Opent de geschiedenis van die versie — wat er veranderd is, wanneer en door wie.
🗑 (op elke regel)	Verwijdert de versie.
Nieuwe versie…	Maakt een vertakking aan.
Selectieve merge…	Haalt gekozen wijzigingen van de ene versie naar de andere.

In een app die nooit versies heeft gehad, zegt het menu "Deze app heeft nog geen geschiedenis.".

#Een versie aanmaken

1. Open het menu met de versies en klik op Nieuwe versie….
2. Vul de Naam in (bijvoorbeeld 1.1) en kies Vanaf — de bronversie.
3. Klik op Versie aanmaken.

"Maakt een vertakking vanaf de bronversie, met de gegevens gekopieerd. De nieuwe versie wordt door geen enkele host geserveerd totdat zij aan er een gekoppeld wordt."

Twee gevolgen die het waard zijn om te onthouden:

• De gegevens worden gekopieerd, niet gedeeld. De 1.1 wordt geboren met een kopie van wat de main op dat moment had; vanaf dan leiden ze een gescheiden leven.
• Niemand ziet haar, totdat u een adres publiceert dat naar haar wijst. U kunt maandenlang in een versie werken zonder dat een enkele gebruiker het merkt.

Zodra de versie is aangemaakt, werkt u erin ("Versie «1.1» aangemaakt — u werkt er nu in.").

#Een versie verwijderen

De 🗑 van een regel verwijdert "het ontwerp, de database en de geschiedenis van deze versie. De andere versies blijven onaangeroerd". Twee beveiligingen:

• de versie main kan niet worden verwijderd;
• de versie waarin u werkt evenmin — "schakel eerst naar een andere voordat u haar verwijdert".

#Publiceren

De publicatie leeft in Instellingen van de app → Algemeen, in de sectie Publicatie.

Elke regel is een gepubliceerd adres: de host, de versie die hij serveert, en de ✕ om de Publicatie ongedaan te maken.

Een nieuw adres publiceren:

1. Typ de host in het veld (het voorbeeld zegt bijv. kaarten.bedrijf.com) — alleen de naam, zonder https:// en zonder paden.
2. Kies de versie die hij voortaan serveert.
3. Klik op Publiceren.

Na de bevestiging verschijnt "Host gepubliceerd." en voegt de nieuwe regel zich bij de lijst.

#Voordat er ook maar een adres bestaat

"Geen gepubliceerde hosts — de app antwoordt op /app/{slug} met de werkversie." Dat is het vertrouwde interne adres, en zo probeert u een app uit voordat u haar een eigen naam geeft.

Let op het verschil: op /app/{slug} draait de werkversie van wie kijkt; op een gepubliceerde host draait de versie die de host serveert, voor iedereen. Daarom publiceert u in productie altijd een host — zodat wat de gebruikers zien niet afhangt van de vertakking waarin iemand toevallig aan het werk is.

#Publicatie ongedaan maken

De ✕ van de regel (Publicatie ongedaan maken) haalt het adres weg. De versie blijft onaangeroerd — zij wordt alleen niet meer daar geserveerd.

Om op een al gepubliceerd adres van versie te wisselen maakt u de publicatie ongedaan en publiceert u opnieuw met de nieuwe versie. Dat is de handeling "de 1.1 in productie zetten", en zij duurt seconden.

#De draaiende app

Een gepubliceerd adres serveert de gebouwde applicatie. Wie daar aankomt, ziet het platform niet: hij ziet het aanmeldscherm van de app, met haar thema.

Vanaf dat punt hangt wat elke persoon kan doen af van het account waarmee zij binnenkomt en van haar rollen — stof voor de pagina Gebruikers van de app. De schermen voor aanmelden, registreren en herstellen zijn ontwerpbaar, en ze hebben een eigen pagina: Publieke schermen en registratie.

#Een gezonde manier van werken

Een gebruikelijke manier om dit in een team te organiseren:

1. main is de versie in productie. De officiële host (crm.empresa.pt) serveert de main.
2. Voor een grote wijziging maakt u vanaf de main een versie (1.1) aan en werkt u daarin.
3. Om haar voortijdig aan iemand te tonen, publiceert u een tweede host (crm-teste.empresa.pt) die de 1.1 serveert.
4. Zodra zij klaar is, serveert de productiehost voortaan de 1.1 — of u haalt wat ertoe doet naar de main met de Selectieve merge….

#Wat niet met de app meereist

Wanneer u een app als pakket exporteert, blijft de host buiten — die is van deze installatie, en hetzelfde pakket dat ergens anders wordt geïnstalleerd, krijgt eigen adressen. Ook de geschiedenis van de uitvoeringen en de API-sleutels blijven buiten. Zie Apps importeren en exporteren.

#Veelgestelde vragen

Ik ben van versie gewisseld en de app lijkt leeg. Elke versie heeft eigen gegevens. De 1.1 heeft alleen wat er in de bron bestond op het moment dat zij werd aangemaakt, plus wat er sindsdien in is gedaan.

Ik heb de host gepubliceerd en de browser vindt niets. De DNS ontbreekt: de naam moet naar deze installatie wijzen. Zolang dat niet gebeurd is, gebruikt u /app/{slug} om uit te proberen.

Kan ik twee hosts hebben die dezelfde versie serveren? Ja. Eén host serveert één versie, maar niets belet dat er meerdere naar dezelfde wijzen — bijvoorbeeld een kort adres en een volledig adres.

Ik heb per ongeluk een versie verwijderd. Er is geen weg terug: het verwijdert haar ontwerp, haar gegevens en haar geschiedenis. Dat is de reden waarom versies in productie altijd een host gekoppeld horen te hebben — een versie die door een host wordt geserveerd, is een versie die niemand uit verstrooidheid verwijdert.