Un progetto solo. Quattro modi di consegnarlo.
La stessa interfaccia e gli stessi dati arrivano alle persone come sito sul tuo dominio, come app Android da installare, come programma per Windows e come eseguibile per Linux. Non sono quattro prodotti da tenere allineati: è lo stesso, impacchettato quattro volte.
Scegli dove deve arrivare
Cambia il pacchetto, non il prodotto. Un'app installabile è una FINESTRA sul sito del progetto: apre il suo indirizzo, quindi quello che si vede dentro è quello che si vede nel browser — ed è per questo che una correzione vale in tutte le consegne nello stesso istante.
L'applicazione sul tuo dominio, che si apre da un indirizzo e non si installa.
Le pagine pubbliche di un progetto sono HTML congelato al momento della pubblicazione: arrivano complete al visitatore e ai motori di ricerca, senza aspettare che parta niente.
Un'app Android da installare, con l'icona del progetto e il suo nome.
L'app è una FINESTRA sul sito del progetto: quello che si vede dentro è quello che si vede nel browser, perché è la stessa cosa. Non c'è una seconda versione da tenere allineata — e una correzione vale in tutte le consegne nello stesso istante.
Un programma per Windows: si installa con un doppio click e sta nel menu Start.
Un programma desktop serve alla DISTRIBUZIONE: è la tua applicazione consegnata come software, per chi la deve trovare fra i programmi e non fra i segnalibri.
Un file solo, eseguibile: si scarica, si rende eseguibile e parte.
Nessun pacchetto da preparare per ogni distribuzione, nessuna dipendenza da installare prima: un file, e parte.
Le quattro consegne escono dalla stessa interfaccia e dagli stessi dati: non ci sono quattro prodotti da mantenere allineati.
Non c'è niente da aggiornare
Un'applicazione consegnata come file ha di solito un problema che il web non ha: le copie in giro. Qui non ce l'ha, perché il pacchetto non contiene il prodotto — lo apre.
Una finestra, non una copia
Il pacchetto apre l'indirizzo del progetto. Dentro c'è il sito: stessa sessione, stessi dati, stesso aspetto.
Pubblichi, e basta
La prossima volta che si apre, l'app installata mostra quello che hai pubblicato. Nessuna build da rifare, nessun aggiornamento da mandare in giro.
Senza rete, lo dice
Una schermata che spiega che serve una connessione, e un tasto per riprovare. È l'unica pagina che il pacchetto porta di suo.
Di ogni app escono sei pacchetti: le tre piattaforme in due versioni, una che apre l'ambiente di lavoro e una che apre quello pubblicato. Identici, tranne l'indirizzo.
Tre passi, e il certificato non lo pensi più
Collegare un dominio è la parte che di solito costa una mattinata a qualcuno che sa farlo. Qui sono due record da copiare e un'attesa che si guarda.
- Scrivi il dominioQuello che hai già, oppure un sottodominio: la piattaforma ti dice quale forma stai scegliendo.
- Copia due recordTe li mostra pronti, con il valore da incollare dove tieni il dominio.
- Aspetta il lucchettoLa verifica gira da sé fino al certificato. Non c'è niente da rinnovare, mai.
Il progetto risponde su un indirizzo della piattaforma dal primo minuto: il tuo dominio si collega quando vuoi, non è un requisito per cominciare.
Colleghi un dominio con il jolly e ogni progetto nuovo prende il suo sottodominio da sé. Chi lavora per i clienti collega il dominio del cliente e basta.
Ogni indirizzo ha un pallino di salute che viene da una prova vera — il nome si risolve, la stretta di mano TLS riesce — non da quello che dovrebbe essere.
Per far aprire l'applicazione su un telefono senza dettare un indirizzo. Si scarica come immagine.
Un gesto, e quattro cose che accadono prima
Pubblicare è un tasto. Quello che lo rende un tasto premibile senza paura è cosa la piattaforma fa attorno ad esso.
- Prima ti dico cosa cambia
Il confronto fra l'ambiente di prova e quello pubblico, file per file: cosa è nuovo, cosa è cambiato, cosa non c'è più. Si pubblica sapendo cosa si sta pubblicando.
- Poi copio quello che sto per sovrascrivere
Una copia di sicurezza del pubblicato viene fatta e attesa PRIMA di toccare qualsiasi cosa. Se non riesce, la pubblicazione si ferma e niente viene toccato: pubblicare sopra qualcosa che non si è potuto salvare è esattamente ciò che la copia serve a evitare.
- E poi lo faccio, con la barra che avanza
Copia, costruzione del frontend, allineamento della struttura del database, e una barra per ogni app installabile che viene rigenerata. Chi apre la pagina durante una pubblicazione — anche da un altro computer — vede le stesse barre.
- Una alla volta, per chiunque
Finché una pubblicazione è in corso non ne parte un'altra, nemmeno da un'altra sessione o da un altro utente. Due pubblicazioni sovrapposte scriverebbero l'una sopra l'altra.
La differenza fra provare e rischiare
Un progetto che non si può rimettere com'era è un progetto su cui non si osa. Qui i modi di tornare indietro sono tre, e uno di essi è automatico.
Ogni modifica dell'agente lascia un punto a cui tornare: si torna indietro senza chiedere niente a nessuno.
Un'ora del giorno, e la piattaforma tiene le copie di ogni giorno, di ogni settimana e di ogni mese, quante ne dici tu.
Frontend, backend, agenti, macchine, dati: si scegliono le sezioni da riportare indietro. Se si è rotta una schermata, non si torna indietro anche coi dati.
Il ripristino li tratta a parte, con una spunta che parte spenta: una chiave vecchia rimessa dentro per distrazione è un guasto che si scopre lontano.
Il codice nativo sta su un repository tuo
Una macchina è un processo che gira; un repository è codice che si costruisce. Quando serve del codice nativo — un'app Android scritta a mano, qualcosa che deve essere compilato — la piattaforma collega il GitHub della tua organizzazione, ci mette il progetto e fa partire la build. Quello che ne esce resta lì, accanto al run che l'ha fatto.
- Il repository è tuo
Sta sull'account o sull'organizzazione GitHub che colleghi, con la tua cronologia e i tuoi collaboratori. La piattaforma ci scrive dentro; il proprietario sei tu.
- Lo costruiscono i runner di GitHub
Compilare non è una cosa che si fa su una macchina accesa a pagamento: si fa su un runner, che esiste per il tempo della build.
- E il risultato resta lì
Quello che la build produce resta su GitHub, accanto al run che l'ha fatto: dalla sezione Repository si scarica con un link firmato. Un posto solo dove un risultato può stare.
- È anche la strada per iOS
Un'app per iPhone si può firmare soltanto su un Mac, e i runner di GitHub ne hanno: per quel mondo, il repository non è una comodità — è l'unica strada che esiste.
Due cose da sapere prima, non dopo
Su un account personale la piattaforma non può creare repository da sé: serve la tua autorizzazione, oppure le si affida un repository che esiste già. E i minuti di costruzione sono del tuo account GitHub — su un runner macOS costano dieci volte tanto, e vale sapere quale stai usando.
Costruiscine uno, e mandalo online oggi.
Il primo progetto vive su un indirizzo suo dal primo minuto: il dominio lo colleghi quando è pronto per essere visto.