Tipi di stato della pipeline

E'importante capire le condizioni di errore o di guasto per un pipeline di riferimento in determinati punti. Concettualmente, due diversi tipi di stato risultato da un'attività gestita in una pipeline di conformità:

• Stato di conformità: lo stato di passaggio o di errore di un controllo some o di una serie di controlli.
• Stato Pipeline: lo stato di successo o di guasto di un'esecuzione di attività stessa.

Se un test, una scansione o un controllo fallisce, non provoca l'interruzione o la arresto della pipeline stessa; l'attività che sta eseguendo il test è contrassegnata come verde.

Da un punto di vista di conformità, il risultato del test unitario non incide sulla distribuzione. È possibile distribuire artefatti con controlli non riusciti, ma il processo tiene traccia di tale attività. Il flusso di conformità non ti blocca dal rilascio di un fix quando si verifica un outage. Ad esempio, una corsa verde per un'attività di test dell'unità che ha trovato dei crash test significa che The task ran successfully and found the following issues.

Se un'attività fallisce con uno stato rosso, si verifica perché la pipeline non può, o non deve, continuare. Le condizioni di esempio per l'errore includono:

• Errori in un'attività o in pipeline.
• Qualcosa è successo che significa che non ha senso continuare a correre il gasdotto.

Ad esempio, se una build di artefatto non riesce nella continua integrazione, rompe lo scopo del processo di integrazione continua stesso.

Per mantenere lo stato della pipeline finale in sincronizzazione con i risultati di conformità, un'attività alla fine della pipeline controlla i risultati di conformità e imposta lo stato di esecuzione della pipeline a red o green.

Pipeline di richiesta pull

La pipeline di richiesta pull esegue controlli di stato di conformità pre - impostati su una richiesta di pull per il repository di applicazione (app) specificato (repo). Questi controlli di stato potrebbero impedire l'unione della richiesta di pull nel ramo attivo predefinito, di solito master, se i controlli hanno esito negativo. Aprire o aggiornare una richiesta di pull rispetto al ramo attivo predefinito per attivare l'esecuzione della pipeline di richiesta di pull. Gli utenti possono eseguire il proprio setup per la pipeline e i test in fasi personalizzate. Per ulteriori informazioni sulla pipeline di richiesta di pull, vedi Pull request pipeline.

Pipeline di integrazione continua

La pipeline di integrazione continua costruisce i manufatti distribuibili dall'applicazione (app) repository (repos). Prima di costruire artefatti, la pipeline controlla che il codice sia scansato e collaudato, nello stesso modo in cui vengono elaborate le richieste di pull. Gli artefatti costruiti vengono inoltre scansati per le vulnerabilità e firmati in pipeline prima di essere marcati pronti per il rilascio e la distribuzione nell'inventario. A differenza della pipeline di richiesta pull, la pipeline di integrazione continua raccoglie prove e manufatti di risultato su ogni fase della build, come test, scansione e firma. Questi dati correlano agli artefatti costruiti e possono essere rintracciati attraverso il processo di distribuzione e la gestione delle modifiche. Per ulteriori informazioni sulla pipeline di integrazione continua, consultare Continuous Integration pipeline.

Pipeline di distribuzione continua

La pipeline di distribuzione continua genera tutti i contenuti di riepilogo delle prove e della richiesta di modifica. La pipeline distribuisce i manufatti di build ad un ambiente specifico, come ad esempio la staging o il prod, e poi raccoglie, crea e carica tutti i file di log esistenti, le prove e gli artefatti all'armadietto delle prove. Per ulteriori informazioni sulla pipeline di distribuzione continua, consultare Continuous deployment pipeline.

Pipeline di conformità continua

La pipeline di conformità continua scandisce periodicamente gli artefatti distribuiti e i loro repository di origine per le vulnerabilità più recenti da quando gli artefatti sono stati distribuiti in produzione. La pipeline aiuta anche a tenere traccia degli scostamenti con la data di scadenza in modo automatico e fornisce la consapevolezza dell'applicazione. Per ulteriori informazioni, vedere Pipeline di conformità continua.

Workflow di inventario

Vedi Prova.

Vedere Inventario.

Gruppo di inventario

Lo stato corrente distribuito contiene il contenuto da distribuire in un ambiente. Ogni commit promosso nei rami di destinazione contiene l'ID di esecuzione della pipeline e l'ID della richiesta di modifica, come tag. Alcuni commit possono avere più tag, ad esempio quando viene eseguita nuovamente una distribuzione non riuscita. L'inventario memorizza ogni parte di informazioni per riprodurre le installazioni.

Uso dei tag

• latest: Tag lo stato corrente, correttamente distribuito e concluso dell'inventario su un ramo.
• pipeline run id: indica lo stato dell'inventario più recente nel ramo, con l'ID di esecuzione della pipeline o il numero di build della distribuzione effettiva. È possibile utilizzare queste informazioni per fare riferimento all'hash del punto di inventario effettivo nella cronologia del ramo in modo che quando vengono attivate le distribuzioni parallele si eviti la sovrapposizione del contenuto dell'inventario.
• change request id: facoltativo. Contrassegna lo stato corrente. Gli ID richiesta di modifica vengono rappresentati e tracciati cronologicamente nell'inventario.

Destinazione singola - configurazione di più regioni

La configurazione di una singola regione di destinazione multipla è un'iterazione su questo modello in cui vengono introdotti più tag latest per un singolo ambiente di destinazione. Questo modello consente a più pipeline continue di lavorare sullo stesso obiettivo per diversi tipi di casi di utilizzo.

Ad esempio, è possibile utilizzare lo stesso ambiente di destinazione per più regioni (come us-south e eu-de) nell'ambiente di destinazione della produzione e nel ramo dell'inventario.

Per specificare la region di distribuzione mediante la pipeline di distribuzione continua, utilizzare il parametro region. Per ulteriori informazioni su questo parametro, vedi Parametri della pipeline di distribuzione continua.

I team non hanno bisogno di impostare un ramo diverso per ogni regione, come us-south-prod e eu-de-prod, ed eseguire la promozione in modo ridondante. Specificare invece queste destinazioni aggiuntive per lo stesso ramo di inventario e quindi utilizzarle come tag Git.

In questa configurazione, il ramo prod ha più tag latest sullo stesso ramo, ad esempio us-south_prod_latest e eu-de_prod_latest, e ogni pipeline di distribuzione continua responsabile per ogni regione può utilizzare tali tag per la distribuzione.

Scenario di esempio

Una serie di modifiche che possono essere distribuite ovunque, potrebbe essere rilasciata prima in una singola regione. Puoi quindi distribuire gradualmente questa serie di modifiche ad altre regioni utilizzando le pipeline di distribuzione continua che puntano a tali regioni.