# REL 8 In che modo implementi le modifiche?
Per distribuire nuove funzionalità e garantire che i carichi di lavoro e l'ambiente operativo eseguano software noti e che sia possibile applicare patch o sostituirli in modo prevedibile, sono necessarie modifiche controllate. Se invece non sono controllate, risulta difficile prevederne l'effetto o risolvere eventuali problemi che causano.
**Topics**
+ [REL08-BP01 Utilizzo di runbook per attività standard come l'implementazione](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 Esecuzione di test funzionali come parte integrante dell'implementazione](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 Esecuzione di test di resilienza come parte integrante dell'implementazione](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 Esecuzione dell'implementazione utilizzando un'infrastruttura immutabile](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 Implementazione delle modifiche tramite automazione](rel_tracking_change_management_automated_changemgmt.md)
# REL08-BP01 Utilizzo di runbook per attività standard come l'implementazione
I runbook sono le procedure predefinite per ottenere risultati specifici. Utilizza i runbook per eseguire attività standard, o manualmente o automaticamente. Alcuni esempi includono l'implementazione di un carico di lavoro, l'applicazione di patch a un carico di lavoro o la realizzazione di modifiche DNS.
Ad esempio, metti in atto processi per [garantire la sicurezza del rollback durante le distribuzioni](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments). Garantire la possibilità di eseguire il rollback di una distribuzione senza interruzioni per i clienti è fondamentale per rendere un servizio affidabile.
Per le procedure di runbook, inizia da un processo manuale valido ed efficace, implementalo nel codice e attivalo per l'esecuzione automatica, se necessario.
Anche per carichi di lavoro sofisticati e altamente automatizzati, i runbook rimangono utili per [eseguire game day](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays) o soddisfare rigorosi requisiti di reportistica e audit.
Tieni presente che i playbook vengono utilizzati in risposta a incidenti specifici e i runbook vengono utilizzati per ottenere risultati specifici. Spesso, i runbook sono per attività di routine, mentre i playbook vengono utilizzati per rispondere a eventi non di routine.
**Anti-pattern comuni:**
+ Eseguire modifiche impreviste alla configurazione nella produzione.
+ Ignorare le fasi del piano per velocizzare l'implementazione, compromettendone la riuscita.
+ Apportare modifiche senza testarne l'annullamento.
**Vantaggi dell'adozione di questa best practice:** Una pianificazione efficace aumenta la capacità di eseguire correttamente la modifica, perché sei a conoscenza di tutti i sistemi interessati. Convalidare la modifica negli ambienti di test aumenta la sicurezza.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Abilita risposte coerenti e tempestive agli eventi noti documentando le procedure nei runbook.
+ [Framework AWS Well-Architected – Concetti – Runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ Uso del principio di infrastruttura come codice per definire l'infrastruttura Utilizzando AWS CloudFormation o una terza parte affidabile per definire la tua infrastruttura, puoi utilizzare un software per il controllo delle versioni per gestire le versioni e tenere traccia delle modifiche.
+ Utilizza AWS CloudFormation o un provider di terze parti affidabile per definire l'infrastruttura.
+ [Che cos'è AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ Crea modelli unici e disaccoppiati, utilizzando solidi principi di progettazione del software.
+ Stabilisci le autorizzazioni, i modelli e le parti responsabili dell'implementazione
+ [ Controllo degli accessi con AWS Identity and Access Management](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)
+ Utilizza un controllo sorgente come AWS CodeCommit o uno strumento di terze parti affidabili per il controllo delle versioni.
+ [Che cos'è AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner per la creazione di soluzioni di distribuzione automatizzate](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [Marketplace AWS: prodotti per l'automazione delle distribuzioni](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [Framework AWS Well-Architected – Concetti – Runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ [Che cos'è AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [Che cos'è AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
**Esempi correlati:**
+ [Automating operations with Playbooks and Runbooks (Automazione delle operazioni con Playbook e Runbook)](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL08-BP02 Esecuzione di test funzionali come parte integrante dell'implementazione
I test funzionali vengono eseguiti come parte integrante della distribuzione automatizzata. Se non vengono soddisfatti i criteri di esito positivo, la pipeline viene arrestata o ripresa dall'inizio.
Questi test vengono eseguiti in un ambiente di pre-produzione, gestito per fasi prima della produzione nella pipeline. Idealmente, questa operazione viene eseguita come parte di una pipeline di distribuzione.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Esegui test funzionali come parte integrante dell'implementazione. I test funzionali vengono eseguiti come parte integrante della distribuzione automatizzata. Se non vengono soddisfatti i criteri di esito positivo, la pipeline viene arrestata o ripresa dall'inizio.
+ Richiama AWS CodeBuild durante l'azione di test delle pipeline di rilascio di software modellate in AWS CodePipeline. Questa funzionalità consente di eseguire facilmente un'ampia gamma di test sul codice, tra cui test delle unità, analisi del codice statico e test di integrazione.
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild (AWS CodePipeline aggiunge il supporto per i test di unità e integrazione personalizzati con AWS CodeBuild)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ Utilizza le soluzioni Marketplace AWS per eseguire test automatizzati come parte integrante della tua pipeline di distribuzione di software.
+ [Automazione e test del software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## Risorse
**Documenti correlati:**
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild (AWS CodePipeline aggiunge il supporto per i test di unità e integrazione personalizzati con AWS CodeBuild)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [Automazione e test del software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [Che cos'è AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
# REL08-BP03 Esecuzione di test di resilienza come parte integrante dell'implementazione
I test di resilienza (eseguiti utilizzando i [Principles of Chaos Engineering](https://principlesofchaos.org/)) vengono svolti nell'ambito della pipeline di implementazione automatizzata in un ambiente di pre-produzione.
Questi test vengono gestiti per fasi ed eseguiti nella pipeline di pre-produzione. Devono anche essere eseguiti in produzione, ma come parte di [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays).
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Esegui test di resilienza come parte integrante della distribuzione Utilizza l'ingegneria del caos, la disciplina che consiste nello sperimentare su un carico di lavoro per aumentare la fiducia nella capacità del carico di lavoro di resistere a condizioni turbolente in produzione.
+ I test di resilienza inseriscono errori o causano un degrado delle risorse per valutare se il carico di lavoro risponde con la resilienza progettata
+ [Corso Well-Architected: Level 300: Testing for Resiliency of EC2 RDS and S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
+ Questi test possono essere eseguiti regolarmente in ambienti di pre-produzione nelle pipeline di distribuzione automatizzate.
+ È opportuno eseguirli anche in produzione, nell'ambito delle giornate di gioco pianificate.
+ A partire dai principi di ingegneristica del caos, avanza ipotesi sulle prestazioni del carico di lavoro in caso di vari problemi, quindi mettile alla prova utilizzando i test di resilienza.
+ [Principles of Chaos Engineering](https://principlesofchaos.org/)
## Risorse
**Documenti correlati:**
+ [Principles of Chaos Engineering](https://principlesofchaos.org/)
+ [Che cos'è AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Esempi correlati:**
+ [Corso Well-Architected: Level 300: Testing for Resiliency of EC2 RDS and S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
# REL08-BP04 Esecuzione dell'implementazione utilizzando un'infrastruttura immutabile
L'infrastruttura immutabile è un modello che richiede che non vengano applicati aggiornamenti, patch di sicurezza o modifiche di configurazione sui carichi di lavoro di produzione. Quando è necessaria una modifica, l'architettura viene costruita su una nuova infrastruttura e distribuita alla produzione.
L'implementazione più comune del paradigma dell'infrastruttura immutabile è il ***server immutabile***. Ciò significa che se un server necessita di un aggiornamento o di una correzione, vengono distribuiti nuovi server invece di aggiornare quelli già in uso. Pertanto, invece di accedere al server tramite SSH e aggiornare la versione del software, ogni modifica nell'applicazione inizia con un push del software al repository di codice, ad esempio git push. Poiché non sono consentite modifiche nell'infrastruttura immutabile, puoi essere sicuro dello stato del sistema distribuito. Le infrastrutture immutabili sono intrinsecamente più coerenti, affidabili e prevedibili e semplificano molti aspetti dello sviluppo e delle operazioni di software.
Utilizza una distribuzione Canary o blue/green durante la distribuzione di applicazioni in infrastrutture immutabili.
[https://martinfowler.com/bliki/CanaryRelease.html](https://martinfowler.com/bliki/CanaryRelease.html) : è la pratica di indirizzare un piccolo numero di clienti alla nuova versione, in genere in esecuzione su una singola istanza di servizio (la release Canary). Quindi analizzerai in modo approfondito le modifiche di comportamento o gli errori generati. Puoi rimuovere il traffico dalla release Canary in caso di problemi critici e reindirizzare gli utenti alla versione precedente. Se la distribuzione viene completata correttamente, puoi continuare a distribuire alla velocità desiderata, monitorando le modifiche alla ricerca di errori, fino a quando non sarai completamente distribuito. AWS CodeDeploy può essere configurato con una configurazione di distribuzione che abilita una distribuzione Canary.
[https://martinfowler.com/bliki/BlueGreenDeployment.html](https://martinfowler.com/bliki/BlueGreenDeployment.html) : è simile alla distribuzione Canary, tranne per il fatto che un intero parco dell'applicazione è distribuito in parallelo. Puoi alternare le distribuzioni tra i due stack (blue e green). Ancora una volta, puoi inviare il traffico alla nuova versione e tornare alla versione precedente in caso di problemi con la distribuzione. Generalmente, tutto il traffico viene trasferito contemporaneamente, tuttavia puoi anche utilizzare frazioni del traffico verso ciascuna versione per accelerare l'adozione della nuova versione mediante le funzionalità di instradamento DNS ponderato di Amazon Route 53. AWS CodeDeploy e AWS Elastic Beanstalk possono essere impostati con una configurazione di implementazione che abilita un'implementazione blu/verde.
![\[Diagramma che mostra l'implementazione blu/verde con AWS Elastic Beanstalk e Amazon Route 53\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/blue-green-deployment.png)
Vantaggi dell'infrastruttura immutabile:
+ **Riduzione delle deviazioni di configurazione:** sostituendo frequentemente i server da una configurazione di base, nota e controllata dalla versione, l'infrastruttura viene **reimpostata** a uno stato noto, evitando deviazioni di configurazione.
+ **Distribuzioni semplificate**: le distribuzioni sono semplificate perché non devono supportare gli aggiornamenti. Gli aggiornamenti sono solo nuove distribuzioni.
+ **Distribuzioni atomiche affidabili:** le distribuzioni vengono completate correttamente o non cambia nulla. Offre maggiore fiducia nel processo di distribuzione.
+ **Distribuzioni più sicure con processi di rollback e ripristino rapidi:** Le distribuzioni sono più sicure perché la versione funzionante precedente non viene modificata. Puoi eseguire il rollback se vengono rilevati errori.
+ **Ambienti di test e debug ottimizzati:** poiché tutti i server utilizzano la stessa immagine, non ci sono differenze tra gli ambienti. Una build viene distribuita in più ambienti. Inoltre, evita ambienti incoerenti e semplifica test e debug.
+ **Maggiore scalabilità:** poiché i server utilizzano un'immagine di base, sono coerenti e ripetibili, la scalabilità automatica è intrinseca.
+ **Toolchain semplificata**: la toolchain è semplificata poiché è possibile eliminare gli strumenti di gestione della configurazione che gestiscono gli aggiornamenti del software di produzione. Non vengono installati altri strumenti o agenti sui server. Le modifiche vengono apportate all'immagine di base, testate e implementate.
+ **Maggiore sicurezza:** negando tutte le modifiche ai server, puoi disabilitare SSH sulle istanze e rimuovere le chiavi. Questo riduce il vettore di attacco, migliorando l'assetto di sicurezza dell'organizzazione.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Distribuisci utilizzando un'infrastruttura immutabile. Un'infrastruttura immutabile è un modello che impone che non vengano *applicati* aggiornamenti, patch di sicurezza o modifiche sui carichi di lavoro di produzione. Quando è necessaria una modifica, viene creata una nuova versione dell'architettura e distribuita alla produzione.
+ [Panoramica di una distribuzione Blue/Green](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [Distribuzione graduale di applicazioni serverless](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [Infrastruttura immutabile: affidabilità, coerenza e fiducia attraverso l'immutabilità](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [Release Canary](https://martinfowler.com/bliki/CanaryRelease.html)
## Risorse
**Documenti correlati:**
+ [Release Canary](https://martinfowler.com/bliki/CanaryRelease.html)
+ [Distribuzione graduale di applicazioni serverless](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [Infrastruttura immutabile: affidabilità, coerenza e fiducia attraverso l'immutabilità](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [Panoramica di una distribuzione Blue/Green](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [The Amazon Builders' Library: Garantire la sicurezza del rollback durante le distribuzioni](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
# REL08-BP05 Implementazione delle modifiche tramite automazione
Le distribuzioni e l'applicazione di patch sono automatizzate per eliminare l'impatto negativo.
Apportare modifiche ai sistemi produttivi è una delle maggiori aree di rischio per molte organizzazioni. Riteniamo che le distribuzioni siano un problema prioritario da risolvere insieme ai problemi aziendali affrontati dal software. Oggi, ciò significa l'uso dell'automazione ovunque sia pratica nelle operazioni, inclusi test e distribuzione di modifiche, aggiunta o rimozione di capacità e migrazione dei dati. AWS CodePipeline consente di gestire le fasi necessarie per rilasciare il carico di lavoro. Questo include uno stato di distribuzione che utilizza AWS CodeDeploy per automatizzare la distribuzione del codice dell'applicazione su istanze Amazon EC2, istanze in locale, funzioni Lambda serverless o servizi Amazon ECS.
**Consiglio**
Anche se la prassi comune suggerisce di includere le persone nelle procedure operative più difficili, suggeriamo di automatizzare le procedure più difficili proprio per questo motivo.
**Anti-pattern comuni:**
+ Eseguire le modifiche manualmente.
+ Ignorare le fasi dell'automazione attraverso i flussi di lavoro di emergenza.
+ Non seguire i piani.
**Vantaggi dell'adozione di questa best practice:** L'utilizzo dell'automazione per distribuire tutte le modifiche scongiura il rischio di introdurre errori umani e consente di effettuare test prima di modificare la produzione, così da garantire che i piani siano completi.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Automatizzazione della pipeline di distribuzione Le pipeline di distribuzione permettono di richiamare test automatici, rilevare le anomalie e interrompere la pipeline a una determinata fase prima della distribuzione in produzione o eseguire automaticamente il ripristino di una modifica.
+ [The Amazon Builders' Library: Garantire la sicurezza del rollback durante le distribuzioni](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [The Amazon Builders' Library: Più velocità con una consegna continua](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ Utilizza AWS CodePipeline (o un prodotto di terze parti affidabile) per definire ed eseguire le tue pipeline.
+ Configura la pipeline in modo che inizi quando si effettua il commit di una modifica al repository del codice.
+ [Che cos'è AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ Utilizza Amazon Simple Notification Service (Amazon SNS) e Amazon Simple Email Service (Amazon SES) per inviare notifiche sui problemi nella pipeline o integrarti utilizzando uno strumento di chat per team, ad esempio Amazon Chime.
+ [Che cos'è Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [Che cos'è Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Che cos'è Amazon Chime?](https://docs.aws.amazon.com/chime/latest/ug/what-is-chime.html)
+ [Automatizza i messaggi delle chat con webhook.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner per la creazione di soluzioni di distribuzione automatizzate](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [Marketplace AWS: prodotti per l'automazione delle distribuzioni](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [Automatizza i messaggi delle chat con webhook.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
+ [The Amazon Builders' Library: Garantire la sicurezza del rollback durante le distribuzioni](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [The Amazon Builders' Library: Più velocità con una consegna continua](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ [Che cos'è AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ [Che cos'è CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ [Che cos'è Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Che cos'è Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
**Video correlati:**
+ [AWS Summit 2019: CI/CD su AWS (AWS Summit: CI/CD su AWS)](https://youtu.be/tQcF6SqWCoY)