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à.
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 Imposta o modifica la modalità di esecuzione della pipeline.
-
Modalità SOSTITUITA: un'esecuzione più recente può superare una precedente. Questa è l’impostazione predefinita.
-
Modalità QUEUED: le esecuzioni vengono elaborate una per una nell'ordine in cui vengono messe in coda. Ciò richiede una pipeline di tipo V2.
-
Modalità PARALLELA: in modalità PARALLELA, le esecuzioni vengono eseguite simultaneamente e indipendentemente l'una dall'altra. Le esecuzioni non attendono il completamento delle altre esecuzioni prima di iniziare o terminare. Ciò richiede una pipeline di tipo V2.
Importante
Per le pipeline in modalità PARALLELA, 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à PARALLELA.
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 pianificata. 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 delle pipeline
Per ogni esecuzione della pipeline che inizia con le modifiche al codice sorgente (revisioni del codice sorgente), le revisioni dei sorgenti vengono determinate come segue.
-
Per le pipeline con un CodeCommit sorgente, 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, questo avvia la pipeline per l'esecuzione 2.
Nota
Per le pipeline in modalità PARALLELA con un' CodeCommit origine, indipendentemente dal commit che ha attivato l'esecuzione della pipeline, l'azione source clonerà sempre l'HEAD nel momento in cui viene avviata. Per ulteriori informazioni, consulta CodeCommit oppure le revisioni dei sorgenti S3 in modalità PARALLELA potrebbero non corrispondere all'evento EventBridge.
-
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à PARALLELA con un sorgente S3, indipendentemente dal tag image che ha attivato l'esecuzione, l'azione source inizierà sempre con l'ultimo tag di immagine. Per ulteriori informazioni, consulta CodeCommit oppure le revisioni dei sorgenti S3 in modalità PARALLELA potrebbero non corrispondere all'evento EventBridge.
-
Per le pipeline con un'origine di connessioni, come 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, e la seconda esecuzione della pipeline utilizza il secondo commit.
Come funzionano le sostituzioni dei sorgenti con il trasformatore di ingresso EventBridge
È possibile utilizzare le sostituzioni per avviare una pipeline con un ID di revisione di origine specifico fornito per l'esecuzione della pipeline. Ad esempio, se desideri avviare una pipeline che elaborerà un ID di commit specifico dalla tua CodeCommit fonte, 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 di origine, l'ID di revisione di origine si applica a tutti i contenuti del repository, in tutte le filiali.
Nota
Per i S3_OBJECT_KEY tipi S3_OBJECT_VERSION_ID e i tipi di revisioni del codice sorgente, entrambi i tipi possono essere utilizzati indipendentemente oppure possono essere usati insieme per sovrascrivere l'origine con un versionID specifico. ObjectKey PerS3_OBJECT_KEY, il parametro di configurazione AllowOverrideForS3ObjectKey deve essere impostato su. true Per ulteriori informazioni sui parametri di configurazione del codice sorgente S3, vedereParametri di configurazione.
È possibile specificare le sostituzioni delle sorgenti utilizzando il trasformatore di ingresso in. EventBridge Utilizzate il trasformatore di ingresso per passare i dati in uno dei seguenti modi:
-
È possibile utilizzare il trasformatore di ingresso per passare i dati come parametri JSON.
-
È possibile utilizzare il trasformatore di ingresso per passare le variabili della pipeline.
Per esempi di trasmissione dei dati come parametri JSON, vedeteAzioni e risorse di origine di Amazon ECR EventBridge, Connessione ad Amazon S3: azioni di origine che utilizzano e EventBridge AWS CloudTrail for S3 e for. CodeCommit azioni di origine e EventBridge 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 Interrompi l'esecuzione di una pipeline in CodePipeline.
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.
-
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.
-
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.
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.
-
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.
-
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.
-
Nella visualizzazione cronologia, lo stato di esecuzione è Arrestato.
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 attività non riuscite o fuori sequenza nella pipeline. Quando un'azione viene abbandonata nel 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 comportare un aggiornamento non riuscito.
Come esempio di azioni abbandonate che possono comportare attività fuori sequenza, se si sta distribuendo un file di grandi dimensioni (1 GB) tramite un'azione di distribuzione S3 e si sceglie di interrompere e abbandonare l'azione mentre la distribuzione è già in corso, l'azione viene abbandonata in Amazon S3 CodePipeline, ma continua. 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à SUPERSEDED. 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à SUPERSEDED.
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.
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.
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.
Prima: l'esecuzione 2 attende tra le fasi mentre l'esecuzione 3 entra nella fase 1. Dopo: l'esecuzione 3 esce dalla fase 1. L'esecuzione 2 è sostituita dall'esecuzione 3.
Per ulteriori informazioni sulle considerazioni relative alla visualizzazione e al passaggio da una modalità di esecuzione all'altra, vedere. Imposta o modifica la modalità di esecuzione della pipeline Per ulteriori informazioni sulle quote con modalità di esecuzione, vedere. Quote in AWS CodePipeline
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à avviate.
Le esecuzioni in attesa si riuniscono nei punti di ingresso alle 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 nessun'altra esecuzione può entrare. Questo comportamento rimane lo stesso della modalità SUPERSEDED. Quando l'esecuzione termina la fase, la fase viene sbloccata e pronta per l'esecuzione successiva.
Il diagramma seguente mostra come vengono eseguite le fasi di una pipeline in modalità QUEUED. Ad esempio, mentre la fase Source elabora l'esecuzione 5, le esecuzioni per 6 e 7 formano la Coda #1 e attendono al punto di ingresso della fase. La successiva esecuzione in coda verrà elaborata dopo lo sblocco dello stage.
Per ulteriori informazioni sulle considerazioni relative alla visualizzazione e al passaggio da una modalità di esecuzione all'altra, vedere. Imposta o modifica la modalità di esecuzione della pipeline Per ulteriori informazioni sulle quote con modalità di esecuzione, vedere. Quote in AWS CodePipeline
Come vengono elaborate le esecuzioni in modalità PARALLELA
Per le pipeline in modalità PARALLELA, le esecuzioni sono indipendenti l'una dall'altra e non devono attendere il completamento delle altre esecuzioni prima di iniziare. Non ci sono code. Per visualizzare le esecuzioni parallele nella pipeline, utilizzate la visualizzazione della cronologia delle esecuzioni.
Usa la modalità PARALLEL negli ambienti di sviluppo in cui ogni funzionalità ha un 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. Imposta o modifica la modalità di esecuzione della pipeline Per ulteriori informazioni sulle quote con modalità di esecuzione, vedere. Quote in AWS CodePipeline
Gestione del flusso di 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 è chiamata esecuzione in entrata. Dopo aver abilitato la transizione, un'esecuzione in entrata entra nella fase 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. Questa operazione riprende l'esecuzione (riprova le azioni non riuscite e, in caso di esito positivo, continua). stage/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 Regione AWS, o zona di disponibilità e così via. 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.
Sinistra: operazioni correlate di test, distribuzione e approvazione raggruppate insieme (scelta consigliata). Destra: operazioni correlate in fasi separate (scelta non consigliata).
Come funzionano le esecuzioni in entrata
Un'esecuzione in entrata è un'esecuzione in attesa della disponibilità di una fase, transizione o azione non disponibile prima di procedere. La fase, la transizione o l'azione successiva potrebbe non essere disponibile perché:
-
Un'altra esecuzione è già entrata nella fase successiva e l'ha bloccata.
-
La transizione per accedere alla fase successiva è disabilitata.
È possibile disattivare una transizione per bloccare 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 è presente un'esecuzione in entrata, è possibile visualizzare la pipeline nella console o visualizzare l'output del comando. get-pipeline-state
Le esecuzioni in entrata si basano sulle seguenti considerazioni:
-
Non appena l'azione, la transizione o la fase bloccata diventa disponibile, l'esecuzione in entrata in corso entra in fase e continua attraverso la pipeline.
-
Mentre l'esecuzione in entrata è in attesa, può essere interrotta manualmente. Un'esecuzione in entrata può avere uno stato
InProgress,Stopped, oFailed. -
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 continua nella fase.
È possibile visualizzare o interrompere un'esecuzione in entrata.
