Strategie di deployment e test delle applicazioni

Last reviewed 2023-07-20 UTC

Questo documento fornisce una panoramica dei pattern di deployment e test delle applicazioni di uso comune. Vedremo come funzionano i pattern, i vantaggi che offrono e gli aspetti da considerare quando li implementi.

Supponiamo che tu voglia eseguire l'upgrade a una nuova versione di un'applicazione in esecuzione. Per garantire un'implementazione senza interruzioni, in genere prendi in considerazione quanto segue:

  • Come ridurre al minimo i tempi di inattività delle applicazioni, se presenti.
  • Come gestire e risolvere gli incidenti con un impatto minimo sugli utenti.
  • Scopri come gestire i deployment non riusciti in modo affidabile ed efficace.
  • Come ridurre al minimo le persone e gli errori dei processi per ottenere deployment prevedibili e ripetibili.

Il modello di deployment scelto dipende in gran parte dai tuoi obiettivi aziendali. Ad esempio, potresti dover implementare le modifiche senza tempi di inattività o apportare modifiche a un ambiente o a un sottoinsieme di utenti prima di rendere una funzionalità disponibile pubblicamente. Ogni metodologia descritta in questo documento tiene conto di obiettivi specifici da raggiungere prima che un deployment venga considerato riuscito.

Questo documento è destinato agli amministratori di sistema e agli ingegneri DevOps che lavorano alla definizione e all'implementazione di strategie di rilascio e deployment per vari sistemi, applicazioni e framework.

Strategie di deployment

Quando deploy di un servizio, non è sempre esposto immediatamente agli utenti. A volte, gli utenti vedono le modifiche nell'applicazione solo dopo il rilascio del servizio. Tuttavia, quando un servizio viene rilasciato in loco, il deployment e il rilascio avvengono contemporaneamente. In questo caso, quando esegui il deployment della nuova versione, quest'ultimo accetta traffico di produzione. In alternativa, sono disponibili strategie di deployment per il provisioning di più versioni di servizio in parallelo. Questi pattern di deployment consentono di controllare e gestire la versione che riceve una richiesta in arrivo. Per saperne di più su deployment, release e concetti correlati, leggi l'articolo relativo a Kubernetes e le sfide della distribuzione continua del software.

I pattern di deployment illustrati in questa sezione offrono flessibilità nell'automazione del rilascio di nuovo software. L'approccio migliore dipende dai tuoi obiettivi.

Ricrea il pattern di deployment

Con un deployment ricreato, fai fare lo scale down completo della versione esistente dell'applicazione prima di fare lo scale up della nuova versione dell'applicazione.

Il seguente diagramma mostra come funziona un deployment di nuova creazione per un'applicazione.

Il flusso di un deployment di nuova creazione.

La versione 1 rappresenta la versione corrente dell'applicazione e la versione 2 rappresenta la nuova versione dell'applicazione. Quando aggiorni la versione corrente dell'applicazione, prima esegui fare lo scale down delle repliche esistenti della versione 1 fino a zero, quindi esegui contemporaneamente il deployment delle repliche con la nuova versione.

Vantaggi principali

Il vantaggio di questo approccio è la sua semplicità. Non è necessario gestire più di una versione dell'applicazione in parallelo e quindi puoi evitare problemi di compatibilità con le versioni precedenti dei tuoi dati e delle tue applicazioni.

Considerazioni

Il metodo di nuova creazione comporta un tempo di inattività durante il processo di aggiornamento. I tempi di inattività non sono un problema per le applicazioni in grado di gestire periodi di manutenzione o interruzioni. Tuttavia, se hai applicazioni mission-critical con accordi sul livello di servizio (SLA) elevati e requisiti di disponibilità, potresti scegliere una strategia di deployment diversa.

Pattern di deployment dell'aggiornamento in sequenza

In un deployment di aggiornamento in sequenza, aggiorni un sottoinsieme di istanze dell'applicazione in esecuzione invece di aggiornare contemporaneamente ogni istanza dell'applicazione, come mostrato nel diagramma seguente.

