In Kinsta, ogni sito può avere 1 Ambiente di Staging Standard e fino a 5 Ambienti di Staging Premium. Gli ambienti di staging consentono di testare plugin, temi o modifiche al codice senza influenzare il sito live.

Kinsta offre la possibilità di portare il vostro ambiente di staging all’ambiente di produzione se le modifiche che avete fatto vi soddisfano e volete che vengano applicate anche al sito live. E grazie alla funzione Selective Push, avete un controllo granulare su cosa state pubblicato.

In passato, portare un sito da staging a produzione era un processo “o tutto o nulla: l’ambiente di staging sovrascriveva completamente il sito live durante il push. Grazie a Selective Push, potete scegliere cosa portare dall’ambiente di staging al sito in produzione. In particolare, ora è possibile fare un push:

  • solo sui vostri file,
  • solo sul vostro database,
  • o entrambi.

Il passaggio da staging a produzione si può fare in pochi clic, ma prima di procedere è necessario leggere le note riportate di seguito. Contengono informazioni essenziali sul processo.

Note importanti

  • Vi consigliamo di usare la funzionalità Push to Live con cautela, di attivarla in momenti di basso traffico e di avere a portata di mano una persona esperta di sviluppo per ogni evenienza. Se avete bisogno di un’assistenza tecnica, ci sono diversi posti dove cercare sviluppatrici e svilulppatori esperti.
  • Creiamo automaticamente un backup in modo che possiate fare il rollback quando necessario. Nota: se il vostro sito live è un ecommerce o un altro sito dinamico che cambia rapidamente, i dati potrebbero perdersi tra il momento del push e il ripristino del backup.
  • Le impostazioni dell’ambiente (reindirizzamenti, geolocalizzazione, configurazione PHP e Nginx, ecc.) sono incluse nel push (anche se è selezionato solo File o Database) e sovrascriveranno completamente le impostazioni dell’ambiente del sito live.
  • Una volta che il push è completo, eliminate qualsiasi cache integrata nel vostro tema o plugin, cancellate la cache del browser e provate il sito per assicurarvi che tutto funzioni come previsto.
  • Quando fate un push del database, se selezionate l’opzione Cerca e sostituisci, il vostro dominio di staging verrà automaticamente sostituito con quello del sito in produzione.
  • Qualsiasi URL hard-coded nel codice del vostro tema o plugin dovrà essere aggiornato all’URL del sito in produzione.
  • Se la protezione della password (.htpasswd) è attiva sul vostro ambiente di staging, questa non verrà trasferita all’ambiente di produzione. Se avete bisogno di questa impostazione sul sito live, dovrete abilitarla direttamente lì.
  • Ricontrollate il sito di staging e risolvete qualsiasi errore prima del push to live.
  • Gli ambienti di staging sono destinati esclusivamente allo sviluppo e ai test. Non sono progettati per essere utilizzati come siti di produzione live e potrebbero esserci cose che non funzionano come previsto. Kinsta non è responsabile se si cerca di usare un ambiente di staging per un sito live.
  • Il push to live non influisce sul ambienti di staging, che rimarrà separato dal sito in produzione. Dopo aver portato il sito live, potetecontinuare a sviluppare e testare le modifiche in staging senza influenzare il sito live fino a quando non porterete le modifiche in produzione.
  • Il push to live non interferirà con Kinsta CDN se è in funzione sul vostro sito in produzione, ma vi consigliamo di cancellare la cache del CDN dopo il push (Siti > nome del sito > Kinsta CDN > Svuota la cache CDN).
  • Fate attenzione se il vostro sito è una rete multisito. Il push del database può funzionare o meno a seconda di come è impostato il multisito. Se usate il push selettivo ed eseguite il push del database o del database e dei file, l’intero contenuto del database verrà portato in produzione e interesserà tutti i siti (il sito principale e i sottositi) della rete multisito.

Come Passare dallo Staging alla Produzione con il Selective Push

