Un deployment mette online una nuova versione del tuo codice sul server. Vimonto Deploy clona il tuo branch in una nuova directory di release, ci esegue il tuo script di deploy e solo allora fa passare il sito alla nuova versione con un unico passaggio atomico. Fino a quel momento i visitatori continuano a ricevere la versione precedente, quindi una build non riuscita non manda mai offline il tuo sito.
Puoi fare il deploy con un pulsante, a ogni push sul tuo branch o dalla CI con un URL di deploy. Le ultime release restano sul server, quindi tornare a una versione precedente richiede pochi secondi.
Come funziona un deployment zero downtime?
Ogni sito è organizzato su disco per i deploy zero-downtime:
/home/{user}/{directory}/
├── releases/
│ ├── 20261007141502/ una directory per ogni deploy
│ └── 20261007153044/
├── shared/
│ ├── .env mantenuto tra le release
│ └── storage/ solo Laravel
└── current -> releases/20261007153044
Nginx serve il sito da current. Un deploy esegue questi passaggi, che puoi seguire in tempo reale:
| Passaggio | Cosa succede |
|---|---|
| Recupera codice | Il branch viene clonato in una nuova release che prende il nome da data e ora (un clone superficiale dell'ultimo commit). Vengono registrati hash, autore e messaggio del commit. |
| Esegui lo script di deploy | Il .env condiviso viene collegato nella release (e per Laravel anche storage/). Poi il tuo script di deploy viene eseguito nella release, con l'utente del sito. |
| Metti live | current viene fatto puntare alla nuova release con un unico rename atomico. PHP-FPM viene ricaricato così OPcache legge i nuovi file. |
| Rimuovi le vecchie release | Le release vecchie vengono rimosse; vengono mantenute le cinque più recenti. |
Dopo il passaggio live, Vimonto Deploy riavvia anche ciò che esegue il tuo codice: i queue worker di Laravel ricevono artisan queue:restart, i processi Node.js vengono riavviati e ogni funzionalità del sito attiva esegue il proprio comando (per esempio horizon:terminate per Horizon).
Al primo deploy di un sito, se il tuo repository ha un .env.example, il .env viene ricostruito su quella base prima che giri lo script di deploy: con le chiavi, l'ordine e i commenti dell'esempio, e con i valori generati da Vimonto Deploy già inseriti. Il log del deploy lo segnala, e la cronologia del .env lo conserva come Costruito su .env.example. Succede una sola volta. Consulta ambiente.
Ogni recupero del codice legge anche i pacchetti nel tuo composer.json e package.json, così il menu delle funzionalità del sito può segnalare gli strumenti usati dalla tua app.
Cosa succede se un deploy fallisce?
Se il recupero del codice o lo script di deploy falliscono, la nuova release viene scartata e current non viene toccato. La pagina del deploy mostra Deploy non riuscito con l'errore e La versione live non è cambiata. Apri Dettagli e log per vedere l'output di ogni passaggio, risolvi il problema e clicca su Rifai il deploy.
Fai il deploy
Clicca su Fai il deploy nell'intestazione del sito, in cima a ogni pagina del sito. Vieni portato alla pagina del deploy, che mostra le fasi, il passaggio in esecuzione e l'avanzamento. Non devi tenere aperta la finestra: il deploy gira sul server, ricevi un messaggio nell'app quando è finito, e un deploy completato o non riuscito invia anche una notifica. Per inviare i risultati dei deploy di un sito anche a un tuo endpoint o ad altri indirizzi email, configura le sue notifiche di deploy.
Per ogni sito gira un solo deploy alla volta. Se ne avvii un altro mentre uno è in corso, vedi C'è già un deploy in corso per seguito dal dominio del sito.
Collega o cambia il repository
Il pannello Repository mostra il repository, il branch e lo stato della Deploy key. Clicca su Collega un repository o Modifica per scegliere un repository da un Git host collegato o per usare un URL Git personalizzato.
- Git host collegato: la deploy key del sito viene registrata sul repository come deploy key di sola lettura, e rimossa dal vecchio repository quando lo cambi. Un repository appena collegato riceve subito Deploy a ogni push attivato.
- URL Git personalizzato: usa un URL SSH (
git@…) per un repository privato e aggiungi la chiave mostrata in Deploy key di questo sito come deploy key presso il tuo Git host. Usa un URL HTTPS per un repository pubblico. Deploy a ogni push è disattivato, perché solo un Git host collegato può ricevere un webhook da Vimonto Deploy.
Modifica lo script di deploy
Il pannello Script di deploy contiene lo script Bash che costruisce una release, in un editor di codice con evidenziazione della sintassi shell. Parte con uno script adatto al tuo framework, che puoi modificare liberamente e salvare con Salva (oppure ⌘ S, Ctrl S). Il deployment successivo lo usa. Predefinito rimette nell'editor lo script generato; viene salvato solo quando clicchi su Salva.
Lo script predefinito di un sito Laravel è questo:
$VIMONTO_COMPOSER install --no-dev --no-interaction --prefer-dist --optimize-autoloader
if [ -f package.json ]; then
if [ -f package-lock.json ]; then npm ci; else npm install; fi
npm run build
fi
$VIMONTO_PHP artisan storage:link --force
$VIMONTO_PHP artisan migrate --force
$VIMONTO_PHP artisan optimize
I siti Symfony svuotano la cache ed eseguono le migration Doctrine quando c'è una cartella migrations. I siti Statamic scaldano anche lo Stache. I siti statici e Node.js installano i pacchetti ed eseguono il comando di build.
Lo script gira con l'utente del sito, nella directory dell'app all'interno della nuova release (la directory root, per un monorepo), con set -e: il primo comando che fallisce interrompe il deploy.
Quali variabili può usare lo script di deploy?
| Variabile | Valore |
|---|---|
$VIMONTO_PHP |
Il binario PHP della versione PHP del sito, come php8.4. |
$VIMONTO_COMPOSER |
Composer, eseguito con la versione PHP del sito. |
$VIMONTO_RELEASE_PATH |
La directory dell'app nella nuova release. |
$VIMONTO_SITE_PATH |
La directory del sito, come /home/vimonto/shop.example.com. |
$VIMONTO_BRANCH |
Il branch di cui fai il deploy. |
$VIMONTO_COMMIT |
L'hash completo del commit di cui fai il deploy. |
Usa $VIMONTO_PHP e $VIMONTO_COMPOSER invece di php e composer, così lo script segue la versione PHP del sito quando la cambi.
Push to deploy
Con un repository di un Git host collegato, il pannello Quick deploy offre Deploy a ogni push. Si attiva da solo quando colleghi il repository, alla creazione o in seguito: Vimonto Deploy aggiunge un webhook al repository su GitHub, GitLab o Bitbucket. Ogni push sul branch del sito avvia allora un deploy; i push su altri branch vengono ignorati. Disattivandolo, il webhook viene rimosso.
Per un repository con un URL Git personalizzato, il pannello ti dice di chiamare invece l'URL di deploy dal tuo Git host o dalla CI.
Deploy dalla CI con l'URL di deploy
Il pannello URL di deploy mostra un URL segreto per il sito a chi può gestire i siti. Una richiesta POST a questo URL fa il deploy del branch del sito:
curl -X POST https://…/deploy/your-secret-token
Usalo come ultimo passaggio di una pipeline GitHub Actions, GitLab CI o di altro tipo, così un deploy parte solo quando i test passano. Le risposte sono semplice JSON:
| Stato | Messaggio | Significato |
|---|---|---|
202 |
Deploy started. |
Il deploy è in coda; la risposta include il suo id. |
409 |
A deploy is already running. |
Riprova quando il deploy in corso è terminato. |
422 |
Il motivo | Il sito non è pronto o non ha un repository. |
404 |
Il token è sbagliato. |
L'URL accetta 60 richieste al minuto. Chiunque abbia l'URL può avviare un deploy, quindi tienilo segreto. Clicca su Rigenera per crearne uno nuovo; il vecchio URL smette subito di funzionare e il webhook presso il tuo Git host viene aggiornato per te.
Segui un deploy e leggi il suo output
L'elenco Deploy mostra tutti i deploy, dal più recente, 15 per pagina: stato, commit, come è stato avviato (Manuale, Push, URL di deploy, Rollback o API, per i deploy avviati tramite la REST API o la CLI), chi l'ha avviato, l'autore del commit, il branch e quanto è durato. La release live ha il badge Live. Anche la panoramica del sito mostra i deploy più recenti.
Clicca su Visualizza per aprire un deploy. La sua pagina mostra le fasi Recupera, Build e Live, l'avanzamento mentre è in corso e, in Dettagli e log, l'output di ogni passaggio. Il pannello Commit riporta messaggio, commit, autore, branch, release e quando è stato avviato. Usa Precedente e Avanti per spostarti tra i deploy.
Rollback a una release precedente
Dato che le cinque release più recenti restano sul server, puoi rimettere live una release precedente senza ricompilare nulla:
- Trova il deploy nell'elenco Deploy e clicca su Rollback, oppure aprilo e clicca su Rollback a questa release.
- Conferma.
currentpunta subito di nuovo a quella release, PHP-FPM viene ricaricato e i worker vengono riavviati.
Un rollback compare nell'elenco come Rollback eseguito a …. I rollback richiedono i deploy zero-downtime e funzionano solo per le release ancora presenti sul server.
Deploy sul posto senza zero downtime
Quando Deploy zero-downtime è disattivato (scelta fatta alla creazione del sito o nelle impostazioni del sito), ogni deploy aggiorna sul posto un'unica release, releases/live. Il codice viene recuperato e riallineato al branch, mentre i file ignorati come vendor/ e node_modules/ restano, quindi le build sono più veloci.
I compromessi:
- I visitatori possono vedere il sito mentre viene compilato.
- Una build non riuscita non viene scartata: il codice live è quello la cui build è fallita.
- Non ci sono release vecchie, quindi niente rollback e niente passaggio di pulizia.
Domande frequenti
Devo tenere aperta la pagina del deploy?
No. I deploy girano sul server come task in background. Puoi chiudere la pagina, e chi ha avviato il deploy riceve una notifica quando finisce. Segui tutti i task nella pagina Attività. Ogni deploy e rollback viene anche registrato nel registro di audit.
Un sito con bilanciamento del carico ha dei deploy?
No. Un sito su un load balancer non ha codice, quindi non ha una pagina Deployment. Fai il deploy del sito su ogni app server dietro il load balancer. Consulta bilanciamento del carico.
Quante release vengono mantenute?
Cinque: le release più recenti, inclusa sempre quella live. Quelle più vecchie vengono rimosse dopo ogni deploy riuscito.
Perché il mio push non ha avviato un deploy?
Verifica che Deploy a ogni push sia attivo e che tu abbia fatto push sul branch del sito. I push su altri branch vengono ignorati. Anche un deploy già in corso rifiuta un secondo deploy.
Posso eseguire le migration solo in alcuni deploy?
Lo script di deploy è semplice Bash, quindi puoi usare delle condizioni. Per esempio, controlla $VIMONTO_BRANCH o un file nella release prima di eseguire $VIMONTO_PHP artisan migrate --force.