Il flusso di un deployment di aggiornamento in sequenza.

In questo approccio al deployment, il numero di istanze aggiornate contemporaneamente è chiamato dimensione finestra. Nel diagramma precedente, l'aggiornamento in sequenza ha una dimensione della finestra pari a 1. Viene aggiornata un'istanza dell'applicazione alla volta. Se hai un cluster di grandi dimensioni, potresti aumentare le dimensioni della finestra.

Con gli aggiornamenti in sequenza, puoi aggiornare la tua applicazione in modo flessibile:

  • Puoi fare lo scale up delle istanze dell'applicazione con la nuova versione prima di fare lo scale down della versione precedente (un processo noto come upgrade di picco).
  • Puoi specificare il numero massimo di istanze dell'applicazione che rimangono non disponibili mentre esegui lo scale up di nuove istanze in parallelo.

Vantaggi principali

  • Niente tempi di inattività. In base alle dimensioni della finestra, aggiorni in modo incrementale le destinazioni di deployment, ad esempio uno alla volta o due alla volta. Indirizza il traffico alle destinazioni di deployment aggiornate solo quando la nuova versione dell'applicazione è pronta per accettare il traffico.
  • Rischio di deployment ridotto. Quando implementi un aggiornamento in modo incrementale, qualsiasi instabilità nella nuova versione colpisce solo una parte degli utenti.

Considerazioni

  • Rollback lento. Se la nuova implementazione non è stabile, puoi terminare le nuove repliche ed eseguire nuovamente il deployment della versione precedente. Tuttavia, come nel caso di un'implementazione, il rollback è un processo graduale e incrementale.
  • Compatibilità con le versioni precedenti. Poiché il nuovo codice e il vecchio codice sono affiancati, gli utenti potrebbero essere reindirizzati in modo arbitrario a una delle due versioni. Pertanto, assicurati che il nuovo deployment sia compatibile con le versioni precedenti, ovvero che la nuova versione dell'applicazione possa leggere e gestire i dati archiviati dalla versione precedente. Questi dati possono includere dati archiviati su disco, in un database o come parte della sessione del browser di un utente.
  • Sessioni persistenti. Se l'applicazione richiede la persistenza della sessione, consigliamo che il bilanciatore del carico supporti stickiness e svuotamento della connessione. Inoltre, consigliamo di richiamare la condivisione delle sessioni, quando possibile (tramite la replica delle sessioni o la gestione delle sessioni utilizzando un datastore), in modo che le sessioni possano essere disaccoppiate dalle risorse sottostanti.

Pattern di deployment blu/verde

In un deployment blu/verde (chiamato anche deployment rosso/nero), esegui due deployment identici dell'applicazione, come illustrato nel diagramma seguente.

Il flusso di un deployment blu/verde.

Nel diagramma, il blu rappresenta la versione corrente dell'applicazione e il verde la nuova versione. È disponibile una sola versione alla volta. Il traffico viene instradato al deployment blu, mentre il deployment verde viene creato e testato. Al termine del test, instrada il traffico alla nuova versione.

Una volta completato il deployment, puoi mantenere il deployment blu per un possibile rollback o dismetterlo. In alternativa, puoi eseguire il deployment di una versione più recente dell'applicazione su queste istanze. In questo caso, l'ambiente corrente (blu) fungerà da area temporanea per la prossima uscita.

Vantaggi principali

  • Zero tempi di inattività. Il deployment blu/verde consente di eseguire il cutover senza tempi di inattività.
  • Rollback istantaneo. Puoi eseguire il rollback in qualsiasi momento durante il processo di deployment regolando il bilanciatore del carico in modo da reindirizzare il traffico all'ambiente blu. L'impatto del tempo di inattività è limitato al tempo necessario per trasferire il traffico all'ambiente blu dopo aver rilevato un problema.
  • Separazione dell'ambiente. Il deployment blu/verde assicura che l'avvio di un ambiente verde parallelo non influisca sulle risorse che supportano l'ambiente blu. Questa separazione riduce il rischio del deployment.