Seguite i passaggi qui sotto per passare il vostro ambiente WordPress dallo staging alla produzione. Il flusso di lavoro per il push selettivo vi permette di scegliere quali elementi portare dallo staging al sito in produzione.

Passo 1

Accedete a MyKinsta, fate clic su Siti e poi sul sito che desiderate aggiornare. Usalte il selettore dell’Ambiente accanto al nome del sito per selezionare l’ambiente di staging da cui volete effettuare il push. Se avete aggiunto un ambiente di staging Premium, avrete più di un ambiente di staging tra cui scegliere.

Passate all’ambiente di staging WordPress usando MyKinsta.
Passate all’ambiente di staging WordPress usando MyKinsta.

Passo 2

Una volta che siete nell’ambiente di staging, fate clic sul menu delle Azioni dell’ambiente e selezionate Push to live dal menu a tendina.

Fare il push da Staging a Live in MyKinsta con il Selective Push.
Fare il push da Staging a Live in MyKinsta con il Selective Push.

Passo 3

Nel pop-up/modale Metti in Produzione che appare, scegliete Files, Database, o spuntateli entrambi a seconda di ciò che volete portare in produzione. Digitate il nome del sito per confermare e fate clic sul pulsante Metti in Produzione.

Usate il Selective Push per portare i file dallo staging alla produzione.
Usate il Selective Push per portare i file dallo staging alla produzione.

Un paio di cose da tenere a mente:

  • Il tempo necessario per completare il processo dipende dalle dimensioni del vostro sito web.
  • MyKinsta vi avviserà quando il processo sarà
  • Il vostro sito web sperimenterà un paio di secondi di downtime nelle fasi finali del processo.
  • Le impostazioni dell’ambiente (redirect, geolocalizzazione, configurazione PHP e Nginx, ecc.) sono incluse nel push (anche se è selezionato solo File o Database) e sovrascriveranno completamente le impostazioni dell’ambiente del sito live.

Casi d’Uso ed Esempi di Flussi di Lavoro

Di seguito abbiamo delineato alcuni esempi di quando potreste voler portare in produzione solo i file, solo il database, o entrambi. Tenete a mente quanto segue quando portate l’ambiente di staging su live:

  • Le impostazioni dell’ambiente (redirect, geolocalizzazione, configurazione PHP e Nginx, ecc.) sono incluse nel push (anche se è selezionato solo File o Database) e sovrascriveranno completamente le impostazioni dell’ambiente del sito live.

Portare Solo i File in Produzione

  • Modifiche apportate direttamente ai file del tema (compresi HTML, CSS o PHP) che non salvano alcun dato nel database.
  • Caricare un file che non deve essere incluso nella Media Library di WordPress.
  • Se avete un plugin personalizzato sul vostro sito e fate delle modifiche ai file che non influenzano il database (non salva o altera i dati nel database).

Portare Solo il Database in Produzione

Nota: tutte le modifiche al database del sito dal momento in cui il sito di staging è stato creato saranno perse, come per esempio commenti, nuovi contenuti, acquisti su siti di ecommerce, iscrizioni su siti di appartenenza, post del forum (ma la lista non è esaustiva).

  • Creare o modificare un nuovo articolo o una pagina che non include alcun media caricato (immagini, video o altri file caricati).
  • Modifiche al layout di una pagina o di un articolo fatte attraverso un plugin del costruttore.
  • Cambiare il titolo del sito o lo slogan.

Portare Tutto in Produzione

Nota: tutte le modifiche al database del sito dal momento in cui il sito di staging è stato creato saranno perse, come per esempio commenti, nuovi contenuti, acquisti su siti di ecommerce, iscrizioni su siti di appartenenza, post del forum (ma la lista non è esaustiva).

  • Creazione di nuovi contenuti che includono media caricati (immagini, video o altri file caricati).
  • Modifiche al tema fatte sia nel Personalizza che nei file del tema.
  • Installare e testare un nuovo plugin o una versione aggiornata di un plugin.

Domande Frequenti (FAQ)

