Versioni e pubblicazione

Costruire e servire sono due cose diverse, e la piattaforma le separa con due pezzi: le versioni (rami dell'app, ciascuno con il suo design e i suoi dati) e la pubblicazione (quale indirizzo serve quale versione).

La regola che riassume tutto: ogni host serve UNA versione di questa app. Pubblicare non è "mettere online" — è scegliere quale versione un indirizzo serve.

#Le versioni di un'app

Una versione è un ramo completo dell'applicazione: le schermate, il modello, le API, gli script, i workflow, i report e i dati. Due versioni non condividono nulla — toccare una non tocca l'altra.

Il menu delle versioni sta nell'intestazione dell'albero dell'app, accanto al pulsante delle impostazioni. Quello che mostra è la tua versione di lavoro:

Elemento	Cosa fa
L'elenco delle versioni	Cliccare su una riga cambia la tua versione di lavoro a quella. Il segno di spunta indica quella attuale.
⟲ (in ogni riga)	Apre la cronologia di quella versione — cosa è cambiato, quando e per mano di chi.
🗑 (in ogni riga)	Elimina la versione.
Nuova versione…	Crea un ramo.
Merge selettivo…	Porta modifiche scelte da una versione a un'altra.

In un'app che non ha mai avuto versioni, il menu dice "Questa app non ha ancora cronologia.".

#Creare una versione

1. Apri il menu delle versioni e clicca su Nuova versione….
2. Compila il Nome (per esempio 1.1) e scegli A partire da — la versione di origine.
3. Clicca su Crea versione.

"Crea un ramo a partire dalla versione di origine, con i dati copiati. La nuova versione non è servita da nessun host finché non le viene associato uno."

Due conseguenze da tenere a mente:

• I dati vengono copiati, non condivisi. La 1.1 nasce con una copia di quello che la main aveva in quell'istante; da lì in poi, seguono vite separate.
• Nessuno la vede, finché non pubblichi un indirizzo che le punti. Puoi lavorare mesi su una versione senza che nessun utente se ne accorga.

Appena la versione è creata, ci stai lavorando ("Versione «1.1» creata — ci stai lavorando.").

#Eliminare una versione

Il 🗑 di una riga elimina "il design, il database e la cronologia di questa versione. Le altre versioni non vengono toccate". Due protezioni:

• la versione main non si elimina;
• nemmeno la versione su cui stai lavorando — "passa a un'altra prima di eliminarla".

#Pubblicare

La pubblicazione vive in Impostazioni dell'app → Generale, nella sezione Pubblicazione.

Ogni riga è un indirizzo pubblicato: l'host, la versione che serve, e la ✕ per Annulla pubblicazione.

Per pubblicare un indirizzo nuovo:

1. Scrivi l'host nel campo (l'esempio dice es: mappe.azienda.com) — solo il nome, senza https:// né percorsi.
2. Scegli la versione che passerà a servire.
3. Clicca su Pubblica.

Confermato, compare "Host pubblicato." e la riga nuova si aggiunge all'elenco.

#Prima che esista un indirizzo

"Nessun host pubblicato — l'app risponde su /app/{slug} con la versione di lavoro." È l'indirizzo interno di sempre, ed è così che si prova un'app prima di darle un nome proprio.

Nota la differenza: su /app/{slug} gira la versione di lavoro di chi sta guardando; su un host pubblicato gira la versione che l'host serve, per tutti. È per questo che, in produzione, si pubblica sempre un host — perché quello che gli utenti vedono non dipenda dal ramo su cui qualcuno sta lavorando.

#Annullare la pubblicazione

La ✕ della riga (Annulla pubblicazione) toglie l'indirizzo. La versione non viene toccata — smette solo di essere servita lì.

Per cambiare versione su un indirizzo già pubblicato, annulla la pubblicazione e pubblica di nuovo con la versione nuova. È l'operazione di "mettere la 1.1 in produzione", e richiede pochi secondi.

#L'app in funzione

Un indirizzo pubblicato serve l'applicazione costruita. Chi ci arriva non vede la piattaforma: vede la schermata di ingresso dell'app, con il suo tema.

Da lì in poi, quello che ciascuno riesce a fare dipende dall'account con cui entra e dai suoi ruoli — materia della pagina Utenti dell'app. Le schermate di ingresso, registrazione e recupero sono disegnabili, e hanno una pagina propria: Schermate pubbliche e registrazione.

#Un flusso di lavoro sano

Un modo comune di organizzare tutto questo in una squadra:

1. main è la versione in produzione. L'host ufficiale (crm.azienda.it) serve la main.
2. Per una modifica grande, si crea una versione (1.1) a partire dalla main e si lavora lì.
3. Per mostrarla a qualcuno prima del tempo, si pubblica un secondo host (crm-test.azienda.it) che serve la 1.1.
4. Quando è pronta, l'host di produzione passa a servire la 1.1 — oppure si porta quello che interessa nella main con il Merge selettivo….

#Cosa non viaggia con l'app

Quando esporti un'app in un pacchetto, l'host resta fuori — è di questa installazione, e lo stesso pacchetto installato altrove avrà i suoi indirizzi. Restano fuori anche la cronologia delle esecuzioni e le chiavi API. Vedi Importare ed esportare app.

#Domande frequenti

Ho cambiato versione e l'app sembra vuota. Ogni versione ha i suoi dati. La 1.1 ha solo quello che esisteva nell'origine nel momento in cui è stata creata, più quello che ci è stato fatto da allora.

Ho pubblicato l'host e il browser non trova niente. Manca il DNS: il nome deve puntare a questa installazione. Finché questo non succede, usa /app/{slug} per provare.

Posso avere due host che servono la stessa versione? Sì. Un host serve una versione, ma niente impedisce che più host puntino alla stessa — per esempio, un indirizzo corto e uno completo.

Ho eliminato una versione per sbaglio. Non si può tornare indietro: elimina il design, i dati e la sua cronologia. È il motivo per cui le versioni in produzione hanno sempre un host associato — una versione servita da un host è una versione che nessuno elimina per distrazione.