Se immaginiamo un diagramma di Venn, gli ambienti di staging di Kinsta convergono sia con lo sviluppo per WordPress che con il ciclo di vita DevOps scelto. Possono far parte di un flusso di lavoro a partire dalla pianificazione iniziale fino alla fase operativa. Questo include il lavoro in locale con WordPress, l’utilizzo del controllo di versione e quasi tutte le altre attività che si svolgono durante un ciclo.
In questo articolo, ci occuperemo dello sviluppo di siti in combinazione con gli ambienti di staging di Kinsta. Nel corso di tutto l’articolo, lo collegheremo a un tipico ciclo di vita DevOps. C’è molto da affrontare, quindi iniziamo con i motivi per usare gli ambienti di staging offerti da Kinsta.
I vantaggi dell’utilizzo degli ambienti di staging di Kinsta
Gli ambienti di staging di Kinsta offrono versatilità e flessibilità quando si tratta di sviluppare siti web e testarli. Questi ambienti permettono di costruire in un ambiente che rispecchia il proprio ambiente live. Dato che anche il server live sarà su Kinsta, si tratta di un terreno di prova affidabile e preciso da cui lavorare.
Naturalmente, gli ambienti di staging si possono creare, gestire, clonare ed eliminare attraverso la dashboard di MyKinsta:
Per chi ha bisogno di maggiore flessibilità, l’add-on per gli ambienti di staging Premium offre cinque ambienti in più. Inoltre, sarà possibile beneficiare della nostra solida infrastruttura, che include il network di livello Premium di Google e l’integrazione con Cloudflare.
Come ci si può aspettare, tutto questo si traduce anche in una maggiore potenza sotto il cofano. A seconda del piano, i clienti Kinsta hanno a disposizione fino a 12 CPU e 8 GB di memoria, un numero di worker PHP corrispondente al sito live e la possibilità di attivare il CDN Kinsta per migliorare le prestazioni. Si tratta di una configurazione adatta a una serie di attività, come i test A/B, i controlli di compatibilità dei plugin, i test ad alta intensità di risorse e molto altro ancora.
Per lo sviluppo locale, DevKinsta completa l’intera esperienza. Una volta superate le fasi iniziali, si può inviare il sito direttamente agli ambienti di staging di Kinsta.
Nel complesso, è possibile creare, costruire, progettare, testare e fare il debug all’interno dell’ecosistema di Kinsta. Inoltre, è adatto anche al proprio ciclo di vita DevOps. Ne parleremo presto in modo più dettagliato. Prima però, ecco qualche informazione in più sugli ambienti di staging di Kinsta.
Alcune informazioni sullo staging di Kinsta
Gli ambienti di staging di Kinsta sono eccellenti quando si tratta di testare un sito su un server live, anche se non di produzione. Tuttavia, ci sono alcune differenze tra l’ambiente di staging e quello live su Kinsta di cui essere consapevoli:
- Innanzitutto, per impostazione predefinita, disabilitiamo sia il caching della pagina intera che OPcache. Potete attivarla se lo desiderate, ma senza di essa è probabile che i tempi di caricamento delle pagine più elevati.
- Allo stesso modo, anche l’indicizzazione del sito è disabilitata all’interno di WordPress. Sebbene possiate riattivarla se necessario, un aspetto che non potete disattivare è l’indicizzazione temporanea degli URL con intestazioni restrittive.
- I Cron Job non verranno eseguiti durante la fase di staging, anche se rimarranno “attivi”. Ciò significa che potete apportare delle modifiche che sostituiranno i cron job sul vostro sito live una volta che lo avrete reso operativo. Tuttavia, mentre sono in fase di staging, non verranno eseguiti.
- Inoltre, tenete presente che le vostre credenziali di accesso a WordPress saranno le stesse sia per il sito di staging che per quello live.
C’è un altro aspetto su cui vogliamo soffermarci rapidamente prima di passare al workflow: il modo in cui i plugin interagiscono con lo staging.
Utilizzo dei plugin negli ambienti di staging di Kinsta
Kinsta vieta già l’installazione di alcuni plugin su WordPress per motivi di sicurezza e di prestazioni. Tuttavia, quando si tratta di staging, dovrete anche disabilitare alcuni dei plugin del vostro sito.
Ci sono tre situazioni in cui dovrete prendere in considerazione questa possibilità:
- Se la licenza del plugin è legata al vostro nome di dominio, potrebbe non funzionare nell’ambiente di staging.
- I plugin come Jetpack passano automaticamente alla modalità di staging. Potreste non notare alcuna differenza, anche se nessuno dei dati che elaborate andrà su WordPress.com. Inoltre, non potrete disabilitare Jetpack in modalità staging.
- Alcuni plugin si collegano e pubblicano sui social media, come CoSchedule. In questi casi, vi consigliamo di disattivarli fino al “go live”. Questo perché possono programmare e pubblicare URL dall’ambiente di staging.
Per ulteriori informazioni su questo argomento (e molto altro), vi invitiamo a consultare la nostra documentazione. È una lettura essenziale se volete utilizzare gli ambienti di staging di Kinsta riducendo al minimo gli effetti sui vostri plugin e temi.
Un tipico flusso di lavoro di sviluppo con gli ambienti di staging di Kinsta
Probabilmente avete già un flusso di lavoro tipico per lo sviluppo. Utilizzando gli ambienti di staging di Kinsta, potete integrare il vostro ciclo di vita DevOps per la Continuous Integration/Continuous Deployment (CI/CD) in modo fluido.
Infatti, il processo inizia con un ambiente locale di sviluppo. Il processo di configurazione richiede pochissimo tempo e gestisce anche la creazione di un database MariaDB.
DevKinsta è ideale anche per i progetti WordPress headless. Anche se in questo caso WordPress si comporta come un’API (Application Programming Interface) di contenuti, potete comunque costruire il front-end utilizzando un framework JavaScript come React o Vue.js.
Quando sarà il momento di passare allo staging, DevKinsta gestirà il back-end nel suo modo tipico. Per quanto riguarda il front-end, potrete distribuire il vostro sito sull’Hosting di Siti Statici di Kinsta o sul nostro Hosting di Applicazioni.
Ecco come si presenta il resto di un tipico workflow:
- Invio all’ambiente di staging. Una volta completato lo sviluppo locale e i test preliminari, dovrete eseguire il push all’ambiente di staging. Questa replica di produzione assicura che i vostri test producano risultati simili a quelli del vostro sito live. Si tratta di una fase cruciale della pipeline CI/CD, in quanto potete implementare test automatizzati e controlli di qualità prima della distribuzione.
- Test e debug. Vorrete effettuare altri test all’interno dello staging, come ad esempio i test di performance, la scansione della sicurezza e i test di accettazione utente (UAT). Poiché Kinsta isola gli ambienti di staging e live, questi test non avranno alcun impatto sul sito live. Grazie ai log e allo strumento Application Performance Monitoring (APM) di Kinsta, potete anche eseguire il debug di eventuali problemi.
- Integrazione e distribuzione continua. Dopo la fase di test e le approvazioni finali, dovrete integrare le modifiche di staging nell’ambiente live. Potete automatizzare alcuni aspetti di questo processo in base al vostro flusso di lavoro CD/CI. In questo modo, il controllo di versione centrale può rimanere aggiornato e potete distribuire il codice in produzione con un minimo di input.
- Monitoraggio e feedback. Dopo la distribuzione, è fondamentale identificare e correggere qualsiasi problema utilizzando un ciclo continuo di feedback e monitoraggio. L’APM di Kinsta può aiutarvi a risolvere qualsiasi problema successivo alla distribuzione. Da qui, potete continuare ad apportare miglioramenti grazie alle analisi e ai dati raccolti.
Nel complesso, gli ambienti di staging di Kinsta (e DevKinsta) forniscono un’infrastruttura solida per aiutarvi a semplificare il vostro flusso di lavoro di sviluppo. Supporta anche le applicazioni WordPress headless. Nella prossima sezione vedremo come potete utilizzare le vostre competenze DevOps esistenti insieme al nostro staging.
Applicare le tecniche DevOps quando si utilizzano gli ambienti di staging di Kinsta
L’applicazione delle tecniche DevOps negli ambienti di staging di Kinsta può migliorare notevolmente la collaborazione e snellire il ciclo di vita dello sviluppo. Questo è particolarmente vero per i team interfunzionali, poiché lo staging replica il più possibile la produzione.
In questo modo gli sviluppatori, i team di Quality Assurance (QA) e altri lavorano insieme in sincronia durante le fasi di creazione, test e distribuzione. Poiché questo avviene in un ambiente controllato e isolato, aiuta a ridurre al minimo i conflitti. Inoltre, permette di identificare e risolvere eventuali problemi nelle prime fasi del processo di sviluppo.
In sostanza, DevOps cerca di rimuovere le barriere tra i team, lo sviluppo e le operazioni, tipici e tradizionali. Le pratiche implementate incoraggiano una cultura collaborativa, automatizzata e integrativa.
Inoltre, le giuste pratiche DevOps mirano a migliorare la velocità, l’efficienza e la sicurezza dello sviluppo e della distribuzione.
Potete vedere questo aspetto in azione nelle varie fasi del ciclo di vita DevOps. Ce ne sono circa cinque o sette, a seconda del progetto e del team:
- Sviluppo. Questa fase comprende la pianificazione e la codifica, oltre alla scelta dell’ambiente di staging. Qui scriverete il codice, lo testerete e ne controllerete la versione (probabilmente usando Git) prima di passare alla fase successiva.
- Integrazione. In questa fase dovrete unire le modifiche al codice in un repository centrale e assicurarvi che le nuove aggiunte non danneggino il vostro sito.
- Test. Successivamente automatizzerete i test da eseguire nell’ambiente di staging. In questo modo avrete un secondo livello per garantire un codice di qualità e privo di bug.
- Distribuzione. Dopo aver convalidato il codice di staging, potete automatizzare la distribuzione in produzione. In questo modo il vostro sito sarà sempre aggiornato alla versione più recente.
- Monitoraggio. Dopo la distribuzione, dovrete monitorare le prestazioni del sito. È qui che un robusto sistema di avvisi e un processo di monitoraggio vi offriranno un valore aggiunto. I dati raccolti in questa fase vi aiuteranno anche in futuro.
- Feedback. Questa è una fase successiva all’implementazione in cui raccoglierete informazioni e dati dagli utenti, in questo caso i visitatori del sito. Utilizzerete il feedback di questa fase per identificare le aree di miglioramento nel prossimo ciclo di sviluppo.
- Operazioni. In questa fase è probabile che si verifichi un incrocio con un nuovo ciclo. È qui che si riducono al minimo le interruzioni, si lavora per migliorare i tempi di attività e si ottimizzano le configurazioni dei server.
A seconda del numero di fasi del vostro ciclo di vita, alcune di queste saranno in un ordine diverso. Ad esempio, la fase di integrazione potrebbe far parte delle fasi di sviluppo o di test. Inoltre, potreste non avere alcune di queste fasi, come ad esempio una fase dedicata al feedback o alle operazioni.
Gli ambienti di staging di Kinsta sono parte integrante della fase di sviluppo, in quanto forniscono un’area sicura e isolata per la codifica, il test e il QA prima della distribuzione. L’integrazione di questi ambienti nel ciclo di vita DevOps può aiutare la collaborazione, aumentare i tempi di consegna e migliorare la qualità dei risultati.
Di seguito vi mostreremo come crearli attraverso la dashboard di MyKinsta.
Come impostare un ambiente di staging su Kinsta
Non tutti gli hosting offrono questa funzionalità, ma gli ambienti di staging di Kinsta sono presenti in tutti i piani che offriamo. L’intero processo richiede un paio di minuti e pochi clic.
Inoltre, non è il caso di descrivere tutti i passaggi in questa sede, perché potete trovarli nella nostra knowledge base. Tuttavia, in breve, potete iniziare la configurazione attraverso la vostra dashboard MyKinsta:
La prima decisione da prendere sarà quella di scegliere un ambiente di staging standard o premium. Il nostro consiglio è quello di capire quanto lo staging sarà fondamentale per il vostro sito live. Ad esempio, un ambiente standard fa per voi se avete bisogno di testare solo elementi lontani dalla produzione.
Al contrario, un ambiente premium sarà necessario se avete bisogno dello stesso livello e della stessa portata di risorse del vostro sito live. Ci sono anche altri vantaggi, come la possibilità di creare più ambienti di staging. Tuttavia, per i siti ad alta intensità di risorse (come i negozi di e-commerce), è necessario che le risorse del vostro sito live siano all’altezza.
Nella maggior parte dei casi, probabilmente vorrete clonare il vostro sito esistente: questa è una delle opzioni che avete a disposizione dopo aver scelto il tipo di ambiente di staging.
Provenendo da DevKinsta, potete creare un ambiente vuoto qui. C’è un pulsante nelle impostazioni del vostro sito in DevKinsta per passare allo staging. In ogni caso, dovrete attendere qualche minuto affinché l’ambiente completi la sua configurazione. Da quel momento potrete iniziare a utilizzare gli ambienti di staging di Kinsta per creare e testare il vostro sito.
Dare al vostro ambiente di staging Kinsta un indirizzo di sottodominio corretto
In circostanze normali, il vostro ambiente di staging Kinsta si trova in una sottocartella del vostro server. Avrà un URL che è un sottodominio di kinsta.cloud, ma questo può causare un paio di problemi:
- Alcuni plugin non funzioneranno, ad esempio quelli che richiedono la verifica di una licenza attraverso un nome di dominio specifico.
- Alcune configurazioni di WordPress Multisite hanno problemi con le sottodirectory su Kinsta o richiedono un sottodominio personalizzato per funzionare in modo ottimale.
Per questo motivo, è bene impostare un indirizzo di sottodominio adeguato per i vostri ambienti di staging su Kinsta. Per gli utenti premium, Kinsta fornisce indirizzi di sottodominio dedicati, ma anche questo potrebbe non risolvere i vostri problemi.
La soluzione è quella di creare un dominio personalizzato per il vostro sito, quindi eseguire lo staging da un sottodominio utilizzando il Domain Name System (DNS). Un URL di staging personalizzato che utilizza un dominio e un sottodominio appropriati offre due vantaggi: innanzitutto, potete attenuare i problemi di cui abbiamo parlato. In secondo luogo, avete un sottodominio “più elegante” da condividere con i collaboratori o i clienti.
Passare un sito live allo staging
Un aspetto dell’ambiente di staging che potrebbe non essere chiaro all’inizio è il modo in cui inviarvi il sito live dopo la configurazione. Una volta compreso che un ambiente di staging è semplicemente una copia del vostro sito live, è più facile da visualizzare.
Tuttavia, ecco una rapida panoramica del flusso di lavoro per fugare ogni dubbio:
- Quando create un ambiente di staging, in pratica copiate il vostro sito live in un sottodominio. Questo include tutti i database e i file. Si tratta di una replica completa uno-a-uno del vostro sito live.
- Apportate le modifiche all’ambiente di staging secondo il vostro ciclo di vita DevOps. Questo sarà soggettivo e legato al vostro progetto, al vostro flusso di lavoro e ai vostri obiettivi.
- Quando si tratta di rendere effettive le modifiche, avete alcune opzioni. Potete utilizzare la funzionalità Invia a Live integrata in Kinsta o apportare modifiche manuali. Di questo aspetto parleremo in modo più approfondito più avanti.
- Da questo punto in poi, avrete una replica uno a uno del vostro sito sia per gli ambienti di staging che per quelli live.
Di conseguenza, non c’è modo di aggiornare l’ambiente di staging in base allo stato del sito live. Vi consigliamo di cancellare l’ambiente di staging e di ricostruirlo quando ne avrete bisogno, in modo da copiare il vostro sito attuale. Questo è un altro buon motivo per utilizzare un sottodominio personalizzato per i vostri ambienti di staging Kinsta.
Kinsta effettua backup sia per il sito live che per l’ambiente di staging. Questo significa che potete anche ripristinare il backup di un sito live direttamente nell’ambiente di staging. In questo modo potrete passare da una fase all’altra del vostro ciclo di vita con maggiore facilità e potrete utilizzare le precedenti permutazioni del vostro sito durante lo sviluppo.
È necessario impostare prima l’ambiente di staging, ma potete ripristinare sia l’ambiente standard che quello premium. In ogni caso, potete farlo attraverso la dashboard di MyKinsta:
Questa operazione richiede un paio di clic e manterrà i backup esistenti per i vostri siti live e di staging, oltre a tutti i domini personalizzati che avete impostato.
Incorporare il controllo di versione nella configurazione di staging
Molti sviluppatori utilizzano il controllo di versione, come Git, cosa che consigliamo anche noi. Sia gli ambienti live che quelli di staging su Kinsta offrono l’integrazione con Git, il che significa che potete controllare la versione del vostro sito di staging per tenere sotto controllo il vostro programma di sviluppo.
Estrarre e clonare un repo sul server di Kinsta è un gioco da ragazzi. Il processo prevede alcuni passaggi fondamentali:
- Collegatevi al vostro sito utilizzando Secure Shell (SSH).
- Prelevate il vostro repo attuale da GitHub, GitLab o un altro servizio simile.
- In alternativa, clonate il vostro repo dalla vostra postazione remota.
Il modo in cui prelevate il vostro repo remoto sarà diverso a seconda che sia pubblico, privato o dotato di autenticazione a due fattori (2FA). Per quanto riguarda l’invio del codice al repo remoto, invece, dovrete trovare un flusso di lavoro adeguato.
Questo perché gli ambienti di staging di Kinsta e l’integrazione con Git non supportano ancora un comando come git push kinsta mysite. Tuttavia, esistono delle soluzioni. Ad esempio, potete utilizzare uno strumento come WP Pusher:
Gli sviluppatori più all’avanguardia stanno trovando modi unici per inviare il codice a GitHub da Kinsta, anche se si tratta di eseguire un semplice comando da un client Git o di automatizzare il processo con degli script. Più avanti parleremo del concetto generale di push del codice sul sito live.
Eseguire test sulle prestazioni negli ambienti di staging di Kinsta
Una parte delle fasi del ciclo di vita del test e del monitoraggio comprende l’analisi (e il confronto) delle prestazioni del vostro sito di staging con i benchmark. La buona notizia è che avete accesso a tutti gli strumenti di Kinsta per il vostro sito di staging, oltre che per quello live.
In breve, prenderete i benchmark per il vostro sito live, creerete gli obiettivi che vorreste raggiungere e ottimizzerete il vostro codice all’interno dello staging. Da lì, valuterete se le modifiche apportate fanno la differenza. In caso affermativo, potrete procedere. In caso contrario, si ripetono le fasi di codifica e di test.
Per gli ambienti di staging di Kinsta, lo strumento Kinsta APM sarà probabilmente un riferimento centrale:
Si tratta di uno strumento personalizzato che si concentra sui problemi di WordPress e che registra con un timestamp tutte le attività raccolte. Potete monitorare i processi PHP, le chiamate HTTP, le query di database e molto altro ancora. Ad esempio, abbiamo scoperto che la maggior parte dei problemi di degrado delle prestazioni sono riconducibili a un plugin o a un tema non ottimale. Kinsta APM può mostrarvi questo aspetto in modo esplicito nella scheda WordPress.
Vedrete che è possibile esaminare in profondità le singole transazioni, il che significa che potete vedere con precisione dove sono i vostri colli di bottiglia. Per i siti di staging, non monitorerete spesso il tempo di transazione di Redis. Invece, i tempi di PHP e MySQL saranno di maggiore interesse.
L’utilizzo di un intervallo di tempo assoluto per la risoluzione dei problemi aiuta a individuare le aree problematiche. La documentazione di Kinsta vi illustra il flusso di lavoro generale, ma in poche parole le pagine lente dovrebbero essere la vostra prima preoccupazione.
Da lì, potete analizzare i processi che compongono le transazioni e individuare il codice non ottimale o gli strumenti di terze parti più scadenti. Probabilmente utilizzerete un mix di strumenti per cercare e combattere il codice problematico. Per lo sviluppo di WordPress, WP_DEBUG e Query Monitor sono quelli più usati.
Distribuzione continua: sincronizzare le modifiche tra staging e produzione
La fase di distribuzione del vostro ciclo di vita porta a dover prendere una decisione: quale codice inviare. Il vostro primo pensiero potrebbe essere quello di fare tutto in una volta, ma non sempre è l’idea migliore.
Infatti, a prescindere dalla somiglianza tra gli ambienti di staging e quelli live, questi ultimi presenteranno comunque delle differenze. Un approccio misurato può essere più sensato, in quanto potete eseguire il push di una suite di codice per un miglioramento specifico, monitorare i cambiamenti e quindi programmare il push successivo.
Questo concetto è fondamentale per il deployment continuo, in quanto la sicurezza del deployment dovrebbe essere una preoccupazione fondamentale. In passato, la funzionalità push-to-live di Kinsta con un solo clic inviava l’intero sito al server live, indipendentemente dalle modifiche apportate. Tuttavia, ora avete anche la possibilità di effettuare un push selettivo: potete inviare i file, il database o entrambi al server live:
Tuttavia, questo include anche le impostazioni dell’ambiente, come le configurazioni di Nginx, PHP e il reindirizzamento. Questo potrebbe comunque essere eccessivo, soprattutto quando si apportano solo piccole o minime modifiche a una parte specifica del sito.
Naturalmente, avete anche la possibilità di rinunciare alle opzioni push-to-live di Kinsta e di svolgere il lavoro da soli. L’approccio più sicuro è quello di replicare le modifiche sul sito live piuttosto che automatizzarle. Certo, l’implementazione richiederà più tempo, ma avrete la possibilità di monitorare ogni modifica man mano che viene resa operativa.
Tuttavia, indipendentemente dal vostro approccio alla distribuzione continua, i vostri backup saranno un componente fondamentale. Kinsta effettua backup giornalieri per ogni sito del vostro account. Questo include i backup generati dal sistema e anche i backup manuali.
Inoltre, ogni backup è un’istantanea completa di un ambiente specifico. Ciò significa che potete tornare a una configurazione nota e funzionante in pochi minuti per riparare un sito non funzionante.
Riepilogo
Gli ambienti di staging di Kinsta possono aiutarvi a creare, testare e distribuire il vostro sito in produzione, indipendentemente dal numero di fasi che eseguite o dalla natura di ciascuna fase del vostro flusso di lavoro. Sono flessibili, perché potete usare l’ambiente di staging standard gratuito per ogni sito che gestite con Kinsta.
Tuttavia, con un ambiente di staging premium, potete impostare più istanze, eseguire risorse che corrispondono al vostro sito live e molto altro ancora. Gli ambienti di staging di Kinsta sono straordinari anche se utilizzati insieme al nostro Hosting di Applicazioni. In ogni caso, potete portare il vostro sito da locale a live e accedere a tutti gli strumenti tipici di Kinsta direttamente dalla dashboard di MyKinsta.
Avete qualche domanda sull’utilizzo degli ambienti di staging di Kinsta insieme alle vostre normali tecniche DevOps? Fateci sapere cosa ne pensate nella sezione commenti qui sotto!
Lascia un commento