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.
-
SUPERSEDEDmodalità: Un'esecuzione più recente può sostituire un'esecuzione precedente. Questa è l'impostazione predefinita.
-
QUEUEDmodalità: Le esecuzioni vengono elaborate una per una nell'ordine in cui sono messe in coda. Ciò richiede una pipeline di tipo V2.
-
PARALLELmodalità: In PARALLEL modalità, 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.
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 un CodeCommit codice sorgente, HEAD viene clonato da 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 PARALLEL modalità con un' CodeCommit origine, indipendentemente dal commit che ha attivato l'esecuzione della pipeline, l'azione di origine le clonerà sempre nel HEAD momento in cui viene avviata. Per ulteriori informazioni, consulta CodeCommit oppure le revisioni dei sorgenti S3 in modalità potrebbero non corrispondere all'evento PARALLEL 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 PARALLEL modalità con una fonte 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à potrebbero non corrispondere all'evento PARALLEL EventBridge .
-
Per le pipeline con un'origine di connessione, ad esempio verso Bitbucket, HEAD viene clonata da nel CodePipeline momento in cui viene inviato il commit. Ad esempio, per una pipeline in PARALLEL modalità, viene inviato un commit, che avvia la pipeline per l'esecuzione 1, mentre la seconda esecuzione della pipeline utilizza il secondo commit.
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 il CLI per interrompere l'esecuzione di una pipeline, si utilizza il comando. stop-pipeline-execution Per ulteriori informazioni, consulta Interrompere 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 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' AWS 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à SUPERSEDED
La modalità predefinita per l'elaborazione delle esecuzioni è SUPERSEDED mode. 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 for mode. 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. Impostare o modificare 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 QUEUED modalità, 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 QUEUED la modalità, 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 QUEUED modalità pipeline elaborano le esecuzioni. Ad esempio, mentre la fase Source elabora l'esecuzione 5, le esecuzioni per 6 e 7 formano Queue #1 e attendono al punto di ingresso dello stage. L'esecuzione successiva nella coda verrà elaborata dopo lo sblocco della fase.
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 Per ulteriori informazioni sulle quote con modalità di esecuzione, vedere. Quote in AWS CodePipeline
Come vengono elaborate le esecuzioni in modalità PARALLEL
Per le pipeline in PARALLEL modalità, 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.
Usa PARALLEL la modalità 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 Per ulteriori informazioni sulle quote con modalità di esecuzione, vedere. Quote in AWS CodePipeline
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.
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 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
InProgressStopped, 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 prosegue nella fase.
È possibile visualizzare o interrompere un'esecuzione in entrata.
