Deployment
Deploy che non mandano mai offline il tuo sito
Ogni deploy crea una release nuova accanto a quella attiva e passa alla nuova versione solo quando ogni passaggio è riuscito. Fai push sul tuo branch, chiama un URL di deploy dalla CI o clicca Fai il deploy.
Come funziona
Quattro passaggi, e solo l'ultimo tocca il sito online
- 1
Recupera il codice
Il tuo branch viene clonato in una nuova directory di release che porta data e ora. Vengono registrati il commit, l'autore e il messaggio.
- 2
Crea la release
Il
.envcondiviso (e per Laravel anchestorage/) viene collegato, poi il tuo script di deploy gira dentro la nuova release come utente del sito. - 3
Online in modo atomico
currentviene puntato sulla nuova release con un solo rename. PHP-FPM si ricarica così OPcache vede i nuovi file, e i queue worker si riavviano. - 4
Cinque release conservate
Le release più vecchie vengono eliminate; le cinque più recenti restano sul server, così un rollback è istantaneo e non richiede alcuna build.
Script di deploy
Uno script di deploy che puoi leggere e modificare
Ogni sito parte con uno script di deploy adatto al suo framework. È semplice Bash, gira con set -e nella nuova release e lo modifichi nel browser.
Usa $VIMONTO_PHP e $VIMONTO_COMPOSER al posto di php e composer, così lo script segue la versione PHP del sito quando la cambi. Hai a disposizione anche il branch e il commit in fase di deploy.
$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 optimizeAvvia un deploy nel modo che preferisci
Push to deploy
Collega un repository da GitHub, GitLab (anche self-hosted) o Bitbucket e il webhook viene aggiunto per te. I push sul branch del sito avviano il deploy; gli altri branch vengono ignorati.
Un URL di deploy per la CI
Chiama un URL segreto con
POSTcome ultimo step della tua pipeline, così un deploy parte solo quando i test passano. Le risposte sono semplice JSON.Fai il deploy
Un pulsante nell'intestazione del sito. Segui le fasi in tempo reale, oppure chiudi la pagina: il deploy gira sul server e ricevi un messaggio quando finisce.
API e CLI
Avvia i deploy dai tuoi script con l'API REST, oppure dalla CI con la CLI di deploy e
Automazione--watch, così un deploy fallito fa diventare rossa la pipeline.
Segui ogni deploy mentre avviene
La pagina di un deploy mostra le fasi Recupera, Build e Live, lo step in corso e l'output di ogni step. Un deploy concluso o fallito invia una notifica, nell'app, via email o al tuo endpoint.
Se un deploy fallisce, non cambia nulla
Se il recupero del codice o lo script di deploy falliscono, la nuova release viene scartata e current non viene toccato. I visitatori continuano a vedere la versione online, e la pagina del deploy mostra l'errore con il log completo.
Tornare indietro è altrettanto rapido: scegli Rollback su un deploy precedente e quella release torna online, senza ricostruire nulla. Le migration del database non vengono annullate, quindi gestiscile tu quando una release lo richiede.
- Un solo deploy alla volta per sito
- Il primo deploy crea il
.enva partire dal tuo.env.example - Ogni modifica al
.envviene conservata: ripristina una delle ultime 50 - Preferisci build più veloci? Passa un sito ai deploy sul posto
Rilasci più sicuri
Siti di staging
Una copia di un sito per un altro branch, come develop, su un proprio indirizzo e con un proprio database. Ogni push su quel branch lo distribuisce.
Controlli di sicurezza
Ogni deploy controlla le dipendenze Composer e npm della nuova release prima che vada online. Scegli per sito se una vulnerabilità nota dà un avviso o ferma il deploy.
Cosa è andato storto
Un deploy fallito viene spiegato in parole semplici a partire dal suo log, con correzioni suggerite, la più probabile per prima.
Domande sui deploy
Devo tenere aperta la pagina del deploy?
No. I deploy girano sul server come attività in background. Chiudi pure la pagina; chi ha avviato il deploy riceve un messaggio quando finisce, e ogni deploy compare nella pagina Attività e nel registro di audit.
Quante release vengono conservate?
Cinque: le release più recenti, sempre inclusa quella online. Le più vecchie vengono rimosse dopo ogni deploy riuscito.
Da quali host Git posso fare il deploy?
GitHub, GitLab (anche GitLab self-hosted) e Bitbucket, con push to deploy. Qualsiasi altro server Git funziona tramite un URL Git personalizzato con la deploy key del sito; avvia quei deploy con l'URL di deploy.
Posso fare il deploy senza zero downtime?
Sì. Con i deploy zero-downtime disattivati, ogni deploy aggiorna una sola release sul posto, che mantiene vendor/ e node_modules/ e fa build più veloci. Rinunci ai rollback, e i visitatori potrebbero vedere il sito durante la build.
Pagine correlate
- Siti e dominiSiti da preset per framework, DNS automatico, SSL gratuito, funzioni del sito e Nginx modificabile.
- AutomazioneUn'API REST, una CLI per la CI, URL di deploy, ricette per gli script ricorrenti e hook di deploy.
- LaravelDeploy Laravel senza downtime, con Horizon, Reverb, Pulse, code e scheduler a portata di interruttore.
Il tuo prossimo deploy potrebbe essere online prima che finisca il caffè.
Crea un’organizzazione, collega un server e fai push. Tutto qui.