# Deploy zero downtime, push to deploy e rollback
> Come Vimonto Deploy pubblica il tuo sito senza downtime: release, script di deploy e variabili, push to deploy, URL di deploy per la CI e rollback rapidi.
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:
```text
/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](https://ops.vimonto.com/docs/it/sites/site-features) 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](https://ops.vimonto.com/docs/it/sites/environment#vedi-e-ripristina-le-versioni-precedenti) lo conserva come **Costruito su .env.example**. Succede una sola volta. Consulta [ambiente](https://ops.vimonto.com/docs/it/sites/environment).
Ogni recupero del codice legge anche i pacchetti nel tuo `composer.json` e `package.json`, così il menu delle [funzionalità del sito](https://ops.vimonto.com/docs/it/sites/site-features) 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](https://ops.vimonto.com/docs/it/more/notifications). 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](https://ops.vimonto.com/docs/it/sites/site-settings#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](https://ops.vimonto.com/docs/it/connections/source-control) 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:
```bash
$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.
> [!TIP]
> Le credenziali di **Autenticazione Composer** e **Autenticazione npm** (impostate alla creazione del sito) sono disponibili solo durante la build, tramite `COMPOSER_AUTH` e una configurazione npm temporanea. In seguito le gestisci nelle **Impostazioni** del sito, nelle schede **Composer** e **npm**: vedi [credenziali per Composer e npm](https://ops.vimonto.com/docs/it/sites/site-settings#credenziali-per-composer-e-npm).
## 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:
```bash
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](https://ops.vimonto.com/docs/it/more/api) o la [CLI](https://ops.vimonto.com/docs/it/more/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:
1. Trova il deploy nell'elenco **Deploy** e clicca su **Rollback**, oppure aprilo e clicca su **Rollback a questa release**.
2. Conferma. `current` punta 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.
> [!WARNING]
> Le migration del database non vengono annullate. Se una release ha eseguito una migration che il codice più vecchio non sa gestire, annulla prima tu la migration.
## Deploy sul posto senza zero downtime
Quando **Deploy zero-downtime** è disattivato (scelta fatta alla [creazione del sito](https://ops.vimonto.com/docs/it/sites/create-a-site#deploy-zero-downtime) o nelle [impostazioni del sito](https://ops.vimonto.com/docs/it/sites/site-settings)), 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à](https://ops.vimonto.com/docs/it/organization/activity). Ogni deploy e rollback viene anche registrato nel [registro di audit](https://ops.vimonto.com/docs/it/organization/audit-log).
### 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](https://ops.vimonto.com/docs/it/sites/load-balancing).
### 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`.