Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Comprendere CI/CD
L'integrazione e la distribuzione continue (CI/CD) sono il processo di automazione del ciclo di vita delle release del software. *In alcuni casi, il *D* in CI/CD può anche significare implementazione.* La differenza tra distribuzione *continua e distribuzione* *continua* si verifica quando si rilascia una modifica all'ambiente di produzione. Con la distribuzione continua, è necessaria un'approvazione manuale prima di promuovere modifiche alla produzione. L'implementazione continua prevede un flusso ininterrotto attraverso l'intera pipeline e non sono richieste approvazioni esplicite. Poiché questa strategia illustra CI/CD concetti generali, i consigli e le informazioni fornite sono applicabili sia agli approcci di distribuzione continua che a quelli di distribuzione continua.
CI/CD automates much or all of the manual processes traditionally required to get new code from a commit into production. A CI/CD pipeline encompasses the source, build, test, staging, and production stages. In each stage, the CI/CD pipelines provisions any infrastructure that is needed to deploy or test the code. By using a CI/CDpipeline, i team di sviluppo possono apportare modifiche al codice che vengono poi testate automaticamente e inviate alla distribuzione.
Esaminiamo il CI/CD processo di base prima di esaminare alcuni dei modi in cui è possibile, consapevolmente o inconsapevolmente, discostarsi dall'essere fasi e attività complete CI/CD. The following diagram shows the CI/CD in ogni fase.
![\[Le cinque fasi di un CI/CD processo e le attività e gli ambienti di ciascuna di esse.\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/strategy-cicd-litmus/images/cicd-stages.png)
## Informazioni sull'integrazione continua
L'integrazione continua avviene in un repository di codice, ad esempio un repository Git in. GitHub Consideri un singolo ramo principale come la fonte di verità per la base di codice e crei rami di breve durata per lo sviluppo di funzionalità. Si integra un feature branch nel ramo principale quando si è pronti a implementare la funzionalità negli ambienti superiori. I feature branch non vengono mai distribuiti direttamente negli ambienti superiori. Per ulteriori informazioni sul tagging, consulta [Approccio basato su Trunk](fully-cicd-process-differences.md#trunk-based-approach)in questa guida.
*Processo di integrazione continuo*
1. Lo sviluppatore crea un nuovo ramo dal ramo principale.
1. Lo sviluppatore apporta modifiche, compilazioni e test a livello locale.
1. Quando le modifiche sono pronte, lo sviluppatore crea una [pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (GitHub documentazione) con il ramo principale come destinazione.
1. Il codice viene esaminato.
1. Quando il codice viene approvato, viene unito al ramo principale.
## Informazioni sulla consegna continua
La distribuzione continua avviene in ambienti isolati, come ambienti di sviluppo e ambienti di produzione. Le azioni che si verificano in ogni ambiente possono variare. Spesso, una delle prime fasi viene utilizzata per aggiornare la pipeline stessa prima di procedere. Il risultato finale della distribuzione è che ogni ambiente viene aggiornato con le ultime modifiche. Anche il numero di ambienti di sviluppo per la creazione e il test varia, ma è consigliabile utilizzarne almeno due. Nella pipeline, ogni ambiente viene aggiornato in base alla sua importanza, per finire con l'ambiente più importante, l'ambiente di produzione.
*Processo di consegna continuo*
La parte di distribuzione continua della pipeline inizia estraendo il codice dal ramo principale del repository di origine e passandolo alla fase di compilazione. Il documento Infrastructure as Code (IaC) per il repository delinea le attività eseguite in ogni fase. Sebbene l'utilizzo di un documento IaC non sia obbligatorio, si consiglia vivamente di utilizzare un servizio o uno strumento IaC, come [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)o [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html). I passaggi più comuni includono:
1. Test unitari
1. Compilazione del codice
1. Fornitura di risorse
1. Test di integrazione
Se si verificano errori o i test falliscono in qualsiasi fase della pipeline, la fase corrente torna allo stato precedente e la pipeline viene terminata. Le modifiche successive devono iniziare nell'archivio del codice e completare l'intero processo. CI/CD
# Test per le condutture CI/CD
I due tipi di test automatici a cui si fa comunemente riferimento nelle pipeline di distribuzione sono *i test unitari e i test* di *integrazione*. Tuttavia, esistono molti tipi di test che è possibile eseguire su una base di codice e nell'ambiente di sviluppo. L'[architettura di riferimento di AWS Deployment Pipeline](https://pipelines.devops.aws.dev/application-pipeline/) definisce i seguenti tipi di test:
+ **Test unitario**: questi test creano ed eseguono il codice dell'applicazione per verificare che funzioni in base alle aspettative. Simulano tutte le dipendenze esterne utilizzate nella codebase. [Esempi di strumenti di unit test includono [JUnit](https://junit.org/)[Jest](https://jestjs.io/) e pytest.](https://pytest.org/)
+ **Test di integrazione**: questi test verificano che l'applicazione soddisfi i requisiti tecnici eseguendo test in un ambiente di test predisposto. [Esempi di strumenti di test di integrazione includono [Cucumber](https://cucumber.io/), [VRest NG](https://vrest.io/) e integ-tests (for).](https://docs.aws.amazon.com/cdk/api/v2/docs/integ-tests-alpha-readme.html) AWS CDK
+ **Test di accettazione**: questi test verificano che l'applicazione soddisfi i requisiti degli utenti eseguendo test in un ambiente di test predisposto. [Esempi di strumenti di test di accettazione includono [Cypress](https://cypress.io/) e Selenium.](https://selenium.dev/)
+ **Test sintetici**: questi test vengono eseguiti continuamente in background per generare traffico e verificare che il sistema sia integro. Esempi di strumenti di test sintetici includono [Amazon CloudWatch Synthetics [e](https://www.dynatrace.com/monitoring/platform/synthetic-monitoring/) Dynatrace](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) Synthetic Monitoring.
+ **Test delle prestazioni: questi test** simulano la capacità di produzione. Determinano se l'applicazione soddisfa i requisiti prestazionali e confrontano le metriche con le prestazioni precedenti. [Esempi di strumenti di test delle prestazioni includono [Apache JMeter](https://jmeter.apache.org/), [Locust](https://locust.io/) e Gatling.](https://gatling.io/)
+ **Test di resilienza**: noti anche come test del *caos, questi test* iniettano i guasti negli ambienti per identificare le aree a rischio. I periodi in cui i guasti vengono iniettati vengono quindi confrontati con i periodi senza guasti. [Esempi di strumenti di test di resilienza includono e Gremlin. [AWS Fault Injection Service](https://aws.amazon.com/fis/)](https://www.gremlin.com/)
+ **Test statico di sicurezza delle applicazioni (SAST)**: questi test analizzano il codice per rilevare eventuali violazioni della sicurezza, come [SQL injection](https://owasp.org/www-community/attacks/SQL_Injection) o [cross-site](https://owasp.org/www-community/attacks/xss/) scripting (XSS). Esempi di strumenti SAST includono [Amazon CodeGuru](https://aws.amazon.com/codeguru/) e [SonarQube](https://www.sonarqube.org/)[Checkmarx](https://checkmarx.com/).
+ **Test dinamico di sicurezza delle applicazioni (DAST)***: questi test sono noti anche come test di *penetrazione* o pen test.* Identificano vulnerabilità, come SQL injection o XSS in un ambiente di test predisposto. [Esempi di strumenti DAST includono [Zed Attack Proxy (ZAP](https://www.zaproxy.org/)) e HCL. AppScan](https://www.hcltechsw.com/appscan) [Per ulteriori informazioni, vedere Penetration Testing.](https://aws.amazon.com/security/penetration-testing/)
Non tutte le CI/CD pipeline eseguono completamente tutti questi test. Tuttavia, come minimo, una pipeline dovrebbe eseguire test unitari e test SAST sulla base di codice, nonché test di integrazione e accettazione in un ambiente di test.
# Metriche per le pipeline CI/CD
Secondo l'[architettura di riferimento AWS di Deployment Pipeline](https://pipelines.devops.aws.dev/application-pipeline/), è necessario tenere traccia almeno delle seguenti quattro metriche per le pipeline: CI/CD
+ **Lead time**: il tempo medio impiegato da un singolo commit per arrivare fino alla produzione. Ti consigliamo di impostare un lead time compreso tra 1 ora e 1 giorno, a seconda del caso d'uso.
+ **Frequenza di implementazione**: il numero di implementazioni di produzione in un determinato periodo di tempo. Consigliamo di impostare come target le frequenze di implementazione da più volte al giorno a due volte alla settimana, a seconda del caso d'uso.
+ **Tempo medio tra i guasti (MTBF)**: il periodo di tempo medio tra l'avvio di una pipeline riuscita e l'inizio di una pipeline fallita. Consigliamo di puntare a un MTBF il più alto possibile. [Per ulteriori informazioni, consulta Incremento dell'MTBF.](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/increasing-mtbf.html)
+ **Tempo medio di ripristino (MTTR)**: il periodo di tempo medio tra l'avvio di una pipeline fallita e l'inizio della successiva pipeline riuscita. Ti consigliamo di scegliere come target un MTTR il più basso possibile. [Per ulteriori informazioni, consulta Ridurre l'MTTR.](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)
Queste metriche aiutano i team a tenere traccia dei progressi verso la completa trasformazione in CI/CD. I team dovrebbero avere discussioni aperte con le parti interessate dell'organizzazione su quali dovrebbero essere gli obiettivi ottimali. Le situazioni e le esigenze variano notevolmente da un'organizzazione all'altra e persino da un team all'altro.
È molto importante ricordare che cambiamenti rapidi e drastici di solito aumentano il rischio di insorgenza di problemi. Stabilisci degli obiettivi per puntare a piccoli miglioramenti incrementali. Un lead time ottimale comune per CI/CD pipeline complete è inferiore a 3 ore. Un team che inizia con un lead time di 5,2 giorni dovrebbe puntare a una riduzione di un giorno ogni poche settimane. Dopo che questo team ha raggiunto un lead time di un giorno o meno, può rimanere lì per diversi mesi e passare a un lead time più aggressivo solo se le parti interessate del team e dell'organizzazione lo ritengono necessario.