Considerazioni

  • Costi e costi operativi generali. L'adozione del modello di deployment blu/verde può aumentare l'overhead e i costi operativi perché devi mantenere ambienti duplicati con un'infrastruttura identica.
  • Compatibilità con le versioni precedenti. I deployment blu e verdi possono condividere punti dati e datastore. Ti consigliamo di verificare che entrambe le versioni dell'applicazione possano utilizzare lo schema del datastore e il formato dei record. Questa compatibilità con le versioni precedenti è necessaria se vuoi passare senza interruzioni tra le due versioni nel caso in cui sia necessario eseguire il rollback.
  • Cutover. Se prevedi di ritirare la versione corrente, ti consigliamo di consentire uno svuotamento appropriato svuotamento della connessione per le transazioni e le sessioni esistenti. Questo passaggio consente di completare o terminare in modo controllato le richieste elaborate dal deployment attuale.

Strategie di test

I pattern di test descritti in questa sezione vengono generalmente utilizzati per convalidare l'affidabilità e la stabilità di un servizio in un periodo ragionevole in un livello realistico di contemporaneità e carico.

Pattern di test canary

Nei test canary, implementi parzialmente una modifica e quindi valuti le sue prestazioni rispetto a un deployment di riferimento, come mostrato nel diagramma seguente.

La configurazione per un test canary.

In questo pattern di test, eseguirai il deployment di una nuova versione dell'applicazione insieme alla versione di produzione. Puoi quindi suddividere e instradare una percentuale del traffico dalla versione di produzione alla versione canary e valutare le prestazioni della versione canary.

Puoi selezionare le metriche chiave per la valutazione quando configuri la versione canary. Ti consigliamo di confrontare la versione canary con una base di riferimento equivalente e non con l'ambiente di produzione live.

