# OPS 6. In che modo mitighi i rischi della distribuzione?
Adotta prassi per fornire un feedback rapido sulla qualità e che permettano un ripristino veloce dalle modifiche che non hanno i risultati previsti. L'uso di queste prassi consente di mitigare l'impatto dei problemi introdotti attraverso la distribuzione delle modifiche.
**Topics**
+ [OPS06-BP01 Preparazione di un piano in caso di esito negativo delle modifiche](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 Implementazioni dei test](ops_mit_deploy_risks_test_val_chg.md)
+ [OPS06-BP03 Utilizza strategie di deployment sicure](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [OPS06-BP04 Automazione dei test e del rollback](ops_mit_deploy_risks_auto_testing_and_rollback.md)
# OPS06-BP01 Preparazione di un piano in caso di esito negativo delle modifiche
Pianifica il ripristino di uno stato corretto noto o la correzione nell'ambiente di produzione nel caso in cui l'implementazione generi un risultato indesiderato. Disporre di una politica per stabilire un piano di questo tipo aiuta tutti i team a sviluppare strategie di ripristino dalle modifiche con esito negativo. Alcune strategie di esempio sono le fasi di deployment e rollback, le politiche di modifica, i flag di funzionalità, l'isolamento del traffico e lo spostamento del traffico. Una singola release può includere più modifiche ai componenti correlati. La strategia dovrebbe fornire la capacità di resistere o ripristinare in caso di guasto generato da qualsiasi modifica dei componenti.
**Risultato desiderato:** hai preparato un piano di ripristino dettagliato per la modifica in caso di fallimento. Inoltre, hai ridotto le dimensioni della release per ridurre al minimo il potenziale impatto su altri componenti del carico di lavoro. Di conseguenza, hai ridotto l'impatto aziendale abbreviando i potenziali tempi di inattività causati da una modifica non riuscita e aumentando la flessibilità e l'efficienza dei tempi di ripristino.
**Anti-pattern comuni:**
+ Hai eseguito un deployment e l'applicazione è diventata instabile, ma sembra che ci siano utenti attivi sul sistema. Devi decidere se eseguire il rollback della modifica e influire sugli utenti attivi o aspettare di eseguire il rollback della modifica, sapendo che gli utenti potranno essere comunque influenzati.
+ Dopo aver apportato una modifica di routine, i nuovi ambienti sono accessibili, ma una delle sottoreti è diventata irraggiungibile. Devi decidere se eseguire il rollback di tutto o provare a correggere il problema della sottorete inaccessibile. Mentre prendi tale decisione, la sottorete rimane irraggiungibile.
+ I tuoi sistemi non sono progettati in modo da consentire loro di essere aggiornati con release più piccole. Di conseguenza, è difficile annullare tali modifiche di massa (bulk changes) durante un deployment conclusosi con esito negativo.
+ Non utilizzi l'Infrastruttura come codice (IaC) e hai apportato aggiornamenti manuali all'infrastruttura che hanno portato a configurazioni indesiderate. Non è possibile tracciare e ripristinare in modo efficace le modifiche manuali.
+ Poiché non hai misurato l'aumento della frequenza dei deployment, il tuo team non è incentivato a ridurre le dimensioni delle modifiche e a migliorare i piani di rollback per ogni modifica, con conseguente aumento dei rischi e dei tassi di fallimento.
+ Non misura la durata totale di un'interruzione causata da modifiche con esito negativo. Il tuo team non è in grado di stabilire le priorità e migliorare il processo di deployment e l'efficacia del piano di ripristino.
**Vantaggi dell'adozione di questa best practice:** Avere un piano per il ripristino dopo le modifiche non riuscite riduce al minimo il tempo medio di ripristino (MTTR) e riduce l'impatto sull'azienda.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
Una politica e una pratica coerenti e documentate adottate dai team di rilascio consentono a un'organizzazione di pianificare cosa dovrebbe succedere in caso di modifiche con esito negativo. In circostanze specifiche la politica dovrebbe consentire la possibilità di apportare correzioni per garantire la prosecuzione del processo. In entrambe le situazioni, un piano di correzione (fix forward) o ripristino (rollback) deve essere ben documentato e testato prima dell'implementazione nei sistemi di produzione live, in modo da ridurre al minimo il tempo necessario per ripristinare una modifica.
### Passaggi dell'implementazione
1. Documenta le politiche che richiedono ai team di disporre di piani efficaci per invertire le modifiche entro un periodo di tempo specificato.
1. Le politiche devono specificare quando è consentita una situazione di applicazione di correzioni per garantire la prosecuzione del processo.
1. Richiedi un piano di rollback documentato che sia accessibile a tutti i soggetti coinvolti.
1. Specifica i requisiti per il rollback (ad esempio, quando si rileva che sono state implementate modifiche non autorizzate).
1. Analizza il livello di impatto di tutte le modifiche relative a ciascun componente di un carico di lavoro.
1. Consenti che le modifiche ripetibili siano standardizzate, basate su modelli e preautorizzate se seguono un flusso di lavoro coerente che applica le politiche di modifica.
1. Riduci il potenziale impatto di qualsiasi modifica riducendone le dimensioni, in modo che il ripristino richieda meno tempo e abbia un impatto minore sulle attività aziendali.
1. Assicurati che le procedure di rollback riportino il codice allo stato corretto noto per evitare incidenti, ove possibile.
1. Integra strumenti e flussi di lavoro per applicare le tue politiche in modo programmatico.
1. Rendi visibili i dati sulle modifiche agli altri responsabili di carichi di lavoro per migliorare la velocità di diagnosi di eventuali modifiche con esito negativo che non possono essere ripristinate.
1. Misura il successo di questa pratica utilizzando dati di modifica visibili e identifica miglioramenti iterativi.
1. Utilizza gli strumenti di monitoraggio per verificare il successo o il fallimento di un deployment per accelerare il processo decisionale sul rollback.
1. Misura la durata dell'interruzione durante una modifica con esito negativo per migliorare continuamente i tuoi piani di ripristino.
**Livello di impegno per il piano di implementazione:** Medio
## Risorse
**Best practice correlate:**
+ [OPS06-BP04 Automazione dei test e del rollback](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**Documenti correlati:**
+ [AWS Builders Library \$1 Ensuring Rollback Safety During Deployments ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [AWS Whitepaper \$1 Change Management in the Cloud ](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**Video correlati:**
+ [ re:Invent 2019 \$1 Amazon’s approach to high-availability deployment ](https://aws.amazon.com/builders-library/amazon-approach-to-high-availability-deployment/)
# OPS06-BP02 Implementazioni dei test
Testa le procedure di rilascio in pre-produzione utilizzando la stessa configurazione di deployment, i controlli di sicurezza, i passaggi e le procedure utilizzati nell'ambiente di produzione. Verifica che tutte le fasi implementate siano state completate come previsto, ad esempio l'ispezione di file, configurazioni e servizi. Verifica ulteriormente tutte le modifiche con test funzionali, di integrazione e di carico, oltre ad attivare tutte le attività di monitoraggio come i controlli dell'integrità. Eseguendo questi test, è possibile identificare tempestivamente i problemi di deployment con l'opportunità di pianificarli e mitigarli prima del passaggio nell'ambiente di produzione.
Puoi creare ambienti paralleli temporanei per testare ogni modifica. Automatizza il deployment degli ambienti di test utilizzando l'Infrastruttura come codice (IaC) per ridurre la quantità di lavoro necessaria e garantire stabilità, coerenza e una distribuzione più rapida delle funzionalità.
**Risultato desiderato:** La tua organizzazione adotta una cultura di sviluppo che include il test delle implementazioni. Ciò garantisce che i team siano concentrati sulla realizzazione di valore aziendale anziché sulla gestione delle release. I team vengono coinvolti fin dall'identificazione dei rischi di deployment per determinare il percorso di mitigazione appropriato.
**Anti-pattern comuni:**
+ Durante le release di produzione, le implementazioni non testate causano problemi frequenti che richiedono una risoluzione mirata e l'escalation.
+ La tua release contiene porzioni di Infrastruttura come codice (IaC) che aggiornano le risorse esistenti. Non sei sicuro che l'IaC funzionerà correttamente e non avrà un impatto sulle risorse.
+ Viene implementata una nuova funzionalità interessante nella tua applicazione. Non funziona come previsto e non c'è visibilità finché non viene segnalata dagli utenti interessati.
+ I certificati vengono aggiornati. Si installano accidentalmente i certificati sui componenti sbagliati, il che non viene rilevato e influisce sui visitatori poiché non è possibile stabilire una connessione sicura al sito web.
**Vantaggi dell'adozione di questa best practice:** Test approfonditi in fase di pre-produzione delle procedure di implementazione e delle modifiche da queste introdotte riducono al minimo il potenziale impatto sulla produzione causato dalle fasi di implementazione. Ciò aumenta la fiducia durante il rilascio in produzione e riduce al minimo la necessità di supporto operativo senza rallentare la velocità di distribuzione delle modifiche apportate.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
Testare il processo di deployment è importante quanto testare le modifiche derivanti dal deployment. Ciò può essere ottenuto testando le fasi di deployment in un ambiente di pre-produzione che rispecchi il più fedelmente possibile quello di produzione. I problemi più comuni, come fasi di deployment incomplete o contenenti errori o configurazioni errate, possono essere individuati di conseguenza prima di passare all'ambiente di produzione. Inoltre, è possibile testare le fasi di ripristino.
**Esempio del cliente**
Nell'ambito della sua pipeline di integrazione continua e distribuzione continua (CI/CD), AnyCompany Retail esegue i passaggi definiti necessari per rilasciare aggiornamenti dell'infrastruttura e del software per i propri clienti in un ambiente simile a quello di produzione. La pipeline comprende controlli preliminari per rilevare il “drift” (il rilevamento delle modifiche alle risorse eseguite al di fuori dell'IaC) nelle risorse prima del deployment, nonché per convalidare le azioni che l'IaC intraprende al suo avvio. Convalida le fasi di deployment, ad esempio la verifica che determinati file e configurazioni siano presenti e che i servizi siano in esecuzione e rispondano correttamente ai controlli di integrità sull'host locale, prima di effettuare nuovamente la registrazione sul sistema di bilanciamento del carico. Inoltre, tutte le modifiche attivano una serie di test automatici, come test funzionali, di sicurezza, di regressione, di integrazione e di carico.
### Passaggi dell'implementazione
1. Esegui controlli di pre-installazione per rispecchiare l'ambiente di pre-produzione in produzione.
1. utilizza [il rilevamento della deviazione](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html) per rilevare quando le risorse sono state modificate all'esterno di CloudFormation.
1. utilizza [i set di modifiche](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html) per verificare che l'intento dell'aggiornamento dello stack corrisponda alle azioni intraprese da CloudFormation quando viene avviato il set di modifiche.
1. Ciò attiva una fase di approvazione manuale in [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html) per autorizzare l'implementazione nell'ambiente di preproduzione.
1. Utilizza configurazioni di implementazione come [file AWS CodeDeploy AppSpec](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html) per definire le fasi di implementazione e convalida.
1. Ove applicabile, [integra AWS CodeDeploy con altri servizi AWS](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html) o [integra AWS CodeDeploy con prodotti e servizi dei partner](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html).
1. [Monitora le implementazioni](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html) usando le notifiche di eventi Amazon CloudWatch, AWS CloudTrail e Amazon SNS.
1. Esegui test automatici post-deployment, inclusi test funzionali, di sicurezza, di regressione, di integrazione e di carico.
1. [Risoluzione dei problemi](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html) di implementazione.
1. La corretta convalida dei passaggi precedenti dovrebbe attivare un flusso di lavoro di approvazione manuale per autorizzare l'implementazione nell'ambiente di produzione.
**Livello di impegno per il piano di implementazione:** alto
## Risorse
**Best practice correlate:**
+ [OPS05-BP02 Test e convalida delle modifiche](ops_dev_integ_test_val_chg.md)
**Documenti correlati:**
+ [AWS Builders' Library \$1 Automating safe, hands-off deployments \$1 Test Deployments ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/#Test_deployments_in_pre-production_environments)
+ [AWS Whitepaper \$1 Practicing Continuous Integration and Continuous Delivery on AWS](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/testing-stages-in-continuous-integration-and-continuous-delivery.html)
+ [ The Story of Apollo - Amazon's Deployment Engine ](https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html)
+ [Come eseguire test e debug con AWS CodeDeploy in locale prima di distribuire il codice](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/)
+ [ Integrating Network Connectivity Testing with Infrastructure Deployment ](https://aws.amazon.com/blogs/networking-and-content-delivery/integrating-network-connectivity-testing-with-infrastructure-deployment/)
**Video correlati:**
+ [ re:Invent 2020 \$1 Testing software and systems at Amazon ](https://www.youtube.com/watch?v=o1sc3cK9bMU)
**Esempi correlati:**
+ [ Tutorial \$1 Deploy and Amazon ECS service with a validation test ](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorial-ecs-deployment-with-hooks.html)
# OPS06-BP03 Utilizza strategie di deployment sicure
I roll-out sicuri della produzione controllano il flusso di modifiche vantaggiose con l'obiettivo di ridurre al minimo l'impatto percepito di tali modifiche sui clienti. I controlli di sicurezza forniscono meccanismi di ispezione per convalidare i risultati desiderati e limitare l'ambito di impatto derivante da eventuali difetti introdotti dalle modifiche o da errori di deployment. I roll-out sicuri possono includere strategie come feature-flags, one-box, roll-out (release canary), immutabili, suddivisioni del traffico e deployment blu/verdi.
**Risultato desiderato:** l'organizzazione utilizza un sistema di distribuzione e integrazione continua (CI/CD) che fornisce funzionalità per automatizzare roll-out sicuri. I team sono tenuti a utilizzare strategie di roll-out sicure appropriate.
**Anti-pattern comuni:**
+ Distribuisci una modifica non riuscita a tutta la produzione contemporaneamente. Di conseguenza, tutti i clienti vengono colpiti contemporaneamente.
+ Un difetto introdotto in un deployment simultaneo su tutti i sistemi richiede una release di emergenza. La correzione per tutti i clienti richiede diversi giorni.
+ La gestione della release di produzione richiede la pianificazione e la partecipazione di diversi team. Ciò limita la tua capacità di aggiornare frequentemente le funzionalità per i tuoi clienti.
+ Esegui un deployment variabile modificando i sistemi esistenti. Dopo aver scoperto che la modifica non è andata a buon fine, devi modificare nuovamente i sistemi per ripristinare la versione precedente estendendo il tempo di ripristino.
**Vantaggi dell'adozione di questa best practice:** Le implementazioni automatizzate bilanciano la velocità dei roll-out con la fornitura costante di modifiche vantaggiose per i clienti. La limitazione dell'impatto previene costosi errori di deployment e massimizza la capacità dei team di rispondere in modo efficiente ai guasti.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Gli errori della distribuzione continua possono portare a una ridotta disponibilità del servizio e a esperienze dei clienti negative. Per massimizzare il tasso di deployment di successo, implementa i controlli di sicurezza nel processo di rilascio end-to-end per ridurre al minimo gli errori di deployment, con l'obiettivo di raggiungere il traguardo di zero errori.
**Esempio del cliente**
La missione di AnyCompany Retail è raggiungere deployment con tempi di inattività minimi o pari a zero, il che significa che non vi deve essere alcun impatto percepibile dagli utenti durante i deployment. A tal fine, l'azienda ha stabilito modelli di deployment (vedere il seguente diagramma del flusso di lavoro) come roll-out e deployment blu/verdi. Tutti i team adottano uno o più di questi modelli nella loro pipeline CI/CD.
| flusso di lavoro CodeDeploy per Amazon EC2 | flusso di lavoro CodeDeploy per Amazon ECS | flusso di lavoro CodeDeploy per Lambda |
| --- | --- | --- |
| ![\[Flusso del processo di implementazione per Amazon EC2\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/deployment-process-ec2.png) | ![\[Flusso del processo di implementazione per Amazon ECS\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/deployment-process-ecs.png) | ![\[Flusso del processo di implementazione per Lambda\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/deployment-process-lambda.png) |
### Passaggi dell'implementazione
1. Utilizza un flusso di lavoro di approvazione per avviare la sequenza delle fasi di roll-out della produzione al momento della promozione alla produzione.
1. Utilizza un sistema di implementazione automatizzato come [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html). AWS CodeDeploy [opzioni di implementazione](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps.html) include le implementazioni locali (in-place) per EC2/on-premise e le implementazioni blu/verdi per EC2/on-premise AWS Lambda e Amazon ECS (vedi il diagramma del flusso di lavoro precedente).
1. Ove applicabile, [integra AWS CodeDeploy con altri servizi AWS](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html) o [integra AWS CodeDeploy con prodotti e servizi dei partner](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html).
1. Utilizza implementazioni blu/verdi per database come [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html) e [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html).
1. [Monitora le implementazioni](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html) usando le notifiche di eventi Amazon CloudWatch, AWS CloudTrail e Amazon SNS.
1. Esegui test automatici post-implementazione, inclusi test funzionali, di sicurezza, di regressione, di integrazione e di carico.
1. [Risoluzione dei problemi](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html) di implementazione.
**Livello di impegno per il piano di implementazione:** Medio
## Risorse
**Best practice correlate:**
+ [OPS05-BP02 Test e convalida delle modifiche](ops_dev_integ_test_val_chg.md)
+ [OPS05-BP09 Applicazione di modifiche frequenti, minime e reversibili](ops_dev_integ_freq_sm_rev_chg.md)
+ [OPS05-BP10 Automazione completa dell'integrazione e della distribuzione](ops_dev_integ_auto_integ_deploy.md)
**Documenti correlati:**
+ [AWS Builders Library \$1 Automating safe, hands-off deployments \$1 Production deployments ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/?did=ba_card&trk=ba_card#Production_deployments)
+ [AWS Builders Library \$1 My CI/CD pipeline is my release captain \$1 Safe, automatic production releases](https://aws.amazon.com//builders-library/cicd-pipeline/#Safe.2C_automatic_production_releases)
+ [AWS Whitepaper \$1 Practicing Continuous Integration and Continuous Delivery on AWS \$1 Deployment methods](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html)
+ [Guida per l'utente di AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [Utilizzo di configurazioni di distribuzione in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
+ [Configurazione della distribuzione di una release Canary di API Gateway ](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [Amazon ECS Deployment Types](https://docs.aws.amazon.com/)
+ [Fully Managed Blue/Green Deployments in Amazon Aurora and Amazon RDS](https://aws.amazon.com/blogs/aws/new-fully-managed-blue-green-deployments-in-amazon-aurora-and-amazon-rds/)
+ [Distribuzioni blu/verde con AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
**Video correlati:**
+ [re:Invent 2020 \$1 Hands-off: Automating continuous delivery pipelines at Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [re:Invent 2019 \$1 Amazon's Approach to high-availability deployment](https://www.youtube.com/watch?v=bCgD2bX1LI4)
**Esempi correlati:**
+ [Prova un'implementazione blu/verde di esempio in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [Workshop \$1 Buiding CI/CD pipelines for Lambda canary deployments using AWS CDK](https://catalog.us-east-1.prod.workshops.aws/workshops/5195ab7c-5ded-4ee2-a1c5-775300717f42/en-US)
+ [Workshop \$1 Blue/Green and Canary Deployment for EKS and ECS](https://catalog.us-east-1.prod.workshops.aws/workshops/2175d94a-cd79-4ed2-8e7e-1f0dd1956a3a/en-US)
+ [Workshop \$1 Building a Cross-account CI/CD Pipeline](https://catalog.us-east-1.prod.workshops.aws/workshops/00bc829e-fd7c-4204-9da1-faea3cf8bd88/en-US)
# OPS06-BP04 Automazione dei test e del rollback
Per aumentare la velocità, l'affidabilità e la sicurezza del processo di deployment, rendi disponibile una strategia per le funzionalità di test e rollback automatizzate negli ambienti di pre-produzione e produzione. Automatizza i test durante il deployment in produzione per simulare le interazioni umane e di sistema che verificano le modifiche implementate. Automatizza il rollback per tornare rapidamente allo stato precedente corretto noto. Il rollback deve essere avviato automaticamente in condizioni predefinite, ad esempio quando il risultato desiderato della modifica non viene raggiunto o quando il test automatico fallisce. L'automazione di queste due attività migliora la percentuale di successo dei deployment, riduce al minimo i tempi di ripristino e riduce il potenziale impatto sulle attività aziendali.
**Risultato desiderato:** I test automatici e le strategie di rollback sono integrati nella pipeline di integrazione continua e distribuzione continua (CI/CD). Il monitoraggio è in grado di eseguire la convalida in base ai criteri di successo e avviare il rollback automatico in caso di errore. Ciò riduce al minimo l'impatto sugli utenti finali e sui clienti. Ad esempio, quando tutti i risultati dei test sono stati soddisfatti, promuovi il codice nell'ambiente di produzione in cui vengono avviati i test di regressione automatizzati, sfruttando gli stessi casi di test. Se i risultati dei test di regressione non corrispondono alle aspettative, viene avviato il rollback automatico nel flusso di lavoro della pipeline.
**Anti-pattern comuni:**
+ I tuoi sistemi non sono progettati in modo da consentire loro di essere aggiornati con release più piccole. Di conseguenza, è difficile annullare tali modifiche di massa (bulk changes) durante un deployment conclusosi con esito negativo.
+ Il processo di deployment consiste in una serie di passaggi manuali. Dopo aver distribuito le modifiche al carico di lavoro, inizi i test post-deployment. Dopo il test, ti rendi conto che il tuo carico di lavoro è inutilizzabile e i clienti sono disconnessi. Inizi quindi a eseguire il rollback alla versione precedente. Tutti questi passaggi manuali ritardano il ripristino complessivo del sistema e provocano un impatto prolungato sui clienti.
+ Hai impiegato del tempo a sviluppare casi di test automatizzati per funzionalità che non vengono utilizzate frequentemente nella tua applicazione, riducendo al minimo il ritorno sull'investimento nella tua capacità di eseguire test automatizzati.
+ La versione è composta da applicazioni, infrastrutture, patch e aggiornamenti di configurazione indipendenti l'uno dall'altro. Tuttavia, è disponibile un'unica pipeline CI/CD che fornisce tutte le modifiche contemporaneamente. Un guasto in un componente obbliga a ripristinare tutte le modifiche, rendendo il rollback complesso e inefficiente.
+ Il tuo team completa il lavoro di codifica nello sprint uno e inizia il lavoro dello sprint due, ma il tuo piano non includeva i test fino allo sprint tre. Come conseguenza, i test automatici hanno rivelato difetti dello sprint uno che dovevano essere risolti prima di poter avviare il test dei deliverable dello sprint due e l'intera release viene ritardata, rendendo inutili i test automatizzati.
+ I casi di test di regressione automatizzati per la release di produzione sono completi, ma non stai monitorando lo stato del carico di lavoro. Poiché non è possibile verificare se il servizio è stato riavviato o meno, non sei sicuro se il rollback sia necessario o se sia già avvenuto.
**Vantaggi dell'adozione di questa best practice:** I test automatizzati aumentano la trasparenza del processo di verifica e la capacità di coprire più funzionalità in un periodo di tempo più breve. Testando e convalidando le modifiche nella produzione, è possibile identificare immediatamente i problemi. Il miglioramento della coerenza con strumenti di test automatizzati consente una migliore rilevazione dei difetti. Effettuando automaticamente il rollback alla versione precedente, l'impatto sui clienti viene ridotto al minimo. In ultima analisi, il rollback automatizzato ispira maggiore fiducia nelle capacità di deployment riducendo l'impatto sulle attività aziendali. Nel complesso, queste funzionalità riducono i tempi di consegna garantendo al contempo la qualità.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Automatizza i test degli ambienti distribuiti per verificare che i risultati siano quelli desiderati. Automatizza il rollback a uno stato corretto noto quando non vengono raggiunti i risultati previsti, per ridurre al minimo il tempo di ripristino e gli errori causati dai processi manuali. Integra gli strumenti di test con il flusso di lavoro della pipeline per testare in modo coerente e ridurre al minimo gli input manuali. Dai priorità all'automazione dei casi di test, come quelli che mitigano i rischi maggiori e devono essere testati frequentemente a ogni modifica. Inoltre, automatizza il rollback in base a condizioni specifiche predefinite nel tuo piano di test.
### Passaggi dell'implementazione
1. Stabilisci un ciclo di vita di test per il tuo ciclo di vita di sviluppo che definisca ogni fase del processo di test, dalla pianificazione dei requisiti allo sviluppo dei test case, alla configurazione degli strumenti, ai test automatizzati e alla chiusura dei test case.
1. Crea un approccio di test specifico per il carico di lavoro partendo dalla tua strategia di test complessiva.
1. Prendi in considerazione una strategia di test continuo, laddove appropriato, durante tutto il ciclo di vita dello sviluppo.
1. Seleziona strumenti automatizzati per il test e il rollback in base ai requisiti aziendali e agli investimenti nella pipeline.
1. Decidi quali casi di test desideri automatizzare e quali devono essere eseguiti manualmente. Questi possono essere definiti in base alla priorità del valore aziendale della funzionalità testata. Allinea tutti i membri del team su questo piano e verifica la responsabilità per l'esecuzione di test manuali.
1. Applica le funzionalità di test automatico a casi di test specifici che è opportuno automatizzare, come i casi ripetibili o eseguiti di frequente, quelli che richiedono attività ripetitive o quelli che sono necessari per più configurazioni.
1. Definisci gli script di automazione dei test e i criteri di successo nello strumento di automazione in modo da poter avviare l'automazione continua del flusso di lavoro quando casi specifici falliscono.
1. Definisci criteri di errore specifici per il rollback automatico.
1. Dai priorità all'automazione dei test per ottenere risultati coerenti con lo sviluppo accurato e completo di casi di test in cui la complessità e l'interazione umana hanno un rischio maggiore di fallimento.
1. Integra i tuoi strumenti di test e rollback automatizzati nella tua pipeline CI/CD.
1. Sviluppa criteri di successo chiari per le tue modifiche.
1. Monitora e osserva per rilevare questi criteri e annullare automaticamente le modifiche quando vengono soddisfatti criteri di rollback specifici.
1. Esegui diversi tipi di test di produzione automatizzati, come:
1. Test A/B, per mostrare i risultati rispetto alla versione corrente tra due gruppi di utenti di test.
1. Test Canary, che consente di distribuire la modifica a un sottoinsieme di utenti prima di rilasciarla a tutti.
1. Test con flag delle funzionalità, che consente di attivare e disattivare una singola funzionalità della nuova versione alla volta dall'esterno dell'applicazione, in modo che ogni nuova funzionalità possa essere convalidata una alla volta.
1. Test di regressione, per verificare nuove funzionalità con componenti correlati esistenti.
1. Monitora gli aspetti operativi dell'applicazione, delle transazioni e delle interazioni con altre applicazioni e componenti. Sviluppa report per mostrare il successo delle modifiche in base al carico di lavoro in modo da poter identificare quali parti dell'automazione e del flusso di lavoro possono essere ulteriormente ottimizzate.
1. Sviluppa report sui risultati dei test che ti aiutino a prendere decisioni rapide sull'opportunità o meno di richiamare o meno le procedure di rollback.
1. Implementa una strategia che consenta il rollback automatico basato su condizioni di errore predefinite derivanti da uno o più metodi di test.
1. Sviluppa i tuoi casi di test automatizzati per consentire la riutilizzabilità in caso di modifiche ripetibili future.
**Livello di impegno per il piano di implementazione:** Medio
## Risorse
**Best practice correlate:**
+ [OPS06-BP01 Preparazione di un piano in caso di esito negativo delle modifiche](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 Implementazioni dei test](ops_mit_deploy_risks_test_val_chg.md)
**Documenti correlati:**
+ [AWS Builders Library \$1 Ensuring rollback safety during deployments ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [Redeploy and rollback a deployment with AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html)
+ [ 8 best practices when automating your deployments with AWS CloudFormation](https://aws.amazon.com/blogs/infrastructure-and-automation/best-practices-automating-deployments-with-aws-cloudformation/)
**Esempi correlati:**
+ [ Serverless UI testing using Selenium, AWS Lambda, AWS Fargate, and AWS Developer Tools ](https://aws.amazon.com/blogs/devops/using-aws-codepipeline-aws-codebuild-and-aws-lambda-for-serverless-automated-ui-testing/)
**Video correlati:**
+ [ re:Invent 2020 \$1 Hands-off: Automating continuous delivery pipelines at Amazon ](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [ re:Invent 2019 \$1 Amazon's Approach to high-availability deployment ](https://www.youtube.com/watch?v=bCgD2bX1LI4)