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à.

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 Ecco alcuni concetti da conoscere durante l'uso. CodePipeline

Per un esempio di DevOps pipeline, vediDevOps esempio di pipeline.

I seguenti termini vengono utilizzati in CodePipeline:

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 artefattidell'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.

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 sonosource,build,test, deployapproval, e. invoke Per un elenco dei provider di operazioni, consulta Fornitori di azioni validi in CodePipeline .

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.

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

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, vedere. PipelineExecution

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:

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.

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 SUPERSEDED modalità, 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. Altre modalità di esecuzione disponibili sono la QUEUED modalità PARALLEL or.

Per ulteriori informazioni sulle modalità di esecuzione e sulle fasi bloccate, vedereCome vengono elaborate le esecuzioni in modalità SUPERSEDED.

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, vedereCome vengono elaborate le esecuzioni in modalità SUPERSEDED.

Gli stati validi per gli stadi sono InProgressStopping,Stopped,Succeeded, eFailed. È possibile riprovare una fase fallita a meno che la fase fallita non sia riprovabile. Per ulteriori informazioni, vedere. StageExecution È 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 inConfigurazione del rollback dello stage. Per ulteriori informazioni, vedere RollbackStage.

Esecuzioni di operazioni

Un'esecuzione di un'operazione è il processo di completamento di un'operazione configurata che opera su artefatti 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 sonoInProgress, AbandonedSucceeded, oFailed. Per ulteriori informazioni, vedere ActionExecution.

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

Per informazioni sui modelli di integrazione supportati per i tipi di azione in CodePipeline, consultaRiferimento al modello di integrazione.

Per informazioni su come i provider di terze parti possono configurare e gestire i tipi di azione in CodePipeline, vedereLavorare con i tipi di azione.

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.

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.

Trigger

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 è ARN stata aggiunta la 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. 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

Variables

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.

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?.

Regolamento

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?.