D: Se provo un plugin sull’ambiente di staging e porto in produzione solo i file, si creeranno delle tabelle del database corrispondenti al plugin?

Se installate un plugin sul sito di staging che non è mai stato installato sul sito in produzione, portando solo i file da staging a live non si creeranno le tabelle del database per quel plugin.

Questo significa anche che tutte le impostazioni che avete configurato nel plugin non saranno portate in produzione (a meno che le impostazioni siano salvate in un file fuori dal database, come in un file JSON per esempio).

A seconda di come il plugin è codificato, l’abilitazione (e prima la disabilitazione, se necessario) del plugin sul sito in produzione può creare la struttura del database.

D: Se porto in produzione solo i file, significa che il vecchio database (in staging) non sovrascriverà quello live e solo i file saranno sovrascritti?

Sì, quando si portano in produzione solo i file significa che il database sul sito live rimane invariato e solo i file sul sito in produzione saranno sovrascritti.

D: Questo significa che posso lavorare sui cambiamenti di design sul mio sito di staging e portarti il produzione senza perdere nuovi abbonati o clienti sul mio sito live?

Sì, finché le modifiche sono apportate solo ai file (nessuna modifica apportata nella bacheca di WordPress – comprese le impostazioni del plugin, del tema o del Personalizza) potete tranquillamente fare il push di queste modifiche senza fare anche quello del database. Quando portate in produzione le modifiche, selezionate File e assicuratevi che Database non sia selezionato.

D: Posso usare il push selettivo per cambiare la versione PHP del mio sito?

Sì, si può usare lo staging per testare e spingere una nuova versione di PHP nell’ambiente live, ma non è strettamente necessario fare il push da staging a live per aggiornare la versione di PHP. Ecco una breve panoramica di come si può cambiare la versione di PHP senza fare il push da staging a live:

  1. Create un sito di staging.
  2. Andate al sito di staging e cambiate la versione di PHP sul sito di staging.
  3. Se tutto è a posto e funziona come previsto sul sito di staging (testate accuratamente il vostro sito), cambiate la versione di PHP sul sito in produzione.

D: Ho apportato modifiche ai CSS nella bacheca di WordPress e ho fatto il push sui file. Perché non vedo le modifiche, anche dopo aver cancellato tutta la cache?

A seconda del tipo di modifica apportata e del punto in cui sono memorizzate le informazioni, potrebbe essere necessario eseguire il push del database o apportare manualmente le modifiche sul sito live. Per esempio, se avete aggiunto o modificato il CSS in un blocco o un widget nella bacheca di WordPress, questo verrebbe probabilmente salvato nel database.

Se apportate modifiche a elementi nella bacheca di WordPress, con l’eccezione delle modifiche apportate con l’Editor del tema (Aspetto > Editor del tema), queste informazioni vengono solitamente memorizzate nel database.

Nota: Tutte le modifiche al database del sito live da quando il sito di staging è stato creato verranno perse, come commenti, nuovi contenuti, acquisti su siti di ecommerce, iscrizioni su siti di memberhsip e post di forum. In questo caso, raccomandiamo di fare le stesse modifiche manualmente sul sito live piuttosto che fare un push del database.

D: Come funziona il push selettivo con una rete multisito?

Se usate il push selettivo per portare solo i file in produzione, funzionerà bene, indipendentemente dal tipo di rete multisito. Se fate il push solo del database o di database più file, può funzionare o meno a seconda di come è impostato il multisito:

  • Se si tratta di un multisito di sottodirectory (example.com, example.com/subsite1, example.com/subsite2), il push in produzione funzionerà come previsto.
  • Se si tratta di un sottodominio multisito (example.com, subsite1.example.com, subsite2.example.com), funzionerà bene, a condizione che i sottositi non richiedano HTTPS.
  • Se si tratta di un multisito con mappatura del dominio (carica diversi sottositi su domini completamente diversi, per esempio example.com, example1.com, example2.com), non funzionerà senza una significativa configurazione manuale.