# OPS 6. In che modo mitighi i rischi dell'implementazione?
Adotta approcci 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 l'implementazione delle modifiche.
**Topics**
+ [
# OPS06-BP01 Piano per modifiche non riuscite
](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [
# OPS06-BP02 Implementazioni di test
](ops_mit_deploy_risks_test_val_chg.md)
+ [
# OPS06-BP03 Utilizza strategie di implementazione sicure
](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [
# OPS06-BP04 Automatizza i test e il rollback
](ops_mit_deploy_risks_auto_testing_and_rollback.md)
# OPS06-BP01 Piano per modifiche non riuscite
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 policy 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 implementazione e rollback, le policy 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'implementazione 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'implementazione conclusasi con esito negativo.
+ Non utilizzi il modello Infrastructure as code (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 delle implementazioni, 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 misuri 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 implementazione e l'efficacia del piano di ripristino.
**Vantaggi derivanti dall'adozione di questa procedura ottimale:** disporre di un piano di ripristino in caso di modifiche non riuscite riduce al minimo il tempo medio di ripristino () MTTR e riduce l'impatto aziendale.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all'implementazione
Una policy 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 policy 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 policy che richiedono ai team di disporre di piani efficaci per invertire le modifiche entro un periodo di tempo specificato.
1. Le policy 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 policy 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 aziendale minore.
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 policy 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'implementazione 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 Automatizza i test e il rollback](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**Documenti correlati:**
+ [AWS Builders Library \$1 Garantire la sicurezza del rollback durante le implementazioni](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [AWS Whitepaper \$1 Gestione delle modifiche nel 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 di test
Testa le procedure di rilascio in pre-produzione utilizzando la stessa configurazione di implementazione, 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 implementazione con l'opportunità di pianificarli e mitigarli prima del passaggio nell'ambiente di produzione.
Puoi creare ambienti paralleli temporanei per testare ogni modifica. Automatizza l'implementazione degli ambienti di test utilizzando il modello Infrastructure as code (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 implementazione 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 del modello Infrastructure as code (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:** elevato
## Guida all'implementazione
Testare il processo di implementazione è importante quanto testare le modifiche derivanti dall'implementazione. Ciò può essere ottenuto testando le fasi di implementazione in un ambiente di pre-produzione che rispecchi il più fedelmente possibile quello di produzione. I problemi più comuni, come fasi di implementazione 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 propria pipeline di integrazione e distribuzione continua (CI/CD), AnyCompany Retail esegue le fasi definite necessarie 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 le deviazioni (il rilevamento delle modifiche alle risorse eseguite al di fuori dell'IaC) nelle risorse prima dell'implementazione, nonché per convalidare le azioni che l'IaC intraprende al suo avvio. Convalida le fasi dell'implementazione, ad esempio la verifica che determinati file e configurazioni siano presenti e che i servizi siano in esecuzione e rispondano correttamente ai controlli dell'integrità sull'host locale, prima di effettuare nuovamente la registrazione sul bilanciatore 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 deriva](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html) per rilevare quando le risorse sono state modificate all'esterno. CloudFormation
1. Utilizzate [i set di modifiche](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html) per verificare che l'intento di un aggiornamento dello stack corrisponda alle azioni CloudFormation intraprese all'avvio del 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 distribuzione, come [AWS CodeDeploy AppSpec](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html)i file, per definire le fasi di distribuzione e convalida.
1. Ove applicabile, esegui [AWS CodeDeploy l'integrazione con altri AWS servizi](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html) o [AWS CodeDeploy con prodotti e servizi dei partner](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html).
1. [Monitora le distribuzioni](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html) utilizzando Amazon e CloudWatch le AWS CloudTrail notifiche SNS degli eventi di Amazon.
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) relativi alle implementazioni.
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:** elevato
## Risorse
**Best practice correlate:**
+ [OPS05-BP02 Test e convalida delle modifiche](ops_dev_integ_test_val_chg.md)
**Documenti correlati:**
+ [AWS Builders' Library \$1 Automatizzazione di implementazioni sicure e pratiche \$1 Distribuzioni di test](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/#Test_deployments_in_pre-production_environments)
+ [AWS Whitepaper \$1 Praticare l'integrazione continua e la distribuzione continua su 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 ed eseguire il debug AWS CodeDeploy localmente prima di spedire 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 Implementazione e ECS servizio Amazon con un test di convalida](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorial-ecs-deployment-with-hooks.html)
# OPS06-BP03 Utilizza strategie di implementazione 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 implementazione. I roll-out sicuri possono includere strategie come feature-flags, one-box, roll-out (release canary), immutabili, suddivisioni del traffico e implementazioni 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:**
+ Implementi una modifica non riuscita a tutta la produzione contemporaneamente. Di conseguenza, tutti i clienti vengono colpiti contemporaneamente.
+ Un difetto introdotto in un'implementazione simultanea 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'implementazione 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 implementazione 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 implementazione di successo, implementa i controlli di sicurezza nel processo di rilascio end-to-end per ridurre al minimo gli errori di implementazione, con l'obiettivo di raggiungere il traguardo di zero errori.
**Esempio del cliente**
La missione di AnyCompany Retail è raggiungere implementazioni con tempi di inattività minimi o pari a zero, il che significa che non vi deve essere alcun impatto percepibile dagli utenti durante le implementazioni. A tal fine, l'azienda ha stabilito modelli di implementazione (vedi il seguente diagramma del flusso di lavoro) come roll-out e implementazioni 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/latest/framework/images/deployment-process-ec2.png) | ![\[Flusso del processo di implementazione per Amazon ECS\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/framework/images/deployment-process-ecs.png) | ![\[Flusso del processo di implementazione per Lambda\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/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. Usa un sistema di implementazione automatizzata come [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html). Le [opzioni di implementazioni](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps.html) AWS CodeDeploy comprendono le implementazioni locali (in-place) per EC2/on-premises e le implementazioni blu/verde per EC2/on-premises. 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 [con prodotti e servizi dei partner AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html).
1. Ricorri a implementazioni blu/verde 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) utilizzando Amazon CloudWatch, AWS CloudTrail e le notifiche di eventi di Amazon Simple Notification Service (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) relativi alle implementazioni.
**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 Apporta modifiche frequenti, piccole e reversibili](ops_dev_integ_freq_sm_rev_chg.md)
+ [OPS05-BP10 Automazione completa dell'integrazione e dell'implementazione](ops_dev_integ_auto_integ_deploy.md)
**Documenti correlati:**
+ [AWS Builders Library \$1 Automatizzazione di distribuzioni pratiche e sicure \$1 Distribuzioni di produzione ](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)
+ [ Whitepaper AWS \$1 Integrazione e distribuzione continua in AWS \$1 Metodi di implementazione](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html)
+ [AWS CodeDeploy Guida per l’utente di](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [Working with deployment configurations in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
+ [Set up an API Gateway canary release deployment ](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/)
+ [Blue/Green deployments with 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 in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [ Workshop \$1 Creazione di pipeline CI/CD per le distribuzioni canary Lambda mediante AWS CDK](https://catalog.workshops.aws/cdk-cicd-for-lambda-canary-deployment/en-US)
+ [ Workshop \$1 Creazione della prima pipeline blu/verde DevOps con Amazon ECS ](https://catalog.us-east-1.prod.workshops.aws/workshops/4b59b9fb-48b6-461c-9377-907b2e33c9df/en-US)
+ [ Workshop \$1 Creazione della prima pipeline blu/verde DevOps con Amazon EKS ](https://catalog.us-east-1.prod.workshops.aws/workshops/4eab6682-09b2-43e5-93d4-1f58fd6cff6e/en-US)
+ [ Workshop \$1 GitOps EKS con ArgoCD ](https://catalog.workshops.aws/eksgitops-argocd-githubactions)
+ [ Workshop \$1 Workshop su CI/CD su AWS](https://catalog.workshops.aws/cicdonaws/en-US)
+ [ Implementazione di CI/CD su più account con funzioni Lambda basate su container AWS SAM](https://aws.amazon.com/blogs/compute/implementing-cross-account-cicd-with-aws-sam-for-container-based-lambda/)
# OPS06-BP04 Automatizza i test e il rollback
Per aumentare la velocità, l'affidabilità e la sicurezza del processo di implementazione, rendi disponibile una strategia per le funzionalità di test e rollback automatizzate negli ambienti di pre-produzione e produzione. Automatizza i test durante l'implementazione nella 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 delle implementazioni, 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'implementazione conclusasi con esito negativo.
+ Il processo di implementazione consiste in una serie di passaggi manuali. Dopo aver distribuito le modifiche al carico di lavoro, inizi i test post-implementazione. 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 implementazione riducendo l'impatto sulle attività aziendali. Nel complesso, queste funzionalità si riducono garantendo al contempo la qualità. time-to-delivery
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Automatizza i test degli ambienti implementati 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 non più 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 Piano per modifiche non riuscite](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 Implementazioni di test](ops_mit_deploy_risks_test_val_chg.md)
**Documenti correlati:**
+ [AWS Builders Library \$1 Garantire la sicurezza in caso di rollback durante le implementazioni](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [Ridistribuisci e ripristina una distribuzione con AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html)
+ [8 best practice per automatizzare le implementazioni con AWS CloudFormation](https://aws.amazon.com/blogs/infrastructure-and-automation/best-practices-automating-deployments-with-aws-cloudformation/)
**Esempi correlati:**
+ [Test dell'interfaccia utente senza server utilizzando Selenium e Developer Tools AWS LambdaAWS FargateAWS](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)