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à.
# Che cos'è AWS CodePipeline?
AWS CodePipeline è un servizio di distribuzione continua che puoi utilizzare per modellare, visualizzare e automatizzare i passaggi necessari per il rilascio del software. È possibile modellare e configurare rapidamente le diverse fasi di un processo di rilascio del software. CodePipeline automatizza i passaggi necessari per rilasciare continuamente le modifiche al software. Per informazioni sui prezzi di CodePipeline, vedi [Prezzi](https://aws.amazon.com/codepipeline/pricing/).
**Topics**
+ [Integrazione e distribuzione continua](concepts-continuous-delivery-integration.md)
+ [Cosa posso fare con CodePipeline?](welcome-what-can-I-do.md)
+ [Una rapida occhiata a CodePipeline](welcome-introducing.md)
+ [Come posso iniziare con CodePipeline?](welcome-get-started.md)
+ [CodePipeline concetti](concepts.md)
+ [DevOps esempio di pipeline](concepts-devops-example.md)
+ [Funzionamento delle esecuzioni pipeline](concepts-how-it-works.md)
+ [Artefatti di input e output](welcome-introducing-artifacts.md)
+ [Come funzionano le condizioni dello stage?](concepts-how-it-works-conditions.md)
+ [Tipi di tubazioni](pipeline-types.md)
+ [Quale tipo di pipeline è adatto a me?](pipeline-types-planning.md)
# Integrazione e distribuzione continua
CodePipeline è un servizio *di fornitura continua* che automatizza la creazione, il test e l'implementazione del software in produzione.
La [distribuzione continua](https://aws.amazon.com/devops/continuous-delivery/) è una metodologia di sviluppo software in cui il processo di rilascio è automatizzato. Ogni modifica software viene automaticamente compilata, testata e distribuita in un ambiente di produzione. Una persona, un test automatico o una regola di business decide quando eseguire il push finale in produzione. Anche se ogni modifica software riuscita può essere immediatamente rilasciata per la produzione con la distribuzione continua, non tutte le modifiche devono essere rilasciate immediatamente.
[L'integrazione continua](https://aws.amazon.com/devops/continuous-integration/) è una pratica di sviluppo software in cui i membri di un team utilizzano un sistema di controllo delle versioni e spesso integrano il proprio lavoro nella stessa posizione, ad esempio in una filiale principale. Ogni modifica viene compilata e verificata per rilevare gli errori di integrazione il più rapidamente possibile. L'integrazione continua è incentrata sulla compilazione e il test automatico del codice, in confronto alla *distribuzione continua* che automatizza l'intero processo di rilascio del software fino alla produzione.
Per ulteriori informazioni, consulta [Practicing Continuous Integration and Continuous Delivery on AWS: Accelerating Software Delivery with](https://d0.awsstatic.com/whitepapers/DevOps/practicing-continuous-integration-continuous-delivery-on-AWS.pdf). DevOps
Puoi utilizzare la CodePipeline console, il AWS Command Line Interface (AWS CLI) AWS SDKs, o qualsiasi combinazione di questi strumenti per creare e gestire le tue pipeline.
# Cosa posso fare con CodePipeline?
Puoi CodePipeline utilizzarlo per aiutarti a creare, testare e distribuire automaticamente le tue applicazioni nel cloud. Nello specifico, puoi eseguire le operazioni seguenti:
+ **Automatizza i processi di rilascio**: automatizza CodePipeline completamente il processo di rilascio dall'inizio alla fine, a partire dal repository di origine fino alla compilazione, al test e alla distribuzione. Puoi impedire lo spostamento delle modifiche in una pipeline includendo un'operazione di approvazione manuale in una fase qualsiasi, ad eccezione della fase di origine. Puoi rilasciare quando vuoi, come vuoi, sui sistemi che vuoi, attraverso una o più istanze.
+ **Stabilisci un processo di rilascio coerente**: definisci una serie coerente di passaggi per ogni modifica del codice. CodePipeline esegue ogni fase del rilascio in base ai tuoi criteri.
+ **Accelera la distribuzione migliorando la qualità**: puoi automatizzare il processo di rilascio per consentire agli sviluppatori di testare e rilasciare il codice in modo incrementale e accelerare il rilascio di nuove funzionalità per i propri clienti.
+ **Usa i tuoi strumenti preferiti**: puoi incorporare nella pipeline gli strumenti di origine, compilazione e distribuzione esistenti. Per un elenco completo degli strumenti Servizi AWS di terze parti attualmente supportati da CodePipeline, consulta[Integrazioni di prodotti e servizi con CodePipeline](integrations.md).
+ **Visualizza i progressi a colpo d'occhio**: puoi esaminare lo stato in tempo reale delle tue pipeline, controllare i dettagli di eventuali avvisi, riprovare le fasi o le azioni non riuscite, visualizzare i dettagli sulle revisioni dei sorgenti utilizzate nell'ultima esecuzione della pipeline in ogni fase e rieseguire manualmente qualsiasi pipeline.
+ **Visualizza i dettagli della cronologia della pipeline: puoi visualizzare i dettagli** sulle esecuzioni di una pipeline, inclusi gli orari di inizio e fine, la durata di esecuzione e l'esecuzione. IDs
# Una rapida occhiata a CodePipeline
Il seguente diagramma mostra un esempio del processo di rilascio utilizzando CodePipeline.
![\[Un esempio di processo di rilascio che utilizza CodePipeline.\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/PipelineFlow.png)
In questo esempio, quando gli sviluppatori eseguono il commit delle modifiche in un repository di origine, CodePipeline rileva automaticamente le modifiche. Queste modifiche vengono compilate e, se configurati, vengono eseguiti i test. Dopo aver completato i test, il codice compilato viene distribuito ai server della gestione temporanea per il test. Dal server di staging, CodePipeline esegue più test, ad esempio test di integrazione o di carico. Una volta completati con successo tali test e dopo l'approvazione di un'azione di approvazione manuale aggiunta alla pipeline, CodePipeline distribuisce il codice testato e approvato nelle istanze di produzione.
CodePipeline può distribuire applicazioni su istanze EC2 utilizzando, o. CodeDeploy AWS Elastic Beanstalk AWS OpsWorks Stacks CodePipeline può anche distribuire applicazioni basate su container ai servizi utilizzando Amazon ECS. Gli sviluppatori possono anche utilizzare i punti di integrazione forniti CodePipeline per collegare altri strumenti o servizi, tra cui servizi di compilazione, fornitori di test o altri obiettivi o sistemi di distribuzione.
Una pipeline può essere semplice o complessa, come richiede il processo di rilascio.
# Come posso iniziare con CodePipeline?
Per iniziare con CodePipeline:
1. **Scopri** come CodePipeline funziona leggendo la [CodePipeline concetti ](concepts.md) sezione.
1. **Preparati** all'uso CodePipeline seguendo i passaggi riportati di seguito[Iniziare con CodePipeline](getting-started-codepipeline.md).
1. **Sperimenta** CodePipeline seguendo i passaggi dei [CodePipeline tutorial](tutorials.md) tutorial.
1. **Utilizzalo** CodePipeline per i tuoi progetti nuovi o esistenti seguendo i passaggi riportati di seguito. [Crea una pipeline, fasi e azioni](pipelines-create.md)
# CodePipeline concetti
La modellazione e la configurazione del processo di rilascio automatico sono più semplici se si comprendono i concetti e i termini utilizzati in. AWS CodePipeline Di seguito sono riportati alcuni concetti che occorre conoscere quando si utilizza CodePipeline.
Per un esempio di DevOps pipeline, vedi. [DevOps esempio di pipeline](concepts-devops-example.md)
I seguenti termini vengono utilizzati in CodePipeline:
**Topics**
+ [Pipeline](#concepts-pipelines)
+ [Esecuzioni pipeline](#concepts-executions)
+ [Operazioni sullo stage](#concepts-stage-executions)
+ [Esecuzioni di operazioni](#concepts-action-executions)
+ [Tipi di esecuzione](#concepts-execution-types)
+ [Tipi di operazione](#concepts-action-types)
+ [Artifacts](#concepts-artifacts)
+ [Revisioni delle origini](#concepts-source-revisions)
+ [Triggers](#concepts-triggers)
+ [Variabili](#concepts-variables)
+ [Condizioni](#concepts-conditions)
+ [Regole](#concepts-rules)
## Pipeline
Una *pipeline* è una struttura di flusso di lavoro che descrive le fasi del processo di rilascio delle modifiche software. Ogni pipeline è composta da una serie di *fasi*.
### Stage
Una fase è un'unità logica che è possibile utilizzare per isolare un ambiente e limitare il numero di modifiche simultanee in tale ambiente. Ogni fase contiene operazioni eseguite sugli [artefatti](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-artifacts)dell'applicazione. Il codice sorgente è un esempio di un artefatto. Una fase potrebbe essere una fase di compilazione, in cui viene creato il codice sorgente e vengono eseguiti i test. Può anche essere una fase di distribuzione, in cui il codice viene distribuito in ambienti runtime. Ogni fase è composta da una serie di *azioni* seriali o parallele.
### Transizioni
Una *transizione* è il punto in cui l'esecuzione di una pipeline passa alla fase successiva della pipeline. È possibile disabilitare la transizione in ingresso di uno stage per impedire che le esecuzioni entrino in quella fase e quindi abilitare la transizione per consentire alle esecuzioni di continuare. Quando più di un'esecuzione arriva a una transizione disabilitata, solo l'esecuzione più recente continua alla fase successiva quando la transizione è abilitata. Ciò significa che le esecuzioni più recenti continuano a sostituire le esecuzioni in attesa mentre la transizione è disabilitata e quindi, dopo che la transizione è attivata, l'esecuzione che continua è l'esecuzione sostitutiva.
![\[Una pipeline include fasi che contengono operazioni, separate dalle transizioni che possono essere disabilitate e abilitate.\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/pipeline-elements-workflow.png)
### Azioni
Un'*azione* è un insieme di operazioni eseguite sul codice dell'applicazione e configurate in modo che le azioni vengano eseguite nella pipeline in un punto specificato. Ciò può includere elementi come un'azione di origine da una modifica del codice, un'azione per la distribuzione dell'applicazione nelle istanze e così via. Ad esempio, una fase di distribuzione potrebbe contenere un'azione di distribuzione che distribuisce il codice a un servizio di elaborazione come Amazon EC2 o. AWS Lambda
I tipi di CodePipeline azione validi sono`source`,`build`,`test`, `deploy``approval`, e. `invoke` Per un elenco dei provider di operazioni, consulta [Fornitori di azioni validi in CodePipeline](actions-valid-providers.md).
Le azioni possono essere eseguite in serie o in parallelo. Per informazioni sulle azioni seriali e parallele in una fase, consulta le `runOrder` informazioni in [Requisiti della struttura delle azioni](https://docs.aws.amazon.com/codepipeline/latest/userguide/reference-pipeline-structure.html#action-requirements).
## Esecuzioni pipeline
Un'*esecuzione* è un insieme di modifiche rilasciate da una pipeline. Ogni esecuzione della pipeline è univoca e ha un proprio ID. Un'esecuzione corrisponde a una serie di modifiche, ad esempio un commit unito o una versione manuale dell'ultimo commit. Due esecuzioni possono rilasciare lo stesso insieme di modifiche in momenti diversi.
Mentre una pipeline può elaborare più esecuzioni contemporaneamente, una fase di pipeline elabora solo un'esecuzione alla volta. A tale scopo, uno stage viene bloccato mentre elabora un'esecuzione. Due esecuzioni di pipeline non possono occupare la stessa fase nello stesso momento. L'esecuzione in attesa di entrare nella fase occupata viene riferita a un'*esecuzione in entrata*. Un'esecuzione in entrata può comunque fallire, essere sostituita o essere interrotta manualmente. Per ulteriori informazioni sul funzionamento delle esecuzioni in entrata, consulta. [Come funzionano le esecuzioni in entrata](concepts-how-it-works.md#how-it-works-inbound-executions)
Le esecuzioni della pipeline attraversano le fasi della pipeline in ordine. Gli stati validi per le pipeline sono `InProgress`, `Stopping`, `Stopped`, `Succeeded`, `Superseded` e `Failed`.
Per ulteriori informazioni, consulta [PipelineExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineExecution.html).
### Esecuzioni interrotte
L'esecuzione della pipeline può essere interrotta manualmente in modo che l'esecuzione della pipeline in corso non continui attraverso la pipeline. Se viene interrotta manualmente, l'esecuzione di una pipeline mostra uno stato `Stopping` fino a quando non viene completamente interrotta. Quindi mostra uno stato `Stopped`. È possibile ripetere l'esecuzione di una pipeline `Stopped`.
Esistono due modi per interrompere l'esecuzione di una pipeline:
+ **Fermati e aspetta**
+ **Fermati e abbandona**
Per informazioni sui casi d'uso per arrestare un'esecuzione e i dettagli della sequenza per queste opzioni, vedere [Come vengono interrotte le esecuzioni di pipeline](concepts-how-it-works.md#concepts-how-it-works-stopping).
### Esecuzioni non riuscite
Se un'esecuzione fallisce, si arresta e non attraversa completamente la pipeline. Il suo stato è `FAILED` e la fase è sbloccata. Un'esecuzione più recente può recuperare ed entrare nella fase sbloccata e bloccarla. È possibile riprovare un'esecuzione non riuscita a meno che l'esecuzione non riuscita non sia stata sostituita o non sia ripristinabile. È possibile ripristinare una fase fallita riportandola a una precedente esecuzione riuscita.
### Modalità di esecuzione
Per fornire l'ultimo set di modifiche tramite una pipeline, le esecuzioni più recenti passano e sostituiscono le esecuzioni meno recenti già in esecuzione attraverso la pipeline. In questo caso, l'esecuzione precedente viene sostituita dall'esecuzione più recente. Un'esecuzione può essere sostituita da un'esecuzione più recente in un certo punto, che è il punto tra le fasi. SUPERSEDED è la modalità di esecuzione predefinita.
In modalità SUPERSEDED, se un'esecuzione è in attesa di entrare in una fase bloccata, un'esecuzione più recente potrebbe recuperarla e sostituirla. L'esecuzione più recente ora attende lo sblocco dello stage e l'esecuzione sostituita si arresta con uno stato `SUPERSEDED`. Quando l'esecuzione di una pipeline viene sostituita, l'esecuzione viene interrotta e non attraversa completamente la pipeline. Non è più possibile riprovare l'esecuzione sostituita dopo che è stata sostituita in questa fase. Le altre modalità di esecuzione disponibili sono la modalità PARALLEL o QUEUED.
Per ulteriori informazioni sulle modalità di esecuzione e sulle fasi bloccate, vedere. [Come vengono elaborate le esecuzioni in modalità SOSTITUITA](concepts-how-it-works.md#concepts-how-it-works-executions)
## Operazioni sullo stage
Quando l'esecuzione di una pipeline attraversa una fase, questa è in fase di completamento di tutte le azioni al suo interno. Per informazioni sul funzionamento delle operazioni sullo stage e sulle fasi bloccate, vedere[Come vengono elaborate le esecuzioni in modalità SOSTITUITA](concepts-how-it-works.md#concepts-how-it-works-executions).
Gli stati validi per gli stadi sono `InProgress``Stopping`,`Stopped`,`Succeeded`, e`Failed`. È possibile riprovare una fase fallita a meno che la fase fallita non sia riprovabile. Per ulteriori informazioni, consulta [StageExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_StageExecution.html). È possibile ripristinare una fase fino a un'esecuzione precedente specificata con successo. Una fase può essere configurata per il rollback automatico in caso di errore, come descritto in[Configurazione del rollback dello stage](stage-rollback.md). Per ulteriori informazioni, consulta [RollbackStage](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_RollbackStage.html).
## Esecuzioni di operazioni
Un'*esecuzione di un'operazione* è il processo di completamento di un'operazione configurata che opera su [artefatti](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-artifacts) designati. Questi possono essere artefatti di input, artefatti di output, o entrambi. Ad esempio, un'azione di compilazione potrebbe eseguire comandi di compilazione su un artefatto di input, ad esempio la compilazione del codice sorgente dell'applicazione. I dettagli relativi all'esecuzione dell'azione includono un ID di esecuzione dell'azione, il trigger dell'origine dell'esecuzione della pipeline correlata e gli artefatti di input e output per l'azione.
Gli stati validi per le azioni sono`InProgress`, `Abandoned``Succeeded`, o`Failed`. Per ulteriori informazioni, consulta [ActionExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_ActionExecution.html).
## Tipi di esecuzione
L'esecuzione di una pipeline o di uno stage può essere un'esecuzione standard o ripristinata.
Per i tipi standard, l'esecuzione ha un ID univoco ed è un'esecuzione completa della pipeline. Un rollback della pipeline ha una fase da ripristinare e un'esecuzione riuscita per la fase come esecuzione di destinazione a cui eseguire il rollback. L'esecuzione della pipeline di destinazione viene utilizzata per recuperare le revisioni e le variabili di origine per la riesecuzione dello stage.
## Tipi di operazione
I *tipi di azione* sono azioni preconfigurate disponibili per la selezione in. CodePipeline Il tipo di azione è definito dal proprietario, dal provider, dalla versione e dalla categoria. Il tipo di azione fornisce parametri personalizzati che vengono utilizzati per completare le attività di azione in una pipeline.
Per informazioni sui prodotti Servizi AWS e servizi di terze parti che puoi integrare nella tua pipeline in base al tipo di azione, consulta. [Integrazioni con tipi di CodePipeline azioni](integrations-action-type.md)
Per informazioni sui modelli di integrazione supportati per i tipi di azione in CodePipeline, consulta[Riferimento al modello di integrazione](reference-integrations.md).
Per informazioni su come i provider di terze parti possono configurare e gestire i tipi di azione in CodePipeline, vedere[Lavorare con i tipi di azione](action-types.md).
## Artifacts
*Gli artefatti* si riferiscono alla raccolta di dati, come il codice sorgente dell'applicazione, le applicazioni create, le dipendenze, i file di definizioni, i modelli e così via, che vengono elaborati dalle azioni della pipeline. Gli artefatti sono prodotti da alcune azioni e consumati da altre. In una pipeline, gli artefatti possono essere l'insieme di file lavorati da un'azione (*artefatti di input*) o l'output aggiornato di un'azione completata (*artefatti di output*).
Le azioni passano l'output a un'altra azione per un'ulteriore elaborazione utilizzando il bucket di artefatti della pipeline. CodePipeline copia gli artefatti nel negozio degli artefatti, dove l'azione li raccoglie. Per ulteriori informazioni sugli artefatti, vedi [Artefatti di input e output](welcome-introducing-artifacts.md).
## Revisioni delle origini
Quando si effettua una modifica del codice sorgente, viene creata una nuova versione. Una *revisione dell’origine* è la versione di una modifica di origine che attiva l'esecuzione di una pipeline. Un'esecuzione elabora le revisioni dei sorgenti. Per i CodeCommit repository GitHub e gli archivi, questo è il commit. Per bucket o azioni S3, questa è la versione dell'oggetto.
È possibile avviare l'esecuzione di una pipeline con una revisione del codice sorgente, ad esempio un commit, specificata dall'utente. L'esecuzione elaborerà la revisione specificata e sostituirà quella che sarebbe stata la revisione utilizzata per l'esecuzione. Per ulteriori informazioni, consulta [Avvia una pipeline con una modifica della revisione del codice sorgente](pipelines-trigger-source-overrides.md).
## Triggers
*I trigger* sono eventi che avviano la pipeline. Alcuni trigger, come l'avvio manuale di una pipeline, sono disponibili per tutti i provider di azioni di origine presenti in una pipeline. Alcuni trigger dipendono dal fornitore di origine di una pipeline. Ad esempio, CloudWatch gli eventi devono essere configurati con risorse di eventi di Amazon CloudWatch a cui è stato aggiunto l'ARN della pipeline come destinazione nella regola dell'evento. Amazon CloudWatch Events è il trigger consigliato per il rilevamento automatico delle modifiche per le pipeline con un'azione sorgente CodeCommit o S3. I webhook sono un tipo di trigger configurato per eventi di repository di terze parti. Ad esempio, WebHookV2 è un tipo di trigger che consente di utilizzare i tag Git per avviare pipeline con provider di sorgenti di terze parti come GitHub .com, GitHub Enterprise Server, GitLab .com, GitLab self-managed o Bitbucket Cloud. Nella configurazione della pipeline, puoi specificare un filtro per i trigger, come la richiesta push o pull. Puoi filtrare gli eventi push del codice su tag Git, branch o percorsi di file. È possibile filtrare gli eventi di pull request in base a eventi (aperti, aggiornati, chiusi), rami o percorsi di file.
Per ulteriori informazioni sui trigger, consulta [Avvia una pipeline in CodePipeline](pipelines-about-starting.md). Per un tutorial che ti spiega come usare i tag Git come trigger per la tua pipeline, vedi. [Tutorial: usa i tag Git per avviare la tua pipeline](tutorials-github-tags.md)
**Importante**
Le pipeline che rimangono inattive per più di 30 giorni avranno il polling disabilitato per la pipeline. Per ulteriori informazioni, consulta il riferimento alla struttura della [pollingDisabledAt](pipeline-requirements.md#metadata.pollingDisabledAt)pipeline. [Per i passaggi per migrare la pipeline dal polling al rilevamento delle modifiche basato sugli eventi, consulta Metodi di rilevamento delle modifiche.](change-detection-methods.md)
## Variabili
Una *variabile* è un valore che può essere utilizzato per configurare dinamicamente le azioni nella pipeline. Le variabili possono essere dichiarate a livello di pipeline o emesse da azioni nella pipeline. I valori delle variabili vengono risolti al momento dell'esecuzione della pipeline e possono essere visualizzati nella cronologia delle esecuzioni. Per le variabili dichiarate a livello di pipeline, potete definire valori predefiniti nella configurazione della pipeline o sovrascriverli per una determinata esecuzione. Per le variabili emesse da un'azione, il valore è disponibile dopo che un'azione è stata completata con successo. Per ulteriori informazioni, consulta [Riferimento alle variabili](reference-variables.md).
## Condizioni
Una *condizione* contiene un insieme di regole che vengono valutate. Se tutte le regole di una condizione hanno esito positivo, la condizione viene soddisfatta. È possibile configurare le condizioni in modo che, quando i criteri non vengono soddisfatti, venga attivato il risultato specificato, ad esempio il fallimento della fase. Le condizioni vengono anche chiamate gate perché consentono di specificare quando un'esecuzione entrerà e verrà attraversata da una fase o uscirà dalla fase dopo averla superata. Ciò equivale a consentire a una linea di traffico su una strada di riunirsi in corrispondenza di un cancello chiuso e quindi a specificare l'apertura del cancello per consentire il flusso del traffico verso un'area. I risultati per i tipi di condizione includono il fallimento della fase o il ripristino della fase. Le condizioni consentono di specificare quando queste azioni vengono eseguite in una fase di pipeline. È possibile sovrascrivere le condizioni in fase di esecuzione.
Esistono tre tipi di condizioni. Le condizioni di ingresso rispondono alla domanda «Se le regole relative alla condizione sono soddisfatte, entra nella fase». La fase viene bloccata quando l'esecuzione entra nella fase, quindi vengono eseguite le regole. Per le condizioni On Failure, la regola si attiva quando una fase ha avuto esito negativo, con il risultato del ripristino di una fase non riuscita. Per le condizioni On Success, la regola si attiva quando una fase ha esito positivo, ad esempio verifica la presenza di allarmi prima di procedere. Ad esempio, una condizione On Success comporterebbe il ripristino di una fase riuscita se la CloudWatchAlarm regola rileva la presenza di allarmi nell'ambiente di distribuzione. Per ulteriori informazioni, consulta [Come funzionano le condizioni dello stage?](concepts-how-it-works-conditions.md).
## Regole
Le condizioni utilizzano una o più *regole* preconfigurate che vengono eseguite ed eseguono controlli che poi attivano il risultato configurato quando la condizione non viene soddisfatta. Ad esempio, il rispetto di tutte le regole relative a una regola di condizione di ingresso che verifica lo stato degli allarmi e gli orari delle finestre di distribuzione determinerà una fase di successo dopo che tutti i controlli sono stati superati. Per ulteriori informazioni, consulta [Come funzionano le condizioni dello stage?](concepts-how-it-works-conditions.md).
# DevOps esempio di pipeline
****Come esempio di DevOps pipeline, una pipeline a due stadi potrebbe avere uno stadio di origine chiamato Source e un secondo stadio chiamato Prod.**** In questo esempio, la pipeline aggiorna l'applicazione con le ultime modifiche e distribuisce continuamente il risultato più recente. Prima di distribuire l'applicazione più recente, la pipeline crea e verifica l'applicazione Web. In questo esempio, un gruppo di sviluppatori ha impostato un modello di infrastruttura e il codice sorgente per un'applicazione Web in un repository chiamato. GitHub MyRepository
![\[Una pipeline con fasi e azioni campione.\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/pipeline-elements-workflow-application.png)
Ad esempio, uno sviluppatore spinge una correzione alla pagina indice dell'applicazione Web e si verifica quanto segue:
1. Il codice sorgente dell'applicazione viene mantenuto in un repository configurato come azione GitHub sorgente nella pipeline. **Quando gli sviluppatori inviano i commit al repository, CodePipeline rilevano la modifica inviata e l'esecuzione della pipeline inizia dal Source Stage.**
1. L'azione GitHub source viene completata correttamente (ovvero, le ultime modifiche sono state scaricate e archiviate nel bucket di artefatti unico per quell'esecuzione). Gli *artefatti di output* prodotti dall'azione GitHub source, che sono i file dell'applicazione presenti nel repository, vengono quindi utilizzati come *artefatti di input* su cui lavorare le azioni nella fase successiva.
1. L'esecuzione della pipeline passa da **fase Source** a **fase Prod**. La prima azione in **Prod Stage** esegue un progetto di compilazione creato CodeBuild e configurato come azione di compilazione nella pipeline. L'attività di compilazione estrae un'immagine dell'ambiente di compilazione e crea l'applicazione Web in un contenitore virtuale.
1. L'azione successiva in **Prod Stage** è un progetto di unit test creato CodeBuild e configurato come azione di test nella pipeline.
1. Il codice unità testato viene successivamente elaborato da un'azione di distribuzione nella **fase Prod** che distribuisce l'applicazione in un ambiente di produzione. Una volta completata con successo l'azione di distribuzione, l'azione finale nella fase è un progetto di test di integrazione creato CodeBuild e configurato come azione di test nella pipeline. L'azione di test chiama gli script della shell che installano ed eseguono uno strumento di test, ad esempio un controllo dei collegamenti, nell'applicazione Web. Dopo il completamento con successo, l'output è un'applicazione web integrata e una serie di risultati dei test.
Gli sviluppatori possono aggiungere azioni alla pipeline che distribuiscono o testano ulteriormente l'applicazione dopo che è stata compilata e testata per ogni modifica.
Per ulteriori informazioni, consulta [Funzionamento delle esecuzioni pipeline](concepts-how-it-works.md).
# Funzionamento delle esecuzioni pipeline
Questa sezione fornisce una panoramica del modo in cui CodePipeline elabora una serie di modifiche. CodePipelinetiene traccia di ogni esecuzione della pipeline che inizia quando una pipeline viene avviata manualmente o viene apportata una modifica al codice sorgente. CodePipeline utilizza le seguenti modalità di esecuzione per gestire il modo in cui ogni esecuzione procede nella pipeline. Per ulteriori informazioni, consulta [Impostare o modificare la modalità di esecuzione della pipeline](execution-modes.md).
+ Modalità SOSTITUITA: un'esecuzione più recente può sostituire un'esecuzione precedente. Questa è l’impostazione predefinita.
+ Modalità CODA: le esecuzioni vengono elaborate una per una nell'ordine in cui sono messe in coda. Ciò richiede una pipeline di tipo V2.
+ Modalità PARALLEL: in modalità PARALLEL, le esecuzioni vengono eseguite simultaneamente e indipendentemente l'una dall'altra. Le esecuzioni non attendono il completamento di altre esecuzioni prima di iniziare o terminare. Ciò richiede una pipeline di tipo V2.
**Importante**
Per le pipeline in modalità PARALLEL, lo stage rollback non è disponibile. Analogamente, le condizioni di errore con un tipo di risultato di rollback non possono essere aggiunte a una pipeline in modalità PARALLEL.
## Come vengono avviate le esecuzioni pipeline
È possibile avviare un'esecuzione quando si modifica il codice sorgente o si avvia manualmente la pipeline. Puoi anche attivare un'esecuzione tramite una regola Amazon CloudWatch Events che pianifichi. Ad esempio, quando una modifica del codice sorgente viene inviata in un repository configurato come azione di origine della pipeline, la pipeline rileva la modifica e avvia un'esecuzione.
**Nota**
Se una pipeline contiene più operazioni di origine, vengono tutte eseguite nuovamente, anche se viene rilevata una modifica per una sola operazione di origine.
## Come vengono elaborate le revisioni dei sorgenti nelle esecuzioni della pipeline
Per ogni esecuzione della pipeline che inizia con modifiche al codice sorgente (revisioni del codice sorgente), le revisioni dei sorgenti vengono determinate come segue.
+ Per le pipeline con una CodeCommit fonte, l'HEAD viene clonato nel momento in cui viene CodePipeline inviato il commit. Ad esempio, viene inviato un commit, che avvia la pipeline per l'esecuzione 1. Nel momento in cui viene inviato un secondo commit, viene avviata la pipeline per l'esecuzione 2.
**Nota**
Per le pipeline in modalità PARALLEL con un' CodeCommit origine, indipendentemente dal commit che ha attivato l'esecuzione della pipeline, l'azione di origine clonerà sempre l'HEAD nel momento in cui viene avviato. Per ulteriori informazioni, consulta [CodeCommit oppure le revisioni dei sorgenti S3 in modalità PARALLEL potrebbero non corrispondere all'evento EventBridge](troubleshooting.md#troubleshooting-revisions-parallel).
+ Per le pipeline con un'origine S3, viene utilizzato l' EventBridge evento per l'aggiornamento del bucket S3. Ad esempio, l'evento viene generato quando un file viene aggiornato nel bucket di origine, che avvia la pipeline per l'esecuzione 1. Nel momento in cui viene effettuato l'evento per un secondo aggiornamento del bucket, viene avviata la pipeline per l'esecuzione 2.
**Nota**
Per le pipeline in modalità PARALLEL con una sorgente S3, indipendentemente dal tag di immagine che ha attivato l'esecuzione, l'azione source inizierà sempre con il tag di immagine più recente. Per ulteriori informazioni, consulta [CodeCommit oppure le revisioni dei sorgenti S3 in modalità PARALLEL potrebbero non corrispondere all'evento EventBridge](troubleshooting.md#troubleshooting-revisions-parallel).
+ Per le pipeline con un'origine di connessione, ad esempio verso Bitbucket, l'HEAD viene clonato nel CodePipeline momento in cui viene inviato il commit. Ad esempio, per una pipeline in modalità PARALLEL, viene inviato un commit, che avvia la pipeline per l'esecuzione 1, mentre la seconda esecuzione della pipeline utilizza il secondo commit.
## Come funzionano le sostituzioni dei sorgenti con il trasformatore di input EventBridge
È possibile utilizzare le sostituzioni per avviare una pipeline con un ID di revisione dell'origine specifico fornito per l'esecuzione della pipeline. Ad esempio, se desideri avviare una pipeline che elabori un ID di commit specifico dalla tua CodeCommit origine, puoi aggiungere l'ID di commit come override all'avvio della pipeline.
Esistono quattro tipi di revisione del codice sorgente per: `revisionType`
+ `COMMIT_ID`
+ `IMAGE_DIGEST`
+ `S3_OBJECT_VERSION_ID`
+ `S3_OBJECT_KEY`
**Nota**
Per i `IMAGE_DIGEST` tipi `COMMIT_ID` e i tipi di revisioni del codice sorgente, l'ID di revisione del codice sorgente si applica a tutto il contenuto del repository, in tutte le filiali.
**Nota**
Per i `S3_OBJECT_KEY` tipi `S3_OBJECT_VERSION_ID` e le revisioni dei sorgenti, entrambi i tipi possono essere utilizzati indipendentemente oppure possono essere usati insieme per sovrascrivere l'origine con un VersionID specifico. ObjectKey Perché`S3_OBJECT_KEY`, il parametro di configurazione `AllowOverrideForS3ObjectKey` deve essere impostato su. `true` Per ulteriori informazioni sui parametri di configurazione del codice sorgente S3, consulta[Parametri di configurazione](action-reference-S3.md#action-reference-S3-config).
È possibile specificare le sostituzioni della sorgente utilizzando il trasformatore di ingresso in. EventBridge Utilizzate il trasformatore di input per passare i dati in uno dei seguenti modi:
+ È possibile utilizzare il trasformatore di input per passare i dati come parametri JSON.
+ È possibile utilizzare il trasformatore di input per passare le variabili della pipeline.
Per esempi di come passare i dati come parametri JSON, vedi[Azioni e risorse relative ai sorgenti di Amazon ECR EventBridge](create-cwe-ecr-source.md), [Connessione ad azioni di origine di Amazon S3 che utilizzano e EventBridge AWS CloudTrail](create-cloudtrail-S3-source.md) per S3 e for. [CodeCommit azioni di origine e EventBridge](triggering.md) CodeCommit
## Come vengono interrotte le esecuzioni di pipeline
Per utilizzare la console per interrompere l'esecuzione di una pipeline, è possibile scegliere **Interrompi esecuzione** nella pagina di visualizzazione della pipeline, nella pagina della cronologia delle esecuzioni o nella pagina della cronologia dettagliata. Per utilizzare l'interfaccia della riga di comando per interrompere l'esecuzione di una pipeline, utilizzare il comando `stop-pipeline-execution`. Per ulteriori informazioni, consulta [Interrompere l'esecuzione di una pipeline in CodePipeline](pipelines-stop.md).
Esistono due modi per interrompere l'esecuzione di una pipeline:
+ **Interrompi e attendi:** tutte le esecuzioni di azioni in corso possono essere completate e le azioni successive non vengono avviate. L'esecuzione della pipeline non prosegue con le fasi successive. Non è possibile utilizzare questa opzione in un'esecuzione già in uno stato `Stopping`.
+ **Arresto e abbandono:** tutte le esecuzioni delle azioni in corso vengono abbandonate e non completate e le azioni successive non vengono avviate. L'esecuzione della pipeline non prosegue con le fasi successive. È possibile utilizzare questa opzione su un'esecuzione che è già in uno stato `Stopping`.
**Nota**
Questa opzione può portare ad attività non riuscite o fuori sequenza.
Ogni opzione si traduce in una sequenza diversa di fasi di esecuzione della pipeline e delle azioni, come segue.
**Opzione 1: Ferma e attendi**
Quando si sceglie di interrompere e attendere, l'esecuzione selezionata continua fino al completamento delle azioni in corso. Ad esempio, l'esecuzione della pipeline seguente è stata interrotta mentre l'azione di compilazione era in corso.
1. Nella visualizzazione pipeline, viene visualizzato il banner del messaggio di successo e l'azione di compilazione continua fino al completamento. Lo stato di esecuzione della pipeline è **In arresto**.
Nella visualizzazione cronologia, lo stato delle azioni in corso, ad esempio l'azione di compilazione, è **In corso** fino al completamento dell'azione di compilazione. Mentre le azioni sono in corso, lo stato di esecuzione della pipeline è **In arresto**.
1. L'esecuzione si interrompe al termine del processo di arresto. Se l'azione di compilazione viene completata correttamente, il relativo stato è **Eseguito correttamente** e l'esecuzione della pipeline mostra lo stato **Arrestato**. Le azioni successive non iniziano. Il pulsante **Riprova** è abilitato.
Nella visualizzazione cronologia, lo stato di esecuzione viene **Arrestato** dopo il completamento dell'azione in corso.
![\[Immagine che mostra la visualizzazione della cronologia in cui lo stato di esecuzione viene interrotto dopo il completamento dell'azione in corso\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/stop-exec-wait-hist-1.png)
**Opzione 2: fermarsi e abbandonare**
Quando si sceglie di interrompere e abbandonare, l'esecuzione selezionata non attende il completamento delle azioni in corso. Le azioni vengono abbandonate. Ad esempio, l'esecuzione della pipeline seguente è stata interrotta e abbandonata mentre l'azione di compilazione era in corso.
1. Nella visualizzazione della pipeline viene visualizzato il messaggio del banner di successo, l'azione di compilazione mostra lo stato **In corso** e l'esecuzione della pipeline mostra uno stato **In arresto**.
1. Dopo l'interruzione dell'esecuzione della pipeline, l'azione di compilazione mostra lo stato **Abbandonato** e l'esecuzione della pipeline mostra lo stato **Arrestato**. Le azioni successive non iniziano. Il pulsante **Riprova** è abilitato.
1. Nella visualizzazione cronologia, lo stato di esecuzione è **Arrestato**.
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/stop-exec-abandon-hist-1.png)
**Casi d'uso per arrestare l'esecuzione di una pipeline**
Si consiglia di utilizzare l'opzione di arresto e attesa per interrompere l'esecuzione di una pipeline. Questa opzione è più sicura perché evita possibili errori o out-of-sequence attività nella pipeline. Quando un'azione viene abbandonata in CodePipeline, il fornitore dell'azione continua tutte le attività correlate all'azione. Nel caso di un' CloudFormation azione, l'azione di distribuzione nella pipeline viene abbandonata, ma l'aggiornamento dello stack potrebbe continuare e causare un aggiornamento non riuscito.
Ad esempio di azioni abbandonate che possono comportare out-of-sequence attività, se stai distribuendo un file di grandi dimensioni (1 GB) tramite un'azione di distribuzione S3 e scegli di interrompere e abbandonare l'azione mentre la distribuzione è già in corso, l'azione viene abbandonata in Amazon S3 CodePipeline, ma continua in Amazon S3. Amazon S3 non riceve alcuna istruzione per annullare il caricamento. Successivamente, se si avvia una nuova esecuzione della pipeline con un file molto piccolo, ora sono in corso due distribuzioni. Poiché le dimensioni del file della nuova esecuzione sono ridotte, la nuova distribuzione viene completata mentre la precedente distribuzione è ancora in fase di caricamento. Al termine della precedente distribuzione, il nuovo file viene sovrascritto dal vecchio file.
Potresti voler utilizzare l'opzione stop and abbandon nel caso in cui tu abbia un'azione personalizzata. Ad esempio, puoi abbandonare un'azione personalizzata con un lavoro che non deve essere completato prima di iniziare una nuova esecuzione per la correzione di un bug.
## Come vengono elaborate le esecuzioni in modalità SOSTITUITA
La modalità predefinita per l'elaborazione delle esecuzioni è la modalità SOSTITUITA. Un'esecuzione consiste in un insieme di modifiche raccolte ed elaborate dall'esecuzione. Le pipeline possono elaborare più esecuzioni contemporaneamente. Ogni esecuzione viene eseguita separatamente attraverso la pipeline. La pipeline elabora ogni esecuzione in ordine e potrebbe sostituire un'esecuzione precedente con una successiva. Le seguenti regole vengono utilizzate per elaborare le esecuzioni in una pipeline per la modalità SOSTITUITA.
**Regola 1: Le fasi vengono bloccate quando viene elaborata un'esecuzione**
Poiché ogni fase può elaborare solo un'esecuzione alla volta, la fase viene bloccata mentre è in corso. Quando l'esecuzione completa una fase, passa alla fase successiva della pipeline.
![\[Immagine che mostra le fasi bloccate in corso\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/Promotion.png)
**Regola 2: le esecuzioni successive attendono lo sblocco dello fase**
Mentre una fase è bloccata, le esecuzioni in attesa sono tenute davanti alla fase bloccata. Tutte le operazioni configurate per una fase devono essere completate prima che fase sia considerata completata. Un errore comporta l’applicazione del lucchetto sulla fase. Quando un'esecuzione viene interrotta, l'esecuzione non continua in uno stage e lo stage viene sbloccato.
**Nota**
Prima di interrompere un'esecuzione, è consigliabile disabilitare la transizione davanti allo stage. In questo modo, quando lo stage viene sbloccato a causa dell'esecuzione interrotta, lo stage non accetta un'esecuzione successiva della pipeline.
![\[Immagine che mostra come l'esecuzione in attesa attende tra le fasi quando la Fase 2 è bloccata\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/Waiting.png)
**Regola 3: le esecuzioni in attesa vengono sostituite da esecuzioni più recenti**
Le esecuzioni vengono sostituite solo tra una fase e l'altra. Una fase bloccata contiene un'esecuzione all’inizio della fase in attesa del completamento della fase. Un'esecuzione più recente supera un'esecuzione in attesa e continua alla fase successiva non appena la fase viene sbloccata. L'esecuzione sostituita non continua. In questo esempio, l'esecuzione 2 è stata sostituita dall’esecuzione 3 in attesa della fase bloccata. L'esecuzione 3 entra nella fase successiva.
![\[Immagine che mostra come l'esecuzione in attesa viene sostituita dall'esecuzione 3\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/Batching.png)
Per ulteriori informazioni sulle considerazioni relative alla visualizzazione e al passaggio da una modalità di esecuzione all'altra, vedere. [Impostare o modificare la modalità di esecuzione della pipeline](execution-modes.md) Per ulteriori informazioni sulle quote con modalità di esecuzione, vedere. [Quote in AWS CodePipeline](limits.md)
## Come vengono elaborate le esecuzioni in modalità QUEUED
Per le pipeline in modalità QUEUED, le fasi sono bloccate durante l'elaborazione di un'esecuzione; tuttavia, le esecuzioni in attesa non superano le esecuzioni già iniziate.
Le esecuzioni in attesa si riuniscono nei punti di ingresso delle fasi bloccate nell'ordine in cui raggiungono la fase, formando una coda di esecuzioni in attesa. Con la modalità QUEUED, puoi avere più code nella stessa pipeline. Quando un'esecuzione in coda entra in una fase, questa viene bloccata e non possono entrare altre esecuzioni. Questo comportamento rimane lo stesso della modalità SUPERSEDED. Al termine dell'esecuzione, la fase viene sbloccata e pronta per l'esecuzione successiva.
Il diagramma seguente mostra come le fasi di una pipeline in modalità QUEUED elaborano le esecuzioni. Ad esempio, mentre la fase Source elabora l'esecuzione 5, le esecuzioni per 6 e 7 formano Queue \$11 e attendono al punto di ingresso dello stage. L'esecuzione successiva nella coda verrà elaborata dopo lo sblocco della fase.
![\[Un diagramma che mostra le esecuzioni in una pipeline impostata per la modalità QUEUED.\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/Queued-Execution-Mode.png)
Per ulteriori informazioni sulle considerazioni relative alla visualizzazione e al passaggio da una modalità di esecuzione all'altra, vedere. [Impostare o modificare la modalità di esecuzione della pipeline](execution-modes.md) Per ulteriori informazioni sulle quote con modalità di esecuzione, vedere. [Quote in AWS CodePipeline](limits.md)
## Come vengono elaborate le esecuzioni in modalità PARALLEL
Per le pipeline in modalità PARALLEL, le esecuzioni sono indipendenti l'una dall'altra e non attendono il completamento delle altre esecuzioni prima di iniziare. Non ci sono code. Per visualizzare le esecuzioni parallele nella pipeline, usa la visualizzazione della cronologia delle esecuzioni.
Utilizza la modalità PARALLEL in ambienti di sviluppo in cui ogni funzionalità ha il proprio ramo di funzionalità e viene distribuita su destinazioni non condivise da altri utenti.
Per ulteriori informazioni sulle considerazioni relative alla visualizzazione e al passaggio da una modalità di esecuzione all'altra, vedere. [Impostare o modificare la modalità di esecuzione della pipeline](execution-modes.md) Per ulteriori informazioni sulle quote con modalità di esecuzione, vedere. [Quote in AWS CodePipeline](limits.md)
## Gestione del flusso della pipeline
Il flusso delle esecuzioni di pipeline può essere controllato da:
+ Una *transizione*, che controlla il flusso delle esecuzioni nella fase. Le transizioni possono essere abilitate o disabilitate. Quando una transizione è disabilitata, le esecuzioni della pipeline non possono entrare nella fase. L'esecuzione della pipeline in attesa di entrare in una fase in cui la transizione è disabilitata viene chiamata esecuzione in entrata. Dopo aver abilitato la transizione, un'esecuzione in entrata passa allo stage e la blocca.
Analogamente alle esecuzioni in attesa di una fase bloccata, quando una transizione è disabilitata, l'esecuzione in attesa di entrare nella fase può comunque essere sostituita da una nuova esecuzione. Quando una transizione disabilitata viene riabilitata, l'esecuzione più recente, inclusa quella che ha sostituito le esecuzioni meno recenti mentre la transizione è stata disabilitata, entra nella fase.
+ Un'*azione di approvazione*, che impedisce a una pipeline di passare all'azione successiva fino a quando non viene concessa l'autorizzazione (ad esempio, tramite l'approvazione manuale da parte di un'identità autorizzata). È possibile utilizzare un'azione di approvazione quando si desidera controllare il momento in cui una pipeline passa a una fase finale di **produzione** ad esempio.
**Nota**
Una fase con un'azione di approvazione viene bloccata fino a quando l'azione di approvazione non viene approvata o rifiutata o è scaduta. Un'azione di approvazione scaduta viene elaborata allo stesso modo di un'azione non riuscita.
+ Un *errore*, quando un'azione in una fase non viene completata correttamente. La revisione non esegue la transizione all'operazione successiva nella fase o alla fase successiva nella pipeline. Si può verificare quanto segue:
+ Viene eseguito un tentativo di ripetizione della fase che contiene le operazioni non riuscite. Questo riprende l'esecuzione (riprova le azioni fallite e, se riescono, continua nella fase/pipeline).
+ Un'altra esecuzione entra nella fase fallita e sostituisce l'esecuzione non riuscita. A questo punto, l'esecuzione non riuscita non può essere ripetuta.
### Struttura consigliata per pipeline
Quando si decide come una modifica del codice deve fluire attraverso la pipeline, è meglio raggruppare le azioni correlate all'interno di una fase in modo che, quando la fase si blocca, tutte le azioni elaborino la stessa esecuzione. È possibile creare una fase per ogni ambiente applicativo o zona di disponibilità e così via. Regione AWS Una pipeline con troppe fasi (cioè troppo granulare) può consentire troppe modifiche simultanee, mentre una pipeline con molte azioni in una fase di grandi dimensioni (troppo grossolana) può richiedere troppo tempo per rilasciare una modifica.
Ad esempio, un'azione di test dopo un'azione di distribuzione nella stessa fase è garantita per testare la stessa modifica che è stata distribuita. In questo esempio, una modifica viene compilata, testata e distribuita in un ambiente test, quindi la modifica più recente dell'ambiente di test viene distribuita in un ambiente di produzione. Nell'esempio consigliato, l'ambiente Test e l'ambiente Prod sono fasi separate.
![\[Immagine che mostra due tipi di raggruppamento per le azioni in fasi, con l'opzione consigliata sulla sinistra\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/structure-example-recommended-notrecommended.png)
### Come funzionano le esecuzioni in entrata
Un'esecuzione in entrata è un'esecuzione in attesa che diventi disponibile una fase, una transizione o un'azione non disponibili prima di procedere. La fase, la transizione o l'azione successiva potrebbero non essere disponibili perché:
+ Un'altra esecuzione è già entrata nella fase successiva e l'ha bloccata.
+ La transizione per accedere alla fase successiva è disabilitata.
È possibile disabilitare una transizione per mantenere un'esecuzione in entrata se si desidera controllare se un'esecuzione corrente ha il tempo di essere completata nelle fasi successive o se si desidera interrompere tutte le azioni in un determinato momento. Per determinare se è in corso un'esecuzione in entrata, è possibile visualizzare la pipeline nella console o visualizzare l'output del comando. **get-pipeline-state**
Le esecuzioni in entrata funzionano in base alle seguenti considerazioni:
+ Non appena l'azione, la transizione o la fase bloccata diventano disponibili, l'esecuzione in entrata in corso entra nella fase e prosegue attraverso la pipeline.
+ Mentre l'esecuzione in entrata è in attesa, può essere interrotta manualmente. Un'esecuzione in entrata può avere uno stato `InProgress``Stopped`, o`Failed`.
+ Quando un'esecuzione in entrata è stata interrotta o non è riuscita, non può essere ritentata perché non ci sono azioni fallite da riprovare. Quando un'esecuzione in entrata è stata interrotta e la transizione è abilitata, l'esecuzione in entrata interrotta non prosegue nella fase.
È possibile visualizzare o interrompere un'esecuzione in entrata.
# Artefatti di input e output
CodePipeline si integra con gli strumenti di sviluppo per verificare le modifiche al codice e quindi creare e implementare in tutte le fasi del processo di distribuzione continua. Gli artefatti sono i file su cui agiscono le azioni della pipeline, ad esempio file o cartelle con codice dell'applicazione, file di pagine indice, script e così via. Ad esempio, l'artefatto dell'azione sorgente di Amazon S3 è un nome di file (o percorso del file) in cui vengono forniti i file di codice sorgente dell'applicazione per l'azione di origine della pipeline. I file vengono forniti come file ZIP, ad esempio il nome dell'artefatto di esempio seguente:. `SampleApp_Windows.zip` L'elemento di output per l'azione di origine, i file di codice sorgente dell'applicazione, è l'artefatto di output di quell'azione ed è l'artefatto di input per l'azione successiva, ad esempio un'azione di compilazione. Come altro esempio, un'azione di compilazione potrebbe eseguire comandi di compilazione che compilano il codice sorgente dell'applicazione per un artefatto di input, ovvero i file di codice sorgente dell'applicazione. Consulta la pagina di riferimento sulla configurazione dell'azione per un'azione specifica per i dettagli sui parametri degli artefatti, ad esempio per l'azione. [AWS CodeBuild riferimento all'azione di compilazione e test](action-reference-CodeBuild.md) CodeBuild
Le azioni utilizzano artefatti di input e output archiviati nel bucket di artefatti Amazon S3 che hai scelto al momento della creazione della pipeline. CodePipeline comprime e trasferisce i file per gli artefatti di input o output in base al tipo di azione nello stage.
**Nota**
Il bucket di artefatti non è lo stesso bucket utilizzato come posizione del file di origine per una pipeline in cui l'azione sorgente scelta è S3.
Esempio:
1. CodePipeline **attiva l'esecuzione della pipeline quando viene eseguito un commit nel repository di origine, fornendo l'artefatto di output (qualsiasi file da creare) dalla fase Source.**
1. L'artefatto di output (qualsiasi file da compilare) della fase precedente viene incluso come artefatto di input per la fase di **compilazione**. Un artefatto di output (l’applicazione di compilazione) dalla fase di **compilazione** può essere un'applicazione aggiornata o un'immagine Docker aggiornata compilata in un contenitore.
1. L'artefatto di output del passaggio precedente (l'applicazione creata) viene inserito come elemento di input nella fase di **distribuzione**, ad esempio negli ambienti di staging o di produzione in. Cloud AWS Puoi distribuire le applicazioni in un parco istanze di distribuzione oppure puoi distribuire le applicazioni basate su container alle attività in esecuzione nei cluster ECS.
Quando si crea o si modifica un'azione, si designano l'artefatto o gli artefatti di input e output per l'azione. Ad esempio, per una pipeline a due fasi con una fase di **origine** e **distribuzione**, in **Modifica azione, si sceglie il nome dell'artefatto dell'azione** di origine per l'artefatto di input per l'azione di distribuzione.
+ Quando usi la console per creare la tua prima pipeline, CodePipeline crea un bucket Amazon S3 nella Account AWS stessa Regione AWS e per archiviare gli elementi per tutte le pipeline. Ogni volta che usi la console per creare un'altra pipeline in quella regione, CodePipeline crea una cartella per quella pipeline nel bucket. Questa cartella viene utilizzata per archiviare artefatti della pipeline durante l'esecuzione del processo di rilascio automatico. Questo bucket è denominato codepipeline- *region* -*12345EXAMPLE*, dove si trova la AWS regione in cui *region* è stata creata la pipeline ed è un numero casuale di 12 cifre che assicura che il nome del bucket *12345EXAMPLE* sia univoco.
**Nota**
Se hai già un bucket che inizia con codepipeline- *region, nella regione* in cui stai creando la pipeline, lo utilizza come bucket predefinito. CodePipeline **Segue anche l'ordine lessicografico; ad esempio, codepipeline- region-abcexample viene scelto prima di codepipeline- region-defexample.**
CodePipeline tronca i nomi degli artefatti, il che può far apparire simili i nomi di alcuni bucket. Anche se il nome dell'artefatto sembra troncato, viene mappato al bucket degli artefatti in modo da non CodePipeline risentire degli artefatti con nomi troncati. La pipeline può funzionare normalmente. Questo non è un problema con la cartella o gli artefatti. I nomi di pipeline hanno un limite di 100 caratteri. Anche se il nome della cartella degli artefatti potrebbe sembrare accorciato, è ancora univoco per la pipeline.
Quando si crea o si modifica una pipeline, è necessario disporre di un bucket di artefatti nella pipeline Account AWS e Regione AWS di un bucket di artefatti per regione in cui si intende eseguire un'azione. Se utilizzi la console per creare una pipeline o delle operazioni tra regioni, i bucket di artefatti predefiniti vengono configurati da CodePipeline nelle regioni in cui disponi di operazioni.
Se usi il AWS CLI per creare una pipeline, puoi archiviare gli elementi di quella pipeline in qualsiasi bucket Amazon S3 purché il bucket si trovi nella stessa pipeline. Account AWS Regione AWS Puoi farlo se sei preoccupato di superare i limiti dei bucket Amazon S3 consentiti per il tuo account. Se utilizzi il AWS CLI per creare o modificare una pipeline e aggiungi un'azione interregionale (un'azione con un AWS provider in una regione diversa dalla tua pipeline), devi fornire un bucket di artefatti per ogni regione aggiuntiva in cui intendi eseguire un'azione.
+ Ogni operazione dispone di un tipo. A seconda del tipo, l'operazione potrebbe contenere uno o entrambi gli elementi seguenti:
+ Un artefatto di input, che è l'artefatto che viene consumato o elaborato durante l'esecuzione dell'operazione.
+ Un artefatto di output, che è l'output dell'operazione.
Ogni artefatto di output nella pipeline deve avere un nome univoco. Ogni artefatto di input per un'operazione deve corrispondere all'artefatto di output di un'operazione precedente nella pipeline, a prescindere che tale operazione sia immediatamente precedente a quella in una fase o che venga eseguita diverse fasi prima.
Un artefatto può essere elaborato da più azioni.
# Come funzionano le condizioni dello stage?
Per ogni condizione che specifica una regola, viene eseguita la regola. Se la condizione fallisce, viene attivato il risultato. Lo stage esegue il risultato specificato solo quando la condizione fallisce. Facoltativamente, come parte della regola, è possibile specificare anche quali risorse CodePipeline utilizzare in determinati casi. Ad esempio, la `CloudWatchAlarm` regola utilizzerà una risorsa di CloudWatch allarme per eseguire i controlli della condizione.
Una condizione può soddisfare più regole e ogni regola può specificare uno dei tre provider.
Il flusso di alto livello per la creazione di condizioni è il seguente.
1. Scegliete il tipo di condizione tra i tipi di condizioni disponibili in CodePipeline. Ad esempio, utilizzate il tipo di condizione On Success per impostare una fase in modo che, dopo il successo della fase, sia possibile utilizzare una serie di regole per eseguire i controlli prima di procedere.
1. Scegliete la regola. Ad esempio, la `CloudWatchAlarm` regola verificherà la presenza di allarmi e utilizza EB per verificare la presenza di una soglia di allarme preconfigurata. Se il controllo ha esito positivo e l'allarme è al di sotto della soglia, la fase può procedere.
1. Configura il risultato, ad esempio un rollback da utilizzare in caso di errore della regola.
Le condizioni vengono utilizzate per tipi specifici di espressioni e ognuna presenta opzioni specifiche per i risultati, disponibili come segue:
+ **Ingresso**: le condizioni per effettuare i controlli che, se soddisfatte, consentono l'accesso a una fase. Le regole si basano sulle seguenti opzioni di risultato: **Fail** o **Skip**
+ **In caso di fallimento**: le condizioni per effettuare i controlli della fase in caso di errore. Le regole vengono applicate con la seguente opzione di risultato: **Rollback**
+ **In caso di successo**: le condizioni per effettuare i controlli della fase in caso di esito positivo. **Le regole si basano sulle seguenti opzioni di risultato: **Rollback** o Fail**
Il diagramma seguente mostra un esempio di flusso per la condizione Entry, tipo in. CodePipeline Le condizioni rispondono alla domanda: Cosa dovrebbe succedere se la condizione non viene soddisfatta, ovvero se una regola fallisce? Nel flusso seguente, una condizione di ingresso è configurata con una LambdaInvoke regola e una `CloudWatchAlarm` regola. Se la regola fallisce, viene attivato il risultato configurato, ad esempio Fail.
![\[Un esempio del tipo di condizione Entry con due regole configurate, una LambdaInvoke regola e una CloudWatchAlarm regola.\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/conditions-overview-entry.png)
Il diagramma seguente mostra un esempio di flusso per il tipo di condizione On Failure. CodePipeline Le condizioni rispondono alla domanda: Cosa dovrebbe succedere se la condizione viene soddisfatta, vale a dire che tutte le regole hanno esito positivo? Nel flusso seguente, una condizione On Failure è configurata con una LambdaInvoke regola e una `CloudWatchAlarm` regola. Se la regola ha esito positivo, viene attivato il risultato configurato, ad esempio Fail.
![\[Un esempio del tipo di condizione On Failure con due regole configurate, una regola Lambda e una CloudWatchAlarm regola.\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/conditions-overview-onfailure.png)
Il diagramma seguente mostra un esempio di flusso per il tipo di condizione On Success in. CodePipeline Le condizioni rispondono alla domanda: Cosa dovrebbe succedere se la condizione viene soddisfatta, vale a dire che tutte le regole hanno esito positivo? Nel flusso seguente, una condizione On Success è configurata con una `LambdaInvoke` regola e una `CloudWatchAlarm` regola. Se la regola ha esito positivo, viene attivato il risultato configurato, ad esempio Fail.
![\[Un esempio del tipo di condizione On Success con due regole configurate, una regola Lambda e una CloudWatchAlarm regola.\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/conditions-overview-onsuccess.png)
## Regole per le condizioni dello stage
Quando si configurano le condizioni dello stadio, si effettua una selezione tra le regole predefinite e si specificano i risultati per la regola. Lo stato di una condizione sarà Fallito se una qualsiasi delle regole della condizione ha esito negativo e Riuscito se tutte le regole hanno esito positivo. Il modo in cui vengono soddisfatti i criteri per le condizioni di On Failure e On Success dipende dal tipo di regola.
Di seguito sono riportate le regole gestite che è possibile aggiungere alle condizioni dello stage.
+ Le condizioni possono utilizzare la regola **Commands** per specificare i comandi che soddisfano i criteri delle regole per le condizioni. Per ulteriori informazioni su questa regola, vedere[Comandi](rule-reference-Commands.md).
+ Le condizioni possono utilizzare la **AWS DeploymentWindow**regola per specificare i tempi di distribuzione approvati per consentire una distribuzione. I criteri per la regola verranno misurati con un'espressione cron fornita per una finestra di distribuzione. La regola ha esito positivo quando la data e l'ora nella finestra di distribuzione soddisfano i criteri nell'espressione cron per la regola. Per ulteriori informazioni su questa regola, vedere. [DeploymentWindow](rule-reference-DeploymentWindow.md)
+ Le condizioni possono utilizzare la regola **AWS Lambda** per verificare gli stati di errore restituiti dalle funzioni Lambda configurate. La regola viene soddisfatta quando il controllo riceve il risultato della funzione Lambda. Un errore della funzione Lambda soddisfa i criteri per le condizioni On Failure. Per ulteriori informazioni su questa regola, vedere[LambdaInvoke](rule-reference-LambdaInvoke.md).
+ Le condizioni possono utilizzare la **AWS CloudWatchAlarm**regola per verificare la presenza di allarmi configurati dagli CloudWatch eventi. La regola viene soddisfatta quando il controllo restituisce uno stato di allarme di OK, ALARM o INSUFF\$1DATA. Per le condizioni On Success, OK e INSUFFICIENT\$1DATA soddisfano i criteri. ALARM soddisfa i criteri per le condizioni On Failure. Per ulteriori informazioni su questa regola, vedere[CloudWatchAlarm](rule-reference-CloudWatchAlarm.md).
+ Le condizioni possono utilizzare la **VariableCheck**regola per creare una condizione in cui la variabile di output viene confrontata con un'espressione fornita. La regola supera il controllo quando il valore della variabile soddisfa i criteri della regola, ad esempio se il valore è uguale o maggiore di una variabile di output specificata. Per ulteriori informazioni su questa regola, vedere[VariableCheck](rule-reference-VariableCheck.md).
# Tipi di tubazioni
CodePipeline fornisce i seguenti tipi di tubazioni, che differiscono per caratteristiche e prezzo, in modo da poter adattare le caratteristiche e i costi della pipeline alle esigenze delle applicazioni.
+ Le pipeline di tipo V1 hanno una struttura JSON che contiene parametri standard di pipeline, stage e action.
+ Le pipeline di tipo V2 hanno la stessa struttura di quelle di tipo V1, oltre a parametri aggiuntivi per la sicurezza del rilascio e la configurazione dei trigger.
[Per informazioni sui prezzi di CodePipeline, vedi Prezzi.](https://aws.amazon.com/codepipeline/pricing/)
Consulta la [CodePipeline riferimento alla struttura della tubazione](reference-pipeline-structure.md) pagina per i dettagli sui parametri di ogni tipo di pipeline. Per informazioni sul tipo di tubazione da scegliere, consulta. [Quale tipo di pipeline è adatto a me?](pipeline-types-planning.md)
# Quale tipo di pipeline è adatto a me?
Il tipo di pipeline è determinato dall'insieme di caratteristiche e funzionalità supportate da ciascuna versione della pipeline.
Di seguito è riportato un riepilogo dei casi d'uso e delle caratteristiche disponibili per ogni tipo di pipeline.
****
| | Tipo V1 | Tipo V2 | Caratteristiche | | |
| --- | --- | --- | --- | --- | --- |
| Casi d’uso | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/pipeline-types-planning.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/pipeline-types-planning.html) |
| [Variabili a livello di azione](https://docs.aws.amazon.com/codepipeline/latest/userguide/reference-variables.html) | Supportata | Supportata |
| [modalità di esecuzione PARALLELA](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html#concepts-how-it-works-executions-parallel) | Non supportata | Supportata |
| [Variabili a livello di pipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-pipeline-variables.html) | Non supportata | Supportata |
| [modalità di esecuzione QUEUED](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html#concepts-how-it-works-executions-queued) | Non supportata | Supportata |
| [Rollback per le fasi della pipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/stage-rollback.html) | Non supportata | Supportata |
| [La revisione del codice sorgente sostituisce](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-trigger-source-overrides.html) | Non supportata | Supportata |
| [Condizioni dello stage](https://docs.aws.amazon.com/codepipeline/latest/userguide/stage-conditions.html) | Non supportata | Supportata |
| [Trigger e filtraggio di tag Git, richieste pull, rami o percorsi di file](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-filter.html) | Non supportata | Supportata |
| [L'azione Commands](https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-Commands.html) | Non supportata | Supportata |
| [Creazione di condizioni di ingresso con Skip result](https://docs.aws.amazon.com/codepipeline/latest/userguide/stage-conditions.html#stage-conditions-entry-skip) | Non supportata | Supportata |
| [Configura una fase per il nuovo tentativo automatico in caso di errore](https://docs.aws.amazon.com/codepipeline/latest/userguide/stage-retry.html#stage-retry-auto) | Non supportata | Supportata |
Per informazioni sui prezzi di CodePipeline, vedi [Prezzi](https://aws.amazon.com/codepipeline/pricing/).
Puoi creare ed eseguire uno script Python per aiutarti ad analizzare il costo potenziale dello spostamento di una pipeline di tipo V1 in una pipeline di tipo V2.
**Nota**
Lo script di esempio riportato di seguito è destinato esclusivamente a scopi dimostrativi e di valutazione. Non è uno strumento di preventivo e non garantisce il costo per l'uso effettivo di una pipeline di tipo V2 e non include le eventuali tasse applicabili. [Per informazioni sui prezzi di CodePipeline, vedi Prezzi.](https://aws.amazon.com/codepipeline/pricing/)
**Per creare ed eseguire uno script che consenta di valutare il costo dello spostamento di una pipeline di tipo V1 in una pipeline di tipo V2**
1. Scarica e installa python.
1. Apri una finestra del terminale. **Esegui il seguente comando per creare un nuovo script python chiamato PipelineCostAnalyzer .py.**
```
vi PipelineCostAnalyzer.py
```
1. Copia e incolla il codice seguente nello **PipelineCostAnalyzerscript.py.**
```
import boto3
import sys
import math
from datetime import datetime, timedelta, timezone
if len(sys.argv) < 3:
raise Exception("Please provide region name and pipeline name as arguments. Example usage: python PipelineCostAnalyzer.py us-east-1 MyPipeline")
session = boto3.Session(profile_name='default', region_name=sys.argv[1])
pipeline = sys.argv[2]
codepipeline = session.client('codepipeline')
def analyze_cost_in_v2(pipeline_name):
if codepipeline.get_pipeline(name=pipeline)['pipeline']['pipelineType'] == 'V2':
raise Exception("Provided pipeline is already of type V2.")
total_action_executions = 0
total_blling_action_executions = 0
total_action_execution_minutes = 0
cost = 0.0
hasNextToken = True
nextToken = ""
while hasNextToken:
if nextToken=="":
response = codepipeline.list_action_executions(pipelineName=pipeline_name)
else:
response = codepipeline.list_action_executions(pipelineName=pipeline_name, nextToken=nextToken)
if 'nextToken' in response:
nextToken = response['nextToken']
else:
hasNextToken= False
for action_execution in response['actionExecutionDetails']:
start_time = action_execution['startTime']
end_time = action_execution['lastUpdateTime']
if (start_time < (datetime.now(timezone.utc) - timedelta(days=30))):
hasNextToken= False
continue
total_action_executions += 1
if (action_execution['status'] in ['Succeeded', 'Failed', 'Stopped']):
action_owner = action_execution['input']['actionTypeId']['owner']
action_category = action_execution['input']['actionTypeId']['category']
if (action_owner == 'Custom' or (action_owner == 'AWS' and action_category == 'Approval')):
continue
total_blling_action_executions += 1
action_execution_minutes = (end_time - start_time).total_seconds()/60
action_execution_cost = math.ceil(action_execution_minutes) * 0.002
total_action_execution_minutes += action_execution_minutes
cost = round(cost + action_execution_cost, 2)
print ("{:<40}".format('Activity in last 30 days:'))
print ("| {:<40} | {:<10}".format('___________________________________', '__________________'))
print ("| {:<40} | {:<10}".format('Total action executions:', total_action_executions))
print ("| {:<40} | {:<10}".format('Total billing action executions:', total_blling_action_executions))
print ("| {:<40} | {:<10}".format('Total billing action execution minutes:', round(total_action_execution_minutes, 2)))
print ("| {:<40} | {:<10}".format('Cost of moving to V2 in $:', cost - 1))
analyze_cost_in_v2(pipeline)
```
1. Dal terminale o dal prompt dei comandi, modificate le directory in cui avete creato lo script dell'analizzatore.
Da quella directory, esegui il comando seguente, dove la *regione è la regione* Regione AWS in cui hai creato le pipeline V1 che desideri analizzare. Facoltativamente, puoi anche valutare una pipeline specifica fornendone il nome:
```
python3 PipelineCostAnalyzer.py region --pipelineName
```
**Ad esempio, esegui il comando seguente per eseguire lo script python denominato .py. PipelineCostAnalyzer** In questo esempio, la regione è. `us-west-2`
```
python3 PipelineCostAnalyzer.py us-west-2
```
**Nota**
Questo script analizzerà tutte le pipeline V1 nell'area specificata, a Regione AWS meno che non si specifichi un nome di pipeline specifico.
1. Nel seguente esempio di output dello script, possiamo vedere l'elenco delle esecuzioni di azioni, l'elenco delle esecuzioni di azioni idonee alla fatturazione, la durata totale di queste esecuzioni di azioni e il costo stimato di queste azioni eseguite in una pipeline V2.
```
Activity in last 30 days:
| ___________________________________ | __________________
| Total action executions: | 9
| Total billing action executions: | 9
| Total billing action execution minutes: | 5.59
| Cost of moving to V2 in $: | -0.76
```
In questo esempio, il valore negativo nell'ultima riga rappresenta l'importo stimato che potrebbe essere risparmiato passando a pipeline di tipo V2.
**Nota**
L'output dello script e gli esempi correlati che mostrano i costi e altre informazioni sono solo stime. Sono destinati esclusivamente a scopi dimostrativi e di valutazione e non garantiscono alcun risparmio effettivo. Per informazioni sui prezzi di CodePipeline, vedi [Prezzi](https://aws.amazon.com/codepipeline/pricing/).