Per ridurre i fattori che potrebbero influire sull'analisi, ad esempio memorizzazione nella cache, connessioni di lunga durata e oggetti hash, ti consigliamo di seguire questi passaggi per la versione di riferimento dell'applicazione:

  • Assicurati che le versioni di base e di produzione dell'applicazione siano identiche.
  • Esegui il deployment della versione di base nello stesso momento in cui esegui il deployment della versione canary.
  • Assicurati che il deployment di riferimento (come il numero di istanze dell'applicazione e i criteri di scalabilità automatica) corrisponda al deployment canary.
  • Utilizza la versione di riferimento per gestire lo stesso traffico della versione canary.

Nei test canary, l'implementazione parziale può seguire varie strategie di partizionamento. Ad esempio, se l'applicazione ha utenti distribuiti geograficamente, puoi prima implementare la nuova versione in una regione o in una località specifica. Per maggiori informazioni, consulta Automazione dell'analisi canary su GKE con Spinnaker.

Vantaggi principali

  • Possibilità di testare il traffico di produzione in tempo reale. Anziché testare un'applicazione utilizzando il traffico simulato in un ambiente di gestione temporanea, puoi eseguire test canary sul traffico di produzione in tempo reale. Con le implementazioni canary, devi decidere in quali incrementi rilasciare la nuova applicazione e quando attivare il passaggio successivo in una release. La versione canary ha bisogno di traffico sufficiente per consentire al monitoraggio di rilevare chiaramente i problemi.
  • Rollback veloce. Puoi eseguire rapidamente il rollback reindirizzando il traffico dell'utente alla versione precedente dell'applicazione.
  • Zero tempi di inattività. Le release canary consentono di instradare il traffico di produzione in tempo reale a versioni diverse dell'applicazione senza tempi di inattività.

Considerazioni

  • Implementazione lenta. Ogni release incrementale richiede il monitoraggio per un periodo ragionevole e, di conseguenza, potrebbe ritardare la release complessiva. I test canary possono spesso richiedere diverse ore.
  • Osservabilità. Un prerequisito per l'implementazione dei test canary è la capacità di osservare e monitorare in modo efficace l'infrastruttura e lo stack di applicazioni. L'implementazione di un monitoraggio affidabile può richiedere un impegno considerevole.
  • Compatibilità con le versioni precedenti e sessioni fisse. Come per gli aggiornamenti in sequenza, i test canary possono comportare rischi di incompatibilità con le versioni precedenti e di persistenza delle sessioni, perché più versioni dell'applicazione vengono eseguite nell'ambiente durante il deployment della versione canary.

Pattern del test A/B

Con il test A/B, verifichi un'ipotesi utilizzando le implementazioni delle varianti. Il test A/B viene utilizzato per prendere decisioni aziendali (non solo per fare previsioni) sulla base dei risultati derivati dai dati.

Quando esegui un test A/B, instrada un sottoinsieme di utenti a nuove funzionalità in base alle regole di routing, come illustrato nel seguente diagramma.

La configurazione per un test A/B.

Le regole di routing spesso includono fattori come la versione del browser, lo user agent, la geolocalizzazione e il sistema operativo. Dopo aver misurato e confrontato le versioni, aggiorni l'ambiente di produzione con la versione che ha prodotto risultati migliori.

Vantaggi principali

Il test A/B è consigliato per misurare l'efficacia della funzionalità in un'applicazione. I casi d'uso per i pattern di deployment discussi in precedenza si concentrano sul rilascio sicuro di nuovo software e sul rollback prevedibile. Con i test A/B, puoi controllare il pubblico di destinazione per le nuove funzionalità e monitorare eventuali differenze significative a livello statistico nel comportamento degli utenti.

Considerazioni

  • Configurazione complessa. I test A/B richiedono un campione rappresentativo che possa essere utilizzato per dimostrare che una versione è migliore dell'altra. Devi precalcolare la dimensione del campione (ad esempio, utilizzando un calcolatore delle dimensioni del campione di test A/B) ed eseguire i test per un periodo ragionevole per raggiungere una significatività statistica di almeno il 95%.
  • Validità dei risultati. Diversi fattori possono alterare i risultati del test, tra cui falsi positivi, campionamento distorto o fattori esterni (ad esempio stagionalità o promozioni di marketing).
  • Osservabilità. Quando esegui più test A/B sul traffico che si sovrappone, i processi di monitoraggio e risoluzione dei problemi possono essere difficili. Ad esempio, se testi la pagina del prodotto A rispetto alla pagina del prodotto B o la pagina di pagamento C rispetto alla pagina di pagamento D, il tracciamento distribuito diventa importante per determinare metriche come la suddivisione del traffico tra le versioni.

Pattern di test shadow

Le tecniche basate su esperimenti sequenziali come i test canary potrebbero esporre i clienti a una versione dell'applicazione inferiore durante le prime fasi del test. Puoi gestire questo rischio usando le tecniche offline come la simulazione. Tuttavia, le tecniche offline non convalidano i miglioramenti dell'applicazione perché l'utente non interagisce con le nuove versioni.

Con il test shadow, esegui il deployment di una nuova versione e la esegui insieme a quella attuale, ma in modo che la nuova versione sia nascosta agli utenti, come mostra il diagramma seguente.

La configurazione per un test shadow.

Una richiesta in entrata viene sottoposta a mirroring e riprodotta in un ambiente di test. Questo processo può avvenire in tempo reale o in modo asincrono dopo che una copia del traffico di produzione acquisito in precedenza viene riprodotta sul servizio di cui è stato appena eseguito il deployment.

Devi assicurarti che i test shadow non causino effetti collaterali che possono modificare l'ambiente di produzione esistente o lo stato dell'utente.

Vantaggi principali

  • Zero impatto sulla produzione. Poiché il traffico è duplicato, eventuali bug nei servizi che elaborano i dati shadow non hanno alcun impatto sulla produzione.
  • Test di nuove funzionalità di backend utilizzando il carico di produzione. Se utilizzato con strumenti come Diffy, lo shadowing del traffico consente di misurare il comportamento del servizio rispetto al traffico di produzione in tempo reale. Questa funzionalità consente di testare errori, eccezioni, prestazioni e parità di risultati tra le versioni dell'applicazione.
  • Rischio di deployment ridotto. Lo shadowing del traffico è in genere combinato con altri approcci come i test canary. Dopo aver testato una nuova funzionalità mediante lo shadowing del traffico, puoi testare l'esperienza utente rilasciando gradualmente la funzionalità a un numero crescente di utenti nel tempo. L'implementazione completa non avviene finché l'applicazione non soddisfa i requisiti di stabilità e prestazioni.

Considerazioni

  • Effetti collaterali. Con lo shadowing del traffico, devi essere prudente nel modo in cui gestisci i servizi che cambiano stato o interagiscono con servizi di terze parti. Ad esempio, se vuoi eseguire un test shadow del servizio di pagamento per una piattaforma carrello degli acquisti, i clienti possono pagare due volte l'ordine. Per evitare test shadow che potrebbero causare mutazioni indesiderate o altre interazioni soggette al rischio, ti consigliamo di utilizzare stub o strumenti di virtualizzazione come Hoverfly anziché sistemi o datastore di terze parti.
  • Costi e costi operativi generali. Il test shadow è abbastanza complesso da configurare. Inoltre, come i deployment blu/verde, i deployment shadow hanno implicazioni operative e in termini di costi perché la configurazione richiede l'esecuzione e la gestione di due ambienti in parallelo.

Scelta della strategia giusta

Puoi sottoporre a deployment e rilasciare la tua applicazione in diversi modi. Ogni approccio presenta vantaggi e svantaggi. La scelta migliore dipende dalle esigenze e dai vincoli della tua azienda. Considera quanto segue:

  • Quali sono le tue considerazioni più critiche? Ad esempio, il tempo di inattività è accettabile? I costi sono vincolanti? Il tuo team ha le competenze giuste per eseguire complesse configurazioni di rollout e rollback?
  • Disponi di controlli rigorosi per i test o vuoi testare le nuove release rispetto al traffico di produzione per garantirne la stabilità e limitare eventuali effetti negativi?
  • Vuoi testare le funzionalità in un pool di utenti per verificare incrociate determinate ipotesi aziendali? Puoi controllare se gli utenti target accettano l'aggiornamento? Ad esempio, gli aggiornamenti sui dispositivi mobili richiedono un'azione esplicita dell'utente e potrebbero richiedere autorizzazioni aggiuntive.
  • I microservizi nel tuo ambiente sono completamente autonomi? Oppure disponi di un ibrido di applicazioni in stile microservizi che funzionano insieme ad applicazioni tradizionali difficili da modificare? Per maggiori informazioni, consulta la pagina relativa ai pattern di deployment in ambienti ibridi e multi-cloud.
  • La nuova release comporta modifiche allo schema? Se sì, le modifiche allo schema sono troppo complesse per essere svincolate dalle modifiche al codice?

La seguente tabella riassume le caratteristiche salienti dei pattern di deployment e test discussi in precedenza in questo documento. Quando valuti i vantaggi e gli svantaggi dei vari approcci di deployment e test, tieni conto delle tue esigenze aziendali e risorse tecnologiche, quindi seleziona l'opzione più vantaggiosa.

Pattern di deployment o
di test		 Nessun tempo di inattività Test sul traffico di produzione reale Rilascio agli utenti in base alle condizioni Durata del rollback Impatto sui costi di hardware e cloud
Ricreazione
Viene terminata la versione 1 e implementata la versione 2.		 x x x Veloci ma invasivi a causa del tempo di inattività Non è richiesta alcuna configurazione aggiuntiva
Aggiornamento in sequenza
La versione 2 viene implementata gradualmente per sostituire la versione 1.		 ✓ x x Lento Può richiedere una configurazione aggiuntiva per gli upgrade di sovraccarico
Blu/verde
La versione 2 viene rilasciata insieme alla versione 1; il traffico passa alla versione 2 dopo il test.		 ✓ x x Istantaneo È necessario mantenere contemporaneamente gli ambienti blu e verde
Canary
La versione 2 viene rilasciata a un sottoinsieme di utenti, quindi viene eseguita l'implementazione completa.		 ✓ ✓ x Rapida Non è richiesta alcuna configurazione aggiuntiva
A/B
La versione 2 viene rilasciata, in condizioni specifiche, a un sottoinsieme di utenti.		 ✓ ✓ ✓ Rapido Non è richiesta alcuna configurazione aggiuntiva
Shadow
La versione 2 riceve traffico reale senza influire sulle richieste degli utenti.		 ✓ ✓ x Non applicabile Abbiamo bisogno di mantenere ambienti paralleli per acquisire e riprodurre le richieste degli utenti

best practice

Per ridurre al minimo i rischi per il deployment e i test, i team delle applicazioni possono seguire diverse best practice:

  • Compatibilità con le versioni precedenti. Quando esegui più versioni dell'applicazione contemporaneamente, assicurati che il database sia compatibile con tutte le versioni attive. Ad esempio, una nuova release richiede una modifica allo schema del database (come una nuova colonna). In questo caso, devi modificare lo schema del database in modo che sia compatibile con le versioni precedenti. Dopo aver completato l'implementazione completa, puoi rimuovere il supporto per lo schema precedente, lasciando il supporto solo per la versione più recente. Un modo per ottenere la compatibilità con le versioni precedenti è disaccoppiare le modifiche allo schema dalle modifiche al codice. Per ulteriori informazioni, consulta i pattern di variazione parallela e refactoring del database.
  • Integrazione continua/deployment continuo (CI/CD). La CI garantisce che il codice archiviato nel ramo delle caratteristiche venga unito al ramo principale solo dopo aver superato i controlli delle dipendenze, i test delle unità e di integrazione e il processo di compilazione. Di conseguenza, ogni modifica a un'applicazione viene testata prima di eseguirne il deployment. Con CD, l'artefatto di codice creato da CI viene pacchettizzato e pronto per il deployment in uno o più ambienti. Per saperne di più, consulta la pagina relativa alla creazione di una pipeline CI/CD con Google Cloud.
  • Automazione. Se gli aggiornamenti delle applicazioni vengono distribuiti continuamente agli utenti, ti consigliamo di creare un processo automatizzato che crei, testi ed esegua il deployment del software in modo affidabile. Consigliamo inoltre di far passare automaticamente le modifiche al codice attraverso una pipeline CI/CD che includa creazione degli artefatti, test delle unità, test funzionale e implementazione in produzione. Utilizzando strumenti di automazione come Cloud Build, Cloud Deploy, Spinnaker e Jenkins, puoi automatizzare i processi di deployment per essere più efficienti, affidabili e prevedibili.
  • IaC e GitOps. Se devi gestire strategie di deployment e test complicate, valuta l'utilizzo degli strumenti Infrastructure as Code (IaC) e GitOps. L'utilizzo di IaC con Terraform e Config Connector può aiutarti a utilizzare il linguaggio dichiarativo per definire l'infrastruttura e le strategie. L'utilizzo di GitOps con Config Sync e Argo CD può aiutarti a gestire il tuo codice con Git.
  • Strategia di rollback. A volte può capitare che le cose vadano storte. Ti consigliamo di creare una strategia di rollback da seguire quando si verifica l'evento imprevisto. Avere una strategia di rollback affidabile può aiutare amministratori e DevOps Engineer a gestire i rischi. Puoi creare una strategia di rollback utilizzando una piattaforma che supporta i rollback come funzionalità integrata, ad esempio App Engine e Cloud Run. Per supportare le tue esigenze di rollback, puoi anche utilizzare strumenti di automazione delle release come Cloud Deploy, Spinnaker e Argo RollOuts.
  • Monitoraggio post-deployment. Per monitorare le metriche critiche e avvisare il team responsabile quando un deployment o un test non va a buon fine, crea un sistema di monitoraggio utilizzando l'osservabilità di Google Cloud. Puoi anche abilitare i rollback automatici per i deployment che non superano i controlli di integrità. Utilizzando Error Reporting, Cloud Trace e Cloud Profiler puoi trovare la causa di problemi post-deployment semplici e complessi.

Passaggi successivi