# Implementazione dell'integrazione continua e della consegna continua Implementazione dell'integrazione continua e della consegna continua In questa sezione vengono illustrati i modi in cui è possibile iniziare a implementare un modello CI/CD nell'organizzazione. In questo whitepaper non viene trattato il modo in cui le organizzazioni con un modello di trasformazione cloud e DevOps maturo creino e utilizzino una pipeline CI/CD. Per accompagnarti nel tuo percorso DevOps, AWS ha una serie di [partner DevOps certificati](https://aws.amazon.com/devops/partner-solutions/) che saranno in grado di fornirti risorse e strumenti. Per ulteriori informazioni sulla preparazione per il passaggio ad AWS Cloud, consulta [Realizzazione di un modello operativo su cloud](https://d1.awsstatic.com/whitepapers/building-a-cloud-operating-model.pdf). # Un percorso verso l'integrazione e la consegna continue Un percorso verso l'integrazione e la consegna continue L'approccio CI/CD può essere rappresentato come una pipeline (osserva la figura seguente), in cui il nuovo codice viene inviato su un'estremità, testato durante una serie di fasi (origine, compilazione, gestione temporanea e produzione) e quindi pubblicato come codice pronto per l'ambiente di produzione. Se la tua organizzazione non conosce CI/CD, può affrontare questa pipeline in modo iterativo. Ciò significa che è consigliabile iniziare con poco e iterare in ogni fase in modo da poter comprendere e sviluppare il codice per supportare la crescita dell'organizzazione. ![\[Pipeline CI/CD\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image2.png) * Pipeline CI/CD * Ogni fase della pipeline CI/CD è strutturata come un'unità logica nel processo di consegna. Inoltre, ogni fase funge da gate che controlla un determinato aspetto del codice. Man mano che il codice avanza attraverso la pipeline, si presume che la sua qualità sia più alta nelle fasi successive perché ne vengono verificati sempre più aspetti. I problemi rilevati in una fase iniziale impediscono al codice di progredire nella pipeline. I risultati dei test vengono immediatamente inviati al team e tutte le successive build e rilasci vengono interrotti se il software non supera la fase. Queste fasi sono dei suggerimenti. Puoi adattarle alle esigenze aziendali. Alcune fasi possono essere ripetute per diversi tipi di test, sicurezza e prestazioni. A seconda della complessità del progetto e della struttura dei team, alcune fasi possono essere ripetute più volte a diversi livelli. Ad esempio, il prodotto finale di un team può diventare una dipendenza nel progetto del team successivo. Ciò significa che il prodotto finale del primo team viene successivamente approntato come artefatto nel progetto del team successivo. La presenza di una pipeline CI/CD avrà un grande impatto sulla maturazione delle capacità della tua organizzazione. Per iniziare, l'organizzazione dovrebbe iniziare con fasi di piccole dimensioni invece di cercare di costruire una pipeline completamente matura, con più ambienti e molte fasi di test e automazione in tutte le fasi. Tieni presente che anche le organizzazioni che dispongono di ambienti CI/CD estremamente maturi non smettono comunque di migliorare le proprie pipeline. Costruire un'organizzazione abilitata per CI/CD è un viaggio, con molte destinazioni lungo il percorso. La sezione successiva illustra un possibile percorso che la tua organizzazione potrebbe intraprendere, a partire dall'integrazione continua attraverso i livelli di consegna continua. # Integrazione continua Integrazione continua ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-source-and-build.png) * Integrazione continua: origine e compilazione * La prima fase del percorso CI/CD prevede lo sviluppo della maturità nell'integrazione continua. Assicurati che tutti gli sviluppatori eseguano regolarmente il commit del codice in un repository centrale (ad esempio uno ospitato in CodeCommit o GitHub) e che uniscano tutte le modifiche in un branch di rilascio dell'applicazione. Nessuno sviluppatore deve tenere il codice in isolamento. Se per un certo periodo di tempo è necessario un branch di funzioni, questo dovrebbe essere mantenuto aggiornato tramite il merge da upstream il più frequentemente possibile. I commit e i merge frequenti con le unità di lavoro complete sono due pratiche che il team dovrebbe svolgere al fine di sviluppare la disciplina e sono inoltre incoraggiate dal processo. Uno sviluppatore che unisce il codice nelle prime fasi del processo e con frequenza avrà probabilmente meno problemi di integrazione nelle fasi successive del processo. Ti consigliamo inoltre di incoraggiare gli sviluppatori a creare il prima possibile unit test per le applicazioni e ad eseguirli prima di inviare il codice al repository centrale. Gli errori rilevati nelle prime fasi del processo di sviluppo del software sono i più economici e facili da correggere. Quando il codice viene inviato a un branch in un repository del codice sorgente, un motore del flusso di lavoro che monitora quel branch invierà a uno strumento di compilazione un comando per la compilazione del codice e l'esecuzione degli unit test in un ambiente controllato. Il processo di compilazione deve essere delle dimensioni appropriate per la gestione di tutte le attività, incluse quelle di push e di test che potrebbero verificarsi durante la fase di commit, per l'invio di feedback rapidi. In questa fase possono avere luogo anche altri controlli di qualità, come la copertura degli unit test, il controllo dello stile e l'analisi statica. Infine, lo strumento di compilazione crea una o più build binarie e altri artefatti, come immagini, fogli di stile e documenti per l'applicazione. # Consegna continua: creazione di un ambiente di gestione temporanea Consegna continua: creazione di un ambiente di gestione temporanea ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-staging.png) * Consegna continua: gestione temporanea* La consegna continua (CD) è la fase successiva e prevede l'implementazione del codice dell'applicazione in un ambiente di gestione temporanea, ovvero una replica dello stack di produzione, e l'esecuzione di più test funzionali. L'ambiente di gestione temporanea potrebbe essere un ambiente statico preconfigurato per i test oppure un ambiente dinamico di cui hai eseguito il provisioning e che hai configurato con un'infrastruttura con commit e il codice di configurazione per il test e l'implementazione del codice dell'applicazione. # Consegna continua: creazione di un ambiente di produzione Consegna continua: creazione di un ambiente di produzione ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-production.png) * Consegna continua - ambiente di produzione* Nella sequenza della pipeline di implementazione/consegna, dopo l'ambiente di gestione temporanea c'è l'ambiente di produzione, anch'esso creato tramite Infrastructure as Code (IaC). # Distribuzione continua Distribuzione continua ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-cd.png) *Distribuzione continua* La fase finale della pipeline di implementazione di CI/CD è l'implementazione continua, che può includere la completa automazione dell'intero processo di rilascio del software, inclusa l'implementazione nell'ambiente di produzione. In un ambiente CI/CD completamente maturo, il percorso verso l'ambiente di produzione è completamente automatizzato, il che consente di implementare il codice con elevata affidabilità. # Maturità e oltre Maturità e oltre Man mano che matura, l'organizzazione continuerà a sviluppare il modello CI/CD per includere altri dei seguenti miglioramenti: + Più ambienti di gestione temporanea per test specifici di prestazioni, conformità, sicurezza e interfaccia utente (UI) + Unit test dell'infrastruttura e del codice di configurazione insieme al codice dell'applicazione + Integrazione con altri sistemi e processi come la revisione del codice, il monitoraggio dei problemi e la notifica degli eventi + Integrazione con la migrazione dello schema di database (se applicabile) + Passaggi aggiuntivi per la verifica e l'approvazione aziendale Anche le organizzazioni più mature che dispongono di pipeline CI/CD multi-ambiente complesse continuano a cercare miglioramenti. DevOps è un viaggio, non una destinazione. I feedback sulla pipeline vengono raccolti continuamente e i miglioramenti in termini di velocità, dimensionamento, sicurezza e affidabilità vengono raggiunti sotto forma di una collaborazione tra le diverse parti dei team di sviluppo. # Team Team AWS consiglia di organizzare tre team di sviluppatori per l'implementazione di un ambiente CI/CD: un team delle applicazioni, un team dell'infrastruttura e un team degli strumenti (fai riferimento alla figura seguente). Questa organizzazione rappresenta un insieme di best practice che sono state sviluppate e applicate nelle startup in rapida evoluzione, nelle grandi organizzazioni aziendali e nella stessa Amazon. Il numero dei membri di un team non dovrebbe superare il numero di persone che possono essere sfamate da due pizze, ovvero circa 10-12 persone. Ciò segue la regola di comunicazione secondo cui le conversazioni significative raggiungono dei limiti proporzionali all'aumento delle dimensioni del gruppo e delle linee di comunicazione. ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image7.png) * Team dell'applicazione, dell'infrastruttura e degli strumenti * ## Team dell'applicazione Team dell'applicazione Il team dell'applicazione si occupa della creazione dell'applicazione. Gli sviluppatori dell'applicazione sono proprietari del backlog, delle storie e degli unit test e sviluppano funzioni basate su un target di applicazione specifico. L'obiettivo organizzativo di questo team è ridurre al minimo il tempo che gli sviluppatori dedicano alle attività non principali relative all'applicazione. Oltre ad avere competenze di programmazione funzionali nel linguaggio applicativo, il team dell'applicazione dovrebbe avere competenze relative alla piattaforma e conoscere la configurazione del sistema. In questo modo, il team potrà concentrarsi esclusivamente sullo sviluppo delle funzioni e sul rafforzamento dell'applicazione. ## Team dell’infrastruttura Team dell’infrastruttura Il team dell'infrastruttura scrive il codice che compilerà e configurerà l'infrastruttura necessaria per eseguire l'applicazione. Questo team può utilizzare strumenti AWS nativi, ad esempio AWS CloudFormation, o strumenti generici come Chef, Puppet o Ansible. Il team dell'infrastruttura deve specificare quali risorse sono necessarie e lavora a stretto contatto con il team dell'applicazione. Il team dell'infrastruttura può essere composto da solo una o due persone, nel caso di applicazioni di piccole dimensioni. Il team deve avere competenze relative ai metodi di provisioning dell'infrastruttura, come AWS CloudFormation o HashiCorp Terraform. Il team dovrebbe inoltre sviluppare competenze di automazione della configurazione con strumenti come Chef, Ansible, Puppet o Salt. ## Team degli strumenti Team degli strumenti Il team degli strumenti crea e gestisce la pipeline CI/CD. È responsabile dell'infrastruttura e degli strumenti che compongono la pipeline. I membri di questo team non rientrano nel concetto del two-pizza team; tuttavia, creano uno strumento che viene utilizzato dai team dell'applicazione e dell'infrastruttura dell'organizzazione. L'organizzazione deve far crescere continuamente il proprio team degli strumenti, in modo che sia sempre un passo avanti rispetto ai team dell'applicazione e dell'infrastruttura in fase di crescita. Il team degli strumenti deve essere esperto nella compilazione e nell'integrazione di tutte le parti della pipeline CI/CD. Ciò include la creazione di repository di controllo del codice sorgente, motori del flusso di lavoro, ambienti di compilazione, framework di test e repository di artefatti. Questo team può scegliere di implementare software come AWS CodeStar, AWS CodePipeline, AWS CodeCommit, AWS CodeDeploy, AWS CodeBuild e AWS CodeArtifact, insieme a Jenkins, GitHub, Artifactory, TeamCity e altri strumenti simili. Alcune organizzazioni potrebbero chiamarlo team DevOps, ma AWS sconsiglia di utilizzare questa nomenclatura e incoraggia invece a pensare a DevOps come all'insieme delle persone, dei processi e degli strumenti che compongono la consegna del software. # Fasi di test nei processi di integrazione e consegna continue Fasi di test nei processi di integrazione e consegna continue I tre team CI/CD devono incorporare i test nel ciclo di vita dello sviluppo del software in diverse fasi della pipeline CI/CD. Nel complesso, i test devono iniziare il prima possibile. La seguente piramide di test è un concetto illustrato da Mike Cohn nel libro *Succeeding with Agile*. La piramide mostra i vari test del software in relazione al loro costo e alla velocità con cui vengono eseguiti. ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image8.png) * Piramide di test CI/CD * Gli unit test si trovano alla base della piramide. Sono i più veloci da eseguire e i meno costosi. Pertanto, gli unit test dovrebbero costituire la parte più importante della strategia di test. Per buona regola generale, dovrebbero corrispondere a circa il 70 percento della piramide di test. Gli unit test devono coprire quasi completamente il codice, poiché i bug rilevati in questa fase possono essere risolti in modo rapido ed economicamente vantaggioso. I test del servizio, dei componenti e dell'integrazione si trovano ai livelli superiori della piramide rispetto agli unit test. Questi test richiedono ambienti dettagliati e, pertanto, sono più costosi in termini di requisiti di infrastruttura e prevedono un'esecuzione più lenta. I test delle prestazioni e della conformità si trovano al livello successivo. Richiedono ambienti di qualità di produzione e sono ancora più costosi. I test dell'interfaccia utente e di accettazione utente sono in cima alla piramide e richiedono ambienti di qualità di produzione. Tutti questi test fanno parte di una strategia di test completa per garantire un software di alta qualità. Tuttavia, per la velocità del processo di sviluppo, l'accento è posto sul numero di test e sulla copertura nella metà inferiore della piramide. Nelle sezioni seguenti sono descritte le fasi di CI/CD. ## Configurazione dell'origine Configurazione dell'origine All'inizio del progetto, è essenziale configurare una fonte in cui archiviare il codice non elaborato e le modifiche alla configurazione e allo schema. Nella fase di origine, scegli un repository del codice sorgente, ad esempio uno ospitato in GitHub o AWS CodeCommit. ## Configurazione ed esecuzione delle build Configurazione ed esecuzione delle build L'automazione delle build è un passaggio essenziale del processo CI. Quando si configura l'automazione delle build, occorre innanzitutto scegliere lo strumento di compilazione giusto. Sono disponibili molti strumenti di compilazione, come ad esempio: + Ant, Maven e Gradle per Java + Make per C/C\$1\$1 + Grunt per JavaScript + Rake per Ruby Lo strumento di compilazione più adatto alle tue esigenze dipende dal linguaggio di programmazione del progetto e dalle competenze del team. Dopo aver scelto lo strumento di compilazione, tutte le dipendenze devono essere chiaramente definite negli script di compilazione, insieme ai passaggi di compilazione. Questa è inoltre una best practice per il controllo delle versioni degli artefatti della build finali, che semplifica l'implementazione e il monitoraggio dei problemi. ## Compilazione Compilazione Nella fase di compilazione, gli strumenti di compilazione trattano come input qualsiasi modifica al repository del codice sorgente, compilano il software ed eseguono i seguenti tipi di test: **Unit test:** consentono di testare una sezione specifica di codice per assicurarsi che il codice si comporti come previsto. Gli unit test vengono eseguiti dagli sviluppatori del software durante la fase di sviluppo. In questa fase, è possibile applicare processi di analisi del codice statico, di analisi del flusso di dati, di copertura del codice e altri processi di verifica del software. **Analisi del codice statico:** questo test viene svolto senza eseguire effettivamente l'applicazione dopo gli unit test e i test di compilazione. Questa analisi può aiutare a rilevare errori di codifica e falle di sicurezza e può inoltre garantire la conformità alle linee guida di codifica. ## Gestione temporanea Gestione temporanea Nella fase di gestione temporanea, vengono creati ambienti completi che rispecchiano il futuro ambiente di produzione. Vengono eseguiti i seguenti test: **Test di integrazione**: consentono di verificare le interfacce tra i componenti rispetto alla progettazione del software. Il test di integrazione è un processo iterativo e facilita la creazione di interfacce solide e dell'integrità del sistema. **Test dei componenti:** consentono di testare la trasmissione dei messaggi tra i vari componenti e i relativi risultati. Un obiettivo chiave di questi test potrebbe essere l'idempotenza nel test dei componenti. I test possono includere volumi di dati estremamente elevati o situazioni perimetrali e input anomali. **Test di sistema**: consentono di testare il sistema in modo completo e di verificare se il software soddisfa i requisiti aziendali. Questi test potrebbero includere il test dell'interfaccia utente (UI), dell'API, della logica di back-end e dello stato finale. **Test delle prestazioni:** consentono di determinare la reattività e la stabilità di un sistema durante il funzionamento con un particolare carico di lavoro. I test delle prestazioni vengono inoltre utilizzati per indagare, misurare, convalidare o verificare altri attributi di qualità del sistema, come scalabilità, affidabilità e utilizzo delle risorse. I tipi di test delle prestazioni possono includere test di carico, test di stress e spike test. I test delle prestazioni vengono utilizzati per il benchmark rispetto ai criteri predefiniti. **Test di conformità:** consentono di verificare se la modifica del codice è conforme ai requisiti di una specifica e/o di una normativa non funzionale. Determinano se l'implementazione sta avvenendo nel rispetto degli standard definiti. **Test di accettazione dell'utente:** consentono di convalidare il flusso aziendale completo. Questi test vengono eseguiti da un utente finale in un ambiente di gestione temporanea e consentono di verificare se il sistema soddisfa i requisiti della specifica dei requisiti. In genere, i clienti utilizzano metodologie di test alfa e beta in questa fase. ## Produzione Produzione Infine, dopo aver superato i test precedenti, la fase di gestione temporanea viene ripetuta in un ambiente di produzione. In questa fase, un *test canary* finale può essere completato implementando il nuovo codice solo su un piccolo sottoinsieme di server o anche su un solo server, o in una Regione AWS, prima di implementare il codice nell'intero ambiente di produzione. Le specifiche su come eseguire l'implementazione in modo sicuro nell'ambiente di produzione sono illustrate nella sezione [Metodi di implementazione](deployment-methods.md). Nella sezione successiva viene illustrata la procedura di creazione della pipeline per incorporare le fasi e i test descritti sopra. ## Creazione della pipeline Creazione della pipeline In questa sezione viene illustrata la procedura di creazione della pipeline. Inizia definendo una pipeline con solo i componenti necessari per il processo di CI e quindi passa successivamente a una pipeline di consegna continua con più componenti e fasi. Questa sezione illustra anche come prendere in considerazione l'utilizzo delle funzioni e delle approvazioni manuali di AWS Lambda per i progetti di grandi dimensioni e come pianificare per più team, branch e Regioni AWS. # Iniziare da una pipeline minima funzionante per l'integrazione continua Iniziare da una pipeline minima funzionante per l'integrazione continua Il percorso dell'organizzazione verso la consegna continua inizia con una pipeline minima funzionante (MVP, Minimun Viable Pipeline). Come discusso nella sezione [Implementazione dell'integrazione e della consegna continue](implementing-continuous-integration-and-continuous-delivery.md), i team possono iniziare con un processo molto semplice, come l'implementazione di una pipeline che esegue un controllo dello stile del codice o un singolo unit test senza implementazione. Un componente chiave è lo strumento di orchestrazione della consegna continua. Per aiutarti a creare questa pipeline, Amazon ha sviluppato [AWS CodeStar](https://aws.amazon.com/codestar). ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/aws-codestar-setup.png) * Pagina di configurazione di AWS CodeStar * AWS CodeStar utilizza AWS CodePipeline, AWS CodeBuild, AWS CodeCommit e AWS CodeDeploy con un processo di configurazione, strumenti, modelli e pannello di controllo integrati. AWS CodeStar ti fornisce tutto ciò che ti serve per iniziare rapidamente a sviluppare, creare e distribuire applicazioni in AWS. In questo modo, puoi iniziare a rilasciare il codice più velocemente. I clienti che hanno già familiarità con Console di gestione AWS e cercano un livello di controllo più elevato possono configurare manualmente i loro strumenti di sviluppo preferiti ed effettuare il provisioning dei singoli servizi AWS in base alle loro esigenze. ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codestar-dashboard.png) * Pannello di controllo di AWS CodeStar * AWS CodePipeline è un servizio di CI/CD che può essere utilizzato tramite AWS CodeStar o tramite la Console di gestione AWS per aggiornamenti rapidi e affidabili dell'applicazione e dell'infrastruttura. AWS CodePipeline compila, testa e implementa il codice ogni volta che questo viene modificato, in base ai modelli del processo di rilascio definiti. Questo ti permette di distribuire in modo rapido e affidabile funzionalità e aggiornamenti. Puoi creare una soluzione end-to-end con la massima semplicità impiegando i plug-in preinstallati di servizi di terze parti quali GitHub oppure integrando i tuoi plug-in personalizzati in qualsiasi fase del processo di rilascio. Con AWS CodePipeline, paghi solo per i servizi che utilizzi. Non sono previste tariffe iniziali né impegni a lungo termine. Le fasi di AWS CodeStar e AWS CodePipeline mappano direttamente alle [fasi di origine, compilazione, gestione temporanea e produzione della pipeline CI/CD](testing-stages-in-continuous-integration-and-continuous-delivery.md). Sebbene sia auspicabile la consegna continua, è possibile iniziare con una semplice pipeline in due fasi che controlla il repository del codice sorgente ed esegue un'operazione di compilazione: ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-source-build.png) * AWS CodePipeline - fasi di origine e di compilazione * Per AWS CodePipeline, la fase di origine può accettare gli input da GitHub, AWS CodeCommit e Amazon Simple Storage Service (Amazon S3). L'automazione del processo di compilazione è un primo passaggio fondamentale per l'implementazione della consegna continua e il passaggio all'implementazione continua. L'eliminazione dell'intervento umano nella produzione di artefatti di compilazione toglie un peso al tuo team, riduce al minimo gli errori introdotti dalla creazione manuale dei pacchetti e consente di iniziare a preparare gli artefatti di consumo con maggiore frequenza. AWS CodePipeline funziona perfettamente con AWS CodeBuild, un servizio di compilazione completamente gestito, per semplificare la configurazione di una fase di compilazione all'interno della pipeline che crea pacchetti di codice ed esegue unit test. Con AWS CodeBuild, non è necessario effettuare il provisioning, gestire o dimensionare i propri server di sviluppo. AWS CodeBuild ridimensiona continuamente ed elabora più build in contemporanea in modo che le build non vengano lasciate in attesa nella coda. AWS CodePipeline si integra inoltre con server di sviluppo come Jenkins, Solano CI e TeamCity. Ad esempio, nella successiva fase di compilazione, vengono eseguite in parallelo tre operazioni (unit test, controlli dello stile del codice e raccolta dei parametri del codice). Con AWS CodeBuild, questi passaggi possono essere aggiunti come nuovi progetti senza ulteriori sforzi durante la compilazione o l'installazione dei server di sviluppo per la gestione del carico. ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-build-functionality.png) * AWS CodePipeline - funzionalità di compilazione * Le fasi di origine e di compilazione mostrate nella figura *AWS CodePipeline - fasi di origine e di compilazione*, insieme ai processi e all'automazione sottostanti, supportano la transizione del team verso l'integrazione continua. A questo livello di maturità, gli sviluppatori devono prestare regolarmente attenzione ai risultati della compilazione e dei test. Devono anche creare e mantenere una base di unit test integra. Ciò, a sua volta, rafforza la fiducia dell'intero team nella pipeline CI/CD e ne promuove l'adozione. ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-stages.png) * Fasi di AWS CodePipeline * # Pipeline di consegna continua Pipeline di consegna continua Dopo che la pipeline di integrazione continua è stata implementata e sono stati stabiliti i processi sottostanti, i team possono iniziare la transizione verso la pipeline di consegna continua. Questa transizione prevede l'automatizzazione da parte dei team sia della creazione che dell'implementazione delle applicazioni. Una pipeline di consegna continua è caratterizzata dalla presenza delle fasi di gestione temporanea e di produzione, dove la fase di produzione viene eseguita dopo un'approvazione manuale. Così come hanno creato la pipeline di integrazione continua, i team possono iniziare a creare gradualmente una pipeline di consegna continua scrivendo i propri script di implementazione. A seconda delle esigenze dell'applicazione, è possibile estrarre alcuni passaggi di implementazione dai servizi AWS esistenti. Ad esempio, AWS CodePipeline si integra direttamente con AWS CodeDeploy, un servizio che automatizza le implementazioni di codice nelle istanze Amazon EC2 e nelle istanze in esecuzione on-premise, con AWS OpsWorks, un servizio di gestione della configurazione che consente di utilizzare le applicazioni tramite Chef, e con AWS Elastic Beanstalk, un servizio per l'implementazione e il dimensionamento di applicazioni e servizi Web. AWS dispone di una [documentazione](https://docs.aws.amazon.com/codepipeline/latest/userguide/getting-started-w.html#getting-started-w-create-deployment) dettagliata su come implementare e integrare AWS CodeDeploy con l'infrastruttura e la pipeline. Dopo che il team ha automatizzato correttamente l'implementazione dell'applicazione, le fasi di implementazione possono essere ampliate con vari test. Ad esempio, puoi aggiungere altre integrazioni pronte all'uso con servizi come Ghost Inspector, Runscope e altri, come mostrato nella figura seguente. ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-code-test-deployment.png) * AWS CodePipeline - test del codice nelle fasi di implementazione* # Aggiunta di operazioni Lambda Aggiunta di operazioni Lambda AWS CodeStar e AWS CodePipeline supportano [l'integrazione con AWS Lambda](https://docs.aws.amazon.com/codepipeline/latest/userguide/how-to-lambda-integration.html). Questa integrazione consente di implementare un'ampia serie di attività, come la creazione di risorse personalizzate nell'ambiente, l'integrazione con sistemi di terze parti (come Slack) e l'esecuzione di controlli sull'ambiente appena implementato. Le funzioni Lambda possono essere utilizzate nelle pipeline CI/CD per eseguire le seguenti attività: + Implementare modifiche all'ambiente con l'applicazione o l'aggiornamento di un modello di AWS CloudFormation. + Creare risorse on demand in una fase della pipeline utilizzando AWS CloudFormation ed eliminarle in un'altra fase. + Implementare le versioni dell'applicazione in AWS Elastic Beanstalk senza tempi di inattività con una funzione Lambda che scambia i valori del [record di nome canonico](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) (CNAME). + Eseguire l'implementazione su istanze Docker di Amazon Elastic Container Service (ECS). + Eseguire il backup delle risorse prima della compilazione o dell'implementazione mediante la creazione di uno snapshot AMI. + Aggiungere l'integrazione con i prodotti di terze parti alla pipeline, ad esempio l'invio di messaggi a un client Internet Relay Chat (IRC). # Approvazioni manuali Approvazioni manuali Aggiungi un'operazione di approvazione a una fase in una pipeline nel punto in cui desideri che l'esecuzione della pipeline venga interrotta per consentire a un utente che dispone delle autorizzazioni AWS Identity and Access Management (IAM) richieste di approvare o rifiutare l'operazione. Se l'operazione viene approvata, l'elaborazione della pipeline riprende. Se l'operazione viene rifiutata, o se nessuno approva o rifiuta l'operazione entro sette giorni da quando la pipeline raggiunge l'operazione e l'interruzione, il risultato è identico a un'operazione non riuscita e l'elaborazione della pipeline non continua. ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codedeploy-manual-approvals.png) * AWS CodeDeploy - approvazioni manuali * # Implementazione delle modifiche al codice dell'infrastruttura in una pipeline CI/CD Implementazione delle modifiche al codice dell'infrastruttura in una pipeline CI/CD AWS CodePipeline consente di selezionare AWS CloudFormation come operazione di implementazione in qualsiasi fase della pipeline. Puoi quindi scegliere l'operazione specifica che desideri venga eseguita da AWS CloudFormation, ad esempio la creazione o l'eliminazione di stack e la creazione o l'esecuzione dei [set di modifiche](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html#d0e3952). Uno [stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html#d0e3929) è un concetto di AWS CloudFormation e rappresenta un gruppo di risorse AWS correlate. Sebbene ci siano molti modi per effettuare il provisioning di Infrastructure as Code, AWS CloudFormation è uno strumento completo consigliato da AWS come soluzione scalabile e completa in grado di descrivere il set più completo di risorse AWS come codice. AWS consiglia di utilizzare AWS CloudFormation in un progetto di AWS CodePipeline per [tenere traccia delle modifiche e dei test dell'infrastruttura](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/continuous-delivery-codepipeline.html). # CI/CD per applicazioni serverless CI/CD per applicazioni serverless È inoltre possibile utilizzare AWS CodeStar, AWS CodePipeline, AWS CodeBuild e AWS CloudFormation per creare pipeline CI/CD per applicazioni serverless. Le applicazioni serverless integrano servizi gestiti come [ Amazon Cognito](https://aws.amazon.com/cognito), Amazon S3 e Amazon DynamoDB con i servizi basati su eventi e AWS Lambda per implementare le applicazioni in un modo che non richiede la gestione dei server. Se sei uno sviluppatore di applicazioni serverless, puoi utilizzare la combinazione di AWS CodePipeline, AWS CodeBuild e AWS CloudFormation per automatizzare le fasi di compilazione, test e implementazione delle applicazioni serverless espresse in modelli creati con AWS Serverless Application Model. Per ulteriori informazioni, fai riferimento alla documentazione su AWS Lambda relativa all'[automazione dell'implementazione delle applicazioni basate su Lambda](https://docs.aws.amazon.com/lambda/latest/dg/automating-deployment.html). Puoi inoltre creare pipeline CI/CD sicure che seguono le best practice della tua organizzazione con le pipeline AWS Serverless Application Model (Pipeline AWS SAM). Le pipeline AWS SAM sono una nuova funzione della CLI di AWS SAM che consente di usufruire in pochi minuti dei vantaggi offerti da CI/CD, come l'accelerazione della frequenza di implementazione, la riduzione dei tempi di applicazione delle modifiche e la riduzione degli errori di implementazione. Le pipeline AWS SAM includono una serie di modelli di pipeline predefiniti per AWS CodeBuild/CodePipeline basati sulle best practice di implementazione di AWS. Per ulteriori informazioni e per guardare il tutorial, consulta il blog[ Introducing AWS SAM Pipelines](https://aws.amazon.com/blogs/compute/introducing-aws-sam-pipelines-automatically-generate-deployment-pipelines-for-serverless-applications/). # Pipeline per più team, branch e regioni AWS Pipeline per più team, branch e regioni AWS Per un progetto di grandi dimensioni, non è raro che più team di progetto lavorino su componenti diversi. Se più team utilizzano un unico repository di codice, questo può essere mappato in modo che ogni team abbia il proprio branch. Ci dovrebbe essere anche un branch di integrazione o di rilascio per l'unione finale del progetto. Se viene utilizzata un'architettura orientata ai servizi o ai microservizi, ogni team potrebbe avere il proprio repository di codice. Nel primo scenario, se viene utilizzata una singola pipeline, è possibile che un team possa influenzare l'avanzamento degli altri team bloccando la pipeline. AWS consiglia di creare pipeline specifiche per i branch dei team e un'altra pipeline di rilascio per la consegna finale del prodotto. # Integrazione della pipeline con AWS CodeBuild Integrazione della pipeline con AWS CodeBuild AWS CodeBuild è progettato per consentire alla tua organizzazione di creare un processo di compilazione ad alta disponibilità con scalabilità quasi illimitata. AWS CodeBuild fornisce ambienti di avvio rapido per parecchi dei linguaggi di programmazione più diffusi, oltre alla possibilità di eseguire un qualsiasi container Docker specificato. Con i vantaggi della stretta integrazione con AWS CodeCommit, AWS CodePipeline e AWS CodeDeploy, così come grazie alle operazioni Lambda di Git e CodePipeline, lo strumento CodeBuild è altamente flessibile. Il software può essere compilato mediante l'inclusione di un file `buildspec.yml` che identifica ciascuna delle fasi di compilazione, incluse le operazioni precedenti e successive alla compilazione o le operazioni specifiche, tramite lo strumento CodeBuild. Puoi visualizzare la cronologia dettagliata di ogni build sul pannello di controllo di CodeBuild. Gli eventi vengono archiviati come file di log di Amazon CloudWatch Logs. ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cloudwatch-logs-log-files.png) * File di log di CloudWatch Logs in AWS CodeBuild * # Integrazione della pipeline con Jenkins Integrazione della pipeline con Jenkins Puoi utilizzare lo strumento di compilazione di Jenkins [per creare pipeline di consegna](https://www.jenkins.io/doc/book/pipeline/getting-started/). Queste pipeline utilizzano processi standard che definiscono i passaggi per l'implementazione delle fasi di consegna continua. Tuttavia, questo approccio potrebbe non essere ottimale per progetti di maggiori dimensioni perché lo stato attuale della pipeline non persiste tra i diversi riavvii di Jenkins, l'implementazione dell'approvazione manuale non è semplice e il monitoraggio dello stato di una pipeline complessa può essere complicato. AWS consiglia invece di implementare la consegna continua con Jenkins utilizzando il [plug-in AWS Code Pipeline](https://wiki.jenkins-ci.org/display/JENKINS/AWS+CodePipeline+Plugin). Questo plug-in consente di descrivere flussi di lavoro complessi utilizzando un linguaggio specifico del dominio simile a Groovy e può essere utilizzato per orchestrare pipeline complesse. La funzionalità del plug-in AWS Code Pipeline può essere migliorata tramite plug-in satelliti come il[ plug-in Pipeline Stage View](https://plugins.jenkins.io/aws-codepipeline/), che consente di visualizzare l'avanzamento delle fasi definite in una pipeline, o il [plug-in Pipeline Multibranch](https://plugins.jenkins.io/workflow-multibranch/), che raggruppa le build provenienti da branch diversi. AWS consiglia di archiviare la configurazione della pipeline in *Jenkinsfile* e di inserirla inoltre in un repository del codice sorgente. In questo modo, potrai tenere traccia delle modifiche al codice della pipeline, soprattutto quando utilizzi il plug-in Pipeline Multibranch. AWS consiglia inoltre di dividere la pipeline in fasi per raggruppare logicamente le fasi della pipeline e fare inoltre in modo che il plug-in Pipeline Stage View visualizzi lo stato corrente della pipeline. La figura seguente mostra un esempio di pipeline Jenkins, con quattro fasi definite visualizzate dal plug-in Pipeline Stage View. ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/defined-stages-of-jenkins.png) *Fasi definite della pipeline Jenkins visualizzate dal plug-in Pipeline Stage View*