Panoramica della Delivery Pipeline classica

IBM Cloud® Continuous Delivery include la Delivery Pipeline classica per costruire, testare e distribuire in modo ripetibile con un intervento umano minimo. In una pipeline, le sequenze di fasi richiamano l'input ed eseguono i lavori, come le build, i test e le distribuzioni.

Puoi lavorare con le delivery pipeline Classic e Tekton utilizzando il browser o utilizzando i comandi della CLI IBM Cloud Developer Tools(ibmcloud dev). Puoi anche utilizzare le delivery pipeline Tekton utilizzando SDK e API HTTP della pipeline Tektono IBM Cloud Provider Terraform. Per ulteriori informazioni sulle pipeline di fornitura Tekton, vedi Utilizzo delle pipeline Tekton.

Le tue autorizzazioni per visualizzare, modificare o eseguire una pipeline sono basate sul controllo dell'accesso per la toolchain che gestisce la pipeline. Per ulteriori informazioni sul controllo dell'accesso per le toolchain, vedi Gestione dell'accesso alle toolchain nei gruppi di risorse.

Puoi specificare gli script da eseguire in molti dei tipi di lavoro forniti dalla pipeline, dandoti un controllo diretto su quello che viene eseguito dal lavoro. Tali script vengono eseguiti in un'immagine Docker che contiene diversi strumenti di sviluppo standard, compresi gli strumenti necessari per interagire con i runtime IBM Cloud. Per ulteriori informazioni su quello che l'immagine Docker standard contiene, vedi Risorse preinstallate. Se il tuo lavoro richiede degli strumenti di sviluppo che non sono disponibili nell'immagine standard, o se hai bisogno di versioni differenti di tali strumenti, puoi utilizzare un'immagine personalizzata. Per ulteriori informazioni sulle immagini personalizzate, vedi Utilizzo di immagini docker personalizzate.

Quando la pipeline esegue gli script, le proprietà che descrivono il contesto in cui il lavoro è in esecuzione vengono passate allo script utilizzando le variabili di ambiente. Ad esempio, l'URL del repository che è l'input alla fase, il nome della fase e il lavoro che si sta eseguendo, i parametri specificati dal tipo di lavoro e così via. Per visualizzare un elenco delle variabili di ambiente disponibili, vedi Risorse preinstallate.

Puoi definire le proprietà sia a livello di pipeline che a livello di fase. Le proprietà di pipeline vengono condivise in tutte le fasi e tutti i lavori in una pipeline. Le proprietà di fase sono univoche per una specifica fase e condivise in tutti i lavori in tale fase. Per ulteriori informazioni sulle proprietà, vedi Proprietà dell'ambiente (variabili di ambiente).

Fasi

Le fasi organizzano l'input e i lavori e come il tuo codice viene generato, distribuito e verificato. Le fasi accettano l'input dai repository di controllo dell'origine (repository SCM) o dai lavori di build in altre fasi. Per i repository SCM, l'input è il contenuto di uno specifico ramo nel repository; per i lavori di build, l'input consiste nelle risorse utente prodotte dal lavoro. Quando crei la tua prima fase, la scheda INPUT contiene le impostazioni predefinite.

Quando una fase viene eseguita, il suo input viene passato a ciascuno dei lavori in essa contenuti. A ogni lavoro viene assegnato un contenitore pulito in cui essere eseguito. Di conseguenza, i lavori all'interno di una fase non possono passarsi le risorse utente tra di loro. Per passare le risorse all'interno dei lavori, separa i lavori in due fasi e usa l'output dal lavoro nella prima fase come input alla seconda fase. Tutti i lavori di creazione possono essere passati come input a qualsiasi altro lavoro in un'altra fase. Per impostazione predefinita, l'output viene creato nella cartella ./. Se non desideri utilizzare l'output da un lavoro di creazione, configura una cartella come output e non inviare alcun output a tale cartella.

Analogamente a come puoi definire le proprietà della pipeline, puoi anche definire le proprietà di fase per l'utilizzo in tutti i lavori in una specifica fase. Ad esempio, puoi definire una proprietà TEST_URL che passa un URL ai lavori di distribuzione e test in una fase. Il lavoro di distribuzione esegue la distribuzione a tale URL e il lavoro di test esegue un test dell'applicazione in esecuzione a tale URL. Le proprietà di fase vengono passate anche agli script di lavoro utilizzando le variabili di ambiente. Se qualche proprietà è definita sia al livello di pipeline che al livello di fase, viene utilizzato il valore della proprietà di fase.

Per impostazione predefinita, in una fase le creazioni e le distribuzioni vengono eseguite automaticamente ogni volta che si distribuiscono delle modifiche al repository SCM di un progetto. Le fasi e i lavori vengono eseguiti serialmente; abilitano il controllo del flusso per il tuo lavoro. Ad esempio, puoi posizionare una fase di verifica prima di una fase di distribuzione. Se i test nella fase di test hanno esito negativo, la fase di distribuzione non viene eseguita.

La Delivery Pipeline utilizza i nodi di lavoro pubblici e privati per eseguire i lavori in una fase. Per impostazione predefinita, i lavori di pipeline vengono eseguiti utilizzando i nodi di lavoro pubblici sull'infrastruttura condivisa pubblica gestita da IBM.

In alcuni scenari, la tua Delivery Pipeline potrebbe richiedere 'accesso a risorse interne o in loco. In queste situazioni, puoi connetterti a, e integrare, un nodo di lavoro privato Delivery Pipeline per l'esecuzione sulla tua infrastruttura Kubernetes.

Potresti desiderare di avere maggiore controllo su una fase specifica. Se non desideri che una fase venga eseguita ogni volta che viene effettuata una modifica nel relativo input, puoi disabilitare tale funzionalità. Nella scheda INPUT, nella sezione Stage Trigger, fai clic su Run jobs only when this stage is run manually.

Ulteriori opzioni di trigger della fase sono disponibili per le fasi che utilizzano il tipo di input del repository Git. Ad esempio, puoi scegliere di eseguire i lavori automaticamente per gli eventi Git sul ramo scelto. Quando scegli questo tipo di trigger, devi selezionare uno o più dei seguenti tipi di evento:

When a commit is pushed viene attivato quando viene eseguito un push al ramo di repository selezionato.
When a pull/merge request is opened or updated viene attivato quando viene aperta o modificata una richiesta di pull o di unione.
When a pull/merge request is closed viene attivato quando viene chiusa una richiesta di pull o di unione, anche senza un commit associato.

Se selezioni la casella di spunta When a pull/merge request is opened or updated, lo stato della pipeline viene restituito al repository Git. Quando una richiesta di pull o di unione attiva la tua pipeline, nella pagina viene visualizzato un controllo dello stato inline. Un controllo dello stato viene visualizzato per ciascuna delle fasi eseguite nella tue pipeline e vengono forniti del collegamenti ai log e alla cronologia per ciascuna fase. Quando viene eseguito, il controllo dello stato viene aggiornato da pending (in sospeso) a successful (riuscito) o failed (non riuscito). Se la tua pipeline contiene più fasi, ciascuna fase notifica il suo stato nell'elenco di controllo.

Questo feedback dello stato è supportato anche dallo strumento GitLab Community Edition ospitato da IBM per le richieste di unione.

Puoi anche limitare l'unione in base ai risultati dei controlli dello stato utilizzando le regole di protezione dei rami Git. Dopo che una regola di protezione dei rami è stata creata, tutta l'unione viene bloccata finché tutti i controlli dello stato richiesti hanno esito positivo.

Richieste di pull Bitbucket Cloud

Bitbucket Cloud al momento non supporta i riferimenti di repository per le richieste di pull, che sono richieste dal servizio Continuous Delivery. Questa funzione consente alle richieste di pull di essere inviate al repository a cui vuoi accedere utilizzando i riferimenti nel seguente formato: refs/pull/123/…

È possibile recuperare e controllare localmente una richiesta di pull utilizzando l'URL del repo sorgente. Tuttavia, se il repository di origine è un repository biforcato privato, il servizio Continuous Delivery non dispone dell'accesso necessario per gestire le richieste di pull. Come soluzione temporanea a questa limitazione, devi fornire esplicitamente l'accesso necessario al repository biforcato nello script della pipeline.

Nel seguente script della pipeline bash di esempio, due utenti stanno utilizzando Bitbucket Cloud ed entrambi hanno una biforcazione privata al loro repository principale (bitbucket.org/userA/repo-forked-A and bitbucket.org/userB/repo-forked-B). Lo script è configurato per controllare la richiesta di pull quando un lavoro di build viene attivato da un evento di apertura o aggiornamento della richiesta di pull da uno dei due repository biforcati.

case "$BITBUCKET_PR_SOURCE_HOST" in       #BITBUCKET_PR_SOURCE_HOST is an environment exported by pipeline if job is triggered by a bitbucket pull request
  *userA*)                                #userA should be replaced to anything to identify a forked repo's url
    url="https://$username:$password@$BITBUCKET_PR_SOURCE_HOST"    #you need to provide username and password for repo-forked-A
    ;;
  *userB/repo-forked-B*)                  #userB/repo-forked-B should be replaced to anything to identify a forked repo's url
    url="https://$username1:password1@$BITBUCKET_PR_SOURCE_HOST"   #you need to provide username1 and password1 for repo-forked-B
    ;;
esac
git fetch $url $BITBUCKET_PR_SOURCE_BRANCH   #BITBUCKET_PR_SOURCE_BRANCH is an environment exported by pipeline if job is triggered by a bitbucket pull request
git checkout FETCH_HEAD

Fase di build

La fase di build specifica un tipo Builder per indicare come creare le risorse utente.

Molti dei campi disponibili nei lavori di build sono comuni in più tipi di Builder.

Sono disponibili i seguenti tipi di Builder:

Tipi di costruttori
Tipo di builder	Descrizione	Tipi di lavoro supportati
Semplice	Archivia l'input dello stage corrente senza modifiche per l'utilizzo da parte di stage futuri. In genere, questo tipo di costruttore è utile solo quando l'input dello stage proviene da un repository SCM.	Versione immagine pipeline: viene eseguito in un contenitore utilizzando un'immagine docker integrata che fornisce vari comandi integrati. Per adottare versioni più recenti di tali comandi, utilizzare una versione dell'immagine più recente.
Ant	Utilizza i file Ant Apache per gestire il job di generazione.	Versione immagine pipeline: viene eseguito in un contenitore utilizzando un'immagine docker integrata che fornisce vari comandi integrati. Per adottare versioni più recenti di tali comandi, utilizzare una nuova versione dell'immagine. Script di build: viene eseguito in una nuova shell Ubuntu ogni qualvolta il lavoro viene eseguito. Nel campo script, immettere uno script o gli script di riferimento memorizzati nel controllo origine del progetto. Directory di lavoro: Specifica la directory in cui viene eseguito lo script Directory di archiviazione del lavoro: Specifica la directory che contiene l'output del lavoro da archiviare per l'utilizzo da parte di uno stage successivo Abilita report di test: Selezionare questa casella di controllo per specificare che il lavoro di compilazione esegue test che producono file di risultati in formato JUnit XML. Un report basato sui file dei risultati viene visualizzato nella scheda Test della pagina Job Results. Se qualche test fallisce, il lavoro viene contrassegnato come fallito Abilita il rapporto sulla copertura del codice: Selezionare questa casella di controllo per visualizzare altri campi da utilizzare per il report sulla copertura del codice. È possibile specificare il runner di Coverage (come JaCoCo, e Cobertura), la posizione del file dei risultati di Coverage e la directory dei risultati di Coverage, rispetto alla directory di lavoro.
Container Registry	Costruisce immagini docker e le carica nel IBM Cloud Container Registry.	Versione immagine pipeline: viene eseguito in un contenitore utilizzando un'immagine docker integrata che fornisce vari comandi integrati. Per adottare versioni più recenti di tali comandi, utilizzare una nuova versione dell'immagine. Chiave API: la chiave API IBM Cloud da utilizzare per fornire le autorizzazioni alle risorse dell'account. Spazio dei nomiContainer Registry: lo spazio dei nomi in cui vuoi archiviare la tua immagine creata. Nome dell'immagineDocker: il nome dell'immagine che questo lavoro costruisce e carica nel IBM Cloud Container Registry Script di compilazione: Viene eseguito in una nuova shell Ubuntu ogni volta che il lavoro viene eseguito. Nel campo script, immettere uno script o gli script di riferimento memorizzati nel controllo origine del progetto. Directory di lavoro: Specifica la directory in cui viene eseguito lo script Directory di archiviazione del lavoro: Specifica la directory che contiene l'output del lavoro da archiviare per l'utilizzo da parte di uno stage successivo Abilita report di test: Selezionare questa casella di controllo per specificare che il lavoro di compilazione esegue test che producono file di risultati in formato JUnit XML. Un report basato sui file dei risultati viene visualizzato nella scheda Test della pagina Job Results. Se qualche test fallisce, il lavoro viene contrassegnato come fallito Abilita il rapporto sulla copertura del codice: Selezionare questa casella di controllo per visualizzare altri campi da utilizzare per il report sulla copertura del codice. È possibile specificare il runner di Coverage (come JaCoCo, e Cobertura), la posizione del file dei risultati di Coverage e la directory dei risultati di Coverage, rispetto alla directory di lavoro.
immagine Docker personalizzata	Crea utilizzando la tua immagine docker personalizzata con un controllo dettagliato sulle versioni del nodo, Java™o altri strumenti.	Nome dell'immagineDocker: il nome dell'immagine che questo lavoro costruisce e carica nel IBM Cloud Container Registry Script di build: viene eseguito in una nuova shell Ubuntu ogni qualvolta il lavoro viene eseguito. Nel campo script, immettere uno script o gli script di riferimento memorizzati nel controllo origine del progetto. Directory di archiviazione del lavoro: Specifica la directory che contiene l'output del lavoro da archiviare per l'utilizzo da parte di uno stage successivo Abilita report di test: Selezionare questa casella di controllo per specificare che il lavoro di compilazione esegue test che producono file di risultati in formato JUnit XML. Un report basato sui file dei risultati viene visualizzato nella scheda Test della pagina Job Results. Se qualche test fallisce, il lavoro viene contrassegnato come fallito Abilita il report sulla copertura del codice: Selezionare questa casella di controllo per visualizzare altri campi da utilizzare per il report sulla copertura del codice. È possibile specificare il runner di Coverage (come JaCoCo, e Cobertura), la posizione del file dei risultati di Coverage e la directory dei risultati di Coverage, rispetto alla directory di lavoro.
Gradle	Crea utilizzando Gradle.	Versione immagine pipeline: viene eseguito in un contenitore utilizzando un'immagine docker integrata, che fornisce diversi comandi integrati. Per adottare versioni più recenti di tali comandi, utilizzare una nuova versione dell'immagine. Script di build: viene eseguito in una nuova shell Ubuntu ogni qualvolta il lavoro viene eseguito. Nel campo script, immettere uno script o gli script di riferimento memorizzati nel controllo origine del progetto. Directory di lavoro: Specifica la directory in cui viene eseguito lo script Build archive directory- Specifica la directory che contiene l'output del lavoro da archiviare per l'utilizzo da parte di uno stage successivo Abilita report di test: Selezionare questa casella di controllo per specificare che il lavoro di compilazione esegue test che producono file di risultati in formato JUnit XML. Un report basato sui file dei risultati viene visualizzato nella scheda Test della pagina Job Results. Se qualche test fallisce, il lavoro viene contrassegnato come fallito Abilita il rapporto sulla copertura del codice: Selezionare questa casella di controllo per visualizzare altri campi da utilizzare per il report sulla copertura del codice. È possibile specificare il runner di Coverage (come JaCoCo, e Cobertura), la posizione del file dei risultati di Coverage e la directory dei risultati di Coverage, rispetto alla directory di lavoro.
Grunt	Crea utilizzando Grunt.	Versione immagine pipeline: viene eseguito in un contenitore utilizzando un'immagine docker integrata che fornisce vari comandi integrati. Per adottare versioni più recenti di tali comandi, utilizzare una nuova versione dell'immagine. Script di build: viene eseguito in una nuova shell Ubuntu ogni qualvolta il lavoro viene eseguito. Nel campo script, immettere uno script o gli script di riferimento memorizzati nel controllo origine del progetto. Directory di lavoro: Specifica la directory in cui viene eseguito lo script Directory di archiviazione del lavoro: Specifica la directory che contiene l'output del lavoro da archiviare per l'utilizzo da parte di uno stage successivo Abilita report di test: Selezionare questa casella di controllo per specificare che il lavoro di compilazione esegue test che producono file di risultati in formato JUnit XML. Un report basato sui file dei risultati viene visualizzato nella scheda Test della pagina Job Results. Se qualche test fallisce, il lavoro viene contrassegnato come fallito Abilita il rapporto sulla copertura del codice: Selezionare questa casella di controllo per visualizzare altri campi da utilizzare per il report sulla copertura del codice. È possibile specificare il runner di Coverage (come JaCoCo, e Cobertura), la posizione del file dei risultati di Coverage e la directory dei risultati di Coverage, rispetto alla directory di lavoro.
Maven	Crea utilizzando Apache Maven.	Versione immagine pipeline: viene eseguito in un contenitore utilizzando un'immagine docker integrata, che fornisce diversi comandi integrati. Per adottare versioni più recenti di tali comandi, utilizzare una nuova versione dell'immagine. Script di build: viene eseguito in una nuova shell Ubuntu ogni qualvolta il lavoro viene eseguito. Nel campo script, immettere uno script o gli script di riferimento memorizzati nel controllo origine del progetto. Directory di lavoro: Specifica la directory in cui viene eseguito lo script Directory di archiviazione del lavoro: Specifica la directory che contiene l'output del lavoro da archiviare per l'utilizzo da parte di uno stage successivo Abilita report di test: Selezionare questa casella di controllo per specificare che il lavoro di compilazione esegue test che producono file di risultati in formato JUnit XML. Un report basato sui file dei risultati viene visualizzato nella scheda Test della pagina Job Results. Se qualche test fallisce, il lavoro viene contrassegnato come fallito Abilita il rapporto sulla copertura del codice: Selezionare questa casella di controllo per visualizzare altri campi da utilizzare per il report sulla copertura del codice. È possibile specificare il runner di Coverage (come JaCoCo, e Cobertura), la posizione del file dei risultati di Coverage e la directory dei risultati di Coverage, rispetto alla directory di lavoro.
npm	Installa le dipendenze con il gestore pacchetti Node.	Versione immagine pipeline: viene eseguito in un contenitore utilizzando un'immagine docker integrata, che fornisce diversi comandi integrati. Per adottare versioni più recenti di tali comandi, utilizzare una nuova versione dell'immagine. Script di build: viene eseguito in una nuova shell Ubuntu ogni qualvolta il lavoro viene eseguito. Nel campo script, immettere uno script o gli script di riferimento memorizzati nel controllo origine del progetto. Directory di lavoro: Specifica la directory in cui viene eseguito lo script Directory di archiviazione del lavoro: Specifica la directory che contiene l'output del lavoro da archiviare per l'utilizzo da parte di uno stage successivo Abilita report di test: Selezionare questa casella di controllo per specificare che il lavoro di compilazione esegue test che producono file di risultati in formato JUnit XML. Un report basato sui file dei risultati viene visualizzato nella scheda Test della pagina Job Results. Se qualche test fallisce, il lavoro viene contrassegnato come fallito Abilita il rapporto sulla copertura del codice: Selezionare questa casella di controllo per visualizzare altri campi da utilizzare per il report sulla copertura del codice. È possibile specificare il runner di Coverage (come JaCoCo, e Cobertura), la posizione del file dei risultati di Coverage e la directory dei risultati di Coverage, rispetto alla directory di lavoro.
Script Shell	Esegue uno script shell UNIX, ad esempio Bash.	Versione immagine pipeline: viene eseguito in un contenitore utilizzando un'immagine docker integrata, che fornisce diversi comandi integrati. Per adottare versioni più recenti di tali comandi, utilizzare una nuova versione dell'immagine. Script di build: viene eseguito in una nuova shell Ubuntu ogni qualvolta il lavoro viene eseguito. Nel campo script, immettere uno script o gli script di riferimento memorizzati nel controllo origine del progetto. Directory di lavoro: Specifica la directory in cui viene eseguito lo script Directory di archiviazione del lavoro: Specifica la directory che contiene l'output del lavoro da archiviare per l'utilizzo da parte di uno stage successivo Abilita report di test: Selezionare questa casella di controllo per specificare che il lavoro di compilazione esegue test che producono file di risultati in formato JUnit XML. Un report basato sui file dei risultati viene visualizzato nella scheda Test della pagina Job Results. Se qualche test fallisce, il lavoro viene contrassegnato come fallito Abilita il rapporto sulla copertura del codice: Selezionare questa casella di controllo per visualizzare altri campi da utilizzare per il report sulla copertura del codice. È possibile specificare il runner di Coverage (come JaCoCo, e Cobertura), la posizione del file dei risultati di Coverage e la directory dei risultati di Coverage, rispetto alla directory di lavoro.
GradleArtifactory, Nexus o SonarQube)	Crea e distribuisce utilizzando Gradle con un repository Nexus o Artifactory. Gradle si integra anche con SonarQube.	Versione immagine pipeline: viene eseguito in un contenitore utilizzando un'immagine docker integrata, che fornisce diversi comandi integrati. Per adottare versioni più recenti di tali comandi, utilizzare una nuova versione dell'immagine. Istanza di integrazione strumento repository: il nome dell'istanza di integrazione strumento repository da utilizzare con questo lavoro di build. Tipo di integrazione dello strumento del repository: il tipo di integrazione dello strumento da cui ottenere informazioni Gradle. SonarQube: il nome dell'istanza di integrazione SonarQube da utilizzare con questo lavoro di build. Comando di creazione: il comando di creazione da eseguire ogni volta che viene eseguito il lavoro. Nel campo Script, immettere uno script o script di riferimento memorizzati nel controllo origine del progetto. Directory di lavoro: Specifica la directory in cui viene eseguito lo script Directory archivio di build: Specifica la directory che contiene l'output del lavoro da archiviare per essere utilizzato da uno stage successivo.
MavenArtifactory, Nexus o SonarQube)	Crea e distribuisce utilizzando Maven con un repository Nexus o Artifactory. Maven si integra anche con SonarQube.	Versione immagine pipeline: viene eseguito in un contenitore utilizzando un'immagine docker integrata, che fornisce diversi comandi integrati. Per adottare versioni più recenti di tali comandi, utilizzare una nuova versione dell'immagine. Istanza di integrazione dello strumento repository: nome dell'istanza di integrazione dello strumento repository da utilizzare con questo lavoro di build. Tipo di integrazione dello strumento repository: tipo di integrazione dello strumento da cui ottenere informazioni Gradle. SonarQube: nome dell'istanza di integrazione SonarQube da utilizzare con questo lavoro di build. Comando di creazione: comando di creazione da eseguire ogni volta che viene eseguito il processo. Nel campo script, immettere uno script o gli script di riferimento memorizzati nel controllo origine del progetto. Directory di lavoro: Specifica la directory in cui viene eseguito lo script Directory archivio di build: Specifica la directory che contiene l'output del lavoro da archiviare per essere utilizzato da uno stage successivo.
npmArtifactory o Nexus)	Crea utilizzando npm con un repository Nexus o Artifactory.	Versione immagine pipeline: viene eseguito in un contenitore utilizzando un'immagine docker integrata, che fornisce diversi comandi integrati. Per adottare versioni più recenti di tali comandi, utilizzare una nuova versione dell'immagine. Istanza di integrazione strumento repository: il nome dell'istanza di integrazione strumento repository da utilizzare con questo lavoro di build. Tipo di integrazione dello strumento del repository: il tipo di integrazione dello strumento da cui ottenere informazioni Gradle. SonarQube: il nome dell'istanza di integrazione SonarQube da utilizzare con questo lavoro di build. Comando di creazione: il comando di creazione da eseguire ogni volta che viene eseguito il lavoro. Nel campo Script, immettere uno script o script di riferimento memorizzati nel controllo origine del progetto. Incrementa versione modulo istantanea: supporta la fornitura continua incrementando la versione del modulo localmente in base al contenuto del file `package.json` e l'istantanea corrente riportata nel registro npm al momento della pubblicazione. Directory di lavoro: Specifica la directory in cui viene eseguito lo script Directory archivio di build: Specifica la directory che contiene l'output del lavoro da archiviare per essere utilizzato da uno stage successivo.

Fase di distribuzione

La fase di distribuzione specifica l'input da una fase di build. I lavori nella fase di distribuzione specificano un tipo Deployer. Sono disponibili i seguenti tipi Deployer:

Tipi di distributori
Tipo di distributore	Descrizione	Tipi di lavoro supportati
immagine Docker personalizzata	Viene distribuito utilizzando la tua immagine Docker personalizzata con un controllo dettagliato sulle versioni del nodo, Java™o altri strumenti.	Versione immagine pipeline: viene eseguito in un contenitore utilizzando un'immagine docker integrata che fornisce vari comandi integrati. Per adottare versioni più recenti di tali comandi, utilizzare una nuova versione dell'immagine. Chiave API: la chiave API IBM Cloud da utilizzare per fornire le autorizzazioni alle risorse dell'account. Nome dell'immagineDocker: il nome dell'immagine che questo lavoro costruisce e carica nel IBM Cloud Container Registry Script di distribuzione: comando di distribuzione da eseguire ogni volta che viene eseguito il lavoro. Nel campo script, immettere uno script o gli script di riferimento memorizzati nel controllo origine del progetto.
Kubernetes	Distribuisce le applicazioni ai cluster Kubernetes, come quelli trovati all'interno del Servizio contenitore IBM Cloud.	Versione immagine pipeline: viene eseguito in un contenitore utilizzando un'immagine docker integrata che fornisce vari comandi integrati. Per adottare versioni più recenti di tali comandi, utilizzare una nuova versione dell'immagine. Chiave API: la chiave API IBM Cloud da utilizzare per fornire le autorizzazioni alle risorse dell'account. Nome cluster: il nome del cluster Kubernetes ; la piattaforma su cui distribuisci i componenti Kubernetes. Script di distribuzione: comando di distribuzione da eseguire ogni volta che viene eseguito il lavoro. Nel campo script, immettere uno script o gli script di riferimento memorizzati nel controllo origine del progetto.

stage di test

La fase di test specifica la configurazione di test. I lavori nella fase di test specificano un tipo di Tester. Sono disponibili i seguenti tipi di tester:

Tipi di tester
Tipo di tester	Descrizione	Tipi di lavoro supportati
Semplice	Avvia un comando shell per eseguire i test automatizzati, con un report di test facoltativo.	Versione immagine pipeline: Non utilizzata. Script di verifica: il comando di verifica da eseguire ogni volta che viene eseguito il lavoro. Nel campo script, immettere uno script o gli script di riferimento memorizzati nel controllo origine del progetto. Directory di lavoro: la directory in cui viene eseguito lo script di test. Abilita report di test: non utilizzato. Abilita report di copertura del codice: non utilizzato.
immagine Docker personalizzata	Verifica utilizzando la tua immagine Docker personalizzata con un controllo dettagliato sulle versioni del nodo, Java™o altri strumenti.	Nome immagineDocker: il nome dell'immagine Docker con cui eseguire il lavoro. Per assicurarti che i tuoi lavori vengano eseguiti in un contesto pulito, eseguili in contenitori Docker. Script di verifica: il comando di verifica da eseguire ogni volta che viene eseguito il lavoro. Nel campo script, immettere uno script o gli script di riferimento memorizzati nel controllo origine del progetto. Directory di lavoro: la directory in cui viene eseguito lo script di test. Abilita report di test: non utilizzato. Abilita report di copertura del codice: non utilizzato.
Vulnerability Advisor	Esegue un controllo di conformità e vulnerabilità rispetto all'immagine specificata e visualizza i risultati. Se si riscontrano problemi, questa fase fallisce.	Versione immagine pipeline: viene eseguito in un contenitore utilizzando un'immagine docker integrata che fornisce vari comandi integrati. Per adottare versioni più recenti di tali comandi, utilizzare una nuova versione dell'immagine. Chiave API: la chiave API IBM Cloud da utilizzare per fornire le autorizzazioni alle risorse dell'account. Spazio dei nomiContainer Registry: lo spazio dei nomi in cui è memorizzata la tua immagine creata. Nome immagineDocker: il nome dell'immagine Docker con cui eseguire il lavoro. Per assicurarti che i tuoi lavori vengano eseguiti in un contesto pulito, eseguili in contenitori Docker. Tag dell'immagineDocker: Un tag per l'immagine Docker che viene visualizzato nel IBM Cloud Container Registry Script di verifica: il comando di verifica da eseguire ogni volta che viene eseguito il lavoro. Nel campo script, immettere uno script o gli script di riferimento memorizzati nel controllo origine del progetto. Directory di lavoro: la directory in cui viene eseguito lo script di test. Abilita report di test: non utilizzato. Abilita report di copertura del codice: non utilizzato.
Sauce Labs	Esegue test JavaScript, Node o Java™ utilizzando Sauce Labs.	Versione immagine pipeline: viene eseguito in un contenitore utilizzando un'immagine docker integrata che fornisce vari comandi integrati. Per adottare versioni più recenti di tali comandi, utilizzare una nuova versione dell'immagine. Istanza del servizio: selezionare un'istanza di configurazione o crearne una.

Tipi di lavoro obsoleti

Diversi tipi di lavoro, come il lavoro IBM Globalization Pipeline Build, il lavoro Space Shell Test e il lavoro DevOps Insights Gate Test sono deprecati. Sebbene questi tipi di lavoro siano obsoleti, è comunque possibile caricarli nella UI, con un indicatore che il tipo di lavoro è obsoleto. In alternativa, il lavoro potrebbe tornare a un altro tipo di lavoro ancora supportato, con una notifica di avvertenza.

Se è necessario utilizzare la configurazione da un tipo di lavoro obsoleto, utilizzare uno dei seguenti metodi per accedere alla configurazione della pipeline.

Utilizzare IBM Cloud Devtool:

ic dev pipeline-get 7325f511-492a-4c35-a388-5e499e65d6bb -output JSON

Utilizzare la Delivery Pipeline API:

curl --location --request GET 'https://devops-api.us-south.devops.cloud.ibm.com/v1/pipeline/pipelines/7325f511-492a-4c35-a388-5e499e65d6bb/stages' \
--header 'Authorization: Bearer <IAM Bearer token>

Dalla scheda Rete dell'IU Delivery Pipeline, filtra in base all'ID pipeline per individuare la pipeline che contiene i dati del tipo di lavoro obsoleti.

Chiavi API

Alcuni lavori standard della pipeline utilizzano IBM Cloud Per accedere ai servizi, come il deploy su Kubernetes. Il servizio IBM Cloud IAM (Identity and Access Management) fornisce due tipi di chiavi API:

chiavi API utente: queste chiavi API forniscono un accesso completo a tutti i servizi e a tutte le risorse a cui ha accesso l'utente.
chiavi API del servizio: puoi configurare le chiavi API del servizio per fornire un accesso specifico a vari servizi e a varie risorse.

Alcuni servizi non possono utilizzare le chiavi API dell'ID servizio. In tali casi, l'interfaccia utente della pipeline ti richiede di specificare una chiave API utente.

Poiché i lavori della pipeline eseguono script creati dagli utenti che potrebbero utilizzare chiavi API del servizio in modalità arbitrarie, la pipeline non può determinare la serie di limitazioni da applicare a una specifica chiave. In questi casi, se richiedi che la pipeline crei una chiave API, essa crea una chiave API utente. Per mantenere un elevato livello di sicurezza, utilizza invece una chiave API del servizio con l'accesso limitato esclusivamente ai servizi e alle risorse di cui hai bisogno nello script. In questo caso, devi creare la chiave API tu stesso. Per ulteriori informazioni sulla creazione di una chiave API, vedi Chiavi API IBM Cloud.

Lavori

Il lavoro è un'unità di esecuzione in una fase. Una fase può contenere più lavori e i lavori in una fase vengono eseguiti in sequenza. Per impostazione predefinita, se un lavoro ha esito negativo, il lavoro seguente nella fase non viene eseguito.

I lavori vengono eseguiti in directory di lavoro separate all'interno dei contenitori Docker che sono stati creati per ogni esecuzione della pipeline. Prima che un lavoro venga eseguito, la relativa directory di lavoro viene compilata con l'input definito al livello della fase. Ad esempio, puoi avere una fase che contiene un lavoro di verifica e un lavoro di distribuzione. Se installi le dipendenze su un lavoro, non sono disponibili per un altro lavoro. Tuttavia, se rendi le dipendenze disponibili nell'input della fase, sono disponibili per entrambi i lavori.

Con eccezione dei lavori di creazione di tipo semplice, quando configuri un lavoro, puoi includere gli script shell UNIX che includono i comandi di creazione, verifica o distribuzione. Poiché i lavori sono eseguiti in un contenitore ad hoc, le azioni di un contenitore non possono influenzare gli ambienti di esecuzione di altri lavori, anche se tali lavori sono parte della stessa fase.

Gli esempi di script di compilazione e distribuzione si trovano in https://github.com/open-toolchain/commons

In aggiunta, i lavori della pipeline possono eseguire solo i seguenti comandi come sudo:

/usr/sbin/service
/usr/bin/apt-get
/usr/bin/apt-key
/usr/bin/dpkg
/usr/bin/add-apt-repository
/opt/IBM/node-v0.10.40-linux-x64/npm
/opt/IBM/node-v0.12.7-linux-x64/npm
/opt/IBM/node-v4.2.2-linux-x64/npm
/usr/bin/Xvfb
/usr/bin/pip

Dopo l'esecuzione di un lavoro, il contenitore creato per esso viene eliminato. I risultati di un'esecuzione di un lavoro possono essere conservati, ma l'ambiente nel quale è stato eseguito non può esserlo.

I lavori possono essere eseguiti fino a un massimo di 60 minuti. Quando i lavori superano tale limite, vengono considerati con esito negativo. Se un lavoro sta per superare il limite, suddividilo in più lavori. Ad esempio, se un lavoro esegue tre attività, puoi suddividerlo in tre lavori: uno per ogni attività.

Per maggiori informazioni su come aggiungere un lavoro a una fase, consulta Aggiunta di un lavoro a una fase.

Lavori di creazione

I lavori di creazione compilano il tuo progetto durante la preparazione per la distribuzione. Essi generano delle risorse utente che possono essere inviate a una directory di archivio di creazione, sebbene per impostazione predefinita, le risorse utente vengono posizionate nella directory root del progetto.

I lavori che ricevono l'input dai lavori di creazione devono far riferimento alle risorse utente di creazione nella stessa struttura in cui sono state create. Ad esempio, se un lavoro di creazione archivia le risorse utente di creazione in una directory output, uno script di distribuzione deve fare riferimento alla directory output anziché alla directory root del progetto per distribuire il progetto compilato. Puoi specificare la directory di archivio immettendo il nome directory nel campo Build Archive Directory. Lasciando il campo vuoto, si archivierà la directory root.

Se utilizzi il tipo di builder Simple, il codice non viene compilato o creato; invece viene inserito in un pacchetto e reso disponibile per le fasi future.

Lavori di distribuzione

I lavori di distribuzione caricano il tuo progetto in IBM Cloud come un'applicazione e sono accessibili da un URL. Dopo che il progetto è stato distribuito, puoi trovare l'applicazione distribuita nel tuo dashboard IBM Cloud.

I lavori di distribuzione possono distribuire nuove applicazioni o aggiornare applicazioni esistenti. Anche se hai prima distribuito un'applicazione utilizzando un altro metodo, puoi aggiornare l'applicazione utilizzando un lavoro di distribuzione. Per aggiornare un'applicazione, nel lavoro di distribuzione, utilizza il nome dell'applicazione.

Puoi eseguire la distribuzione a uno o più regioni e servizi. Ad esempio, puoi impostare il tuo Delivery Pipeline per utilizzare uno o più servizi, eseguire verifiche in una regione e distribuire in produzione in più regioni.

Lavori di verifica

Se desideri richiedere che vengano rispettate le condizioni, includi i lavori di verifica prima o dopo i tuoi lavori di distribuzione o di creazione. Puoi personalizzare i lavori di verifica in modo che siano semplici o complessi a secondo dei tuoi bisogni. Ad esempio, puoi immettere un comando cURL e attendere una risposta particolare. Puoi anche eseguire una suite di verifiche dell'unità o di verifiche funzionali dell'esecuzione con servizi di verifica di terze parti, come ad esempio Sauce Labs.

Se le tue verifiche producono dei file dei risultati nel formato XML JUnit, viene visualizzato un report che si basa sui file dei risultati nella scheda Tests per ogni pagina del risultato della verifica. Se una verifica ha esito negativo, anche il lavoro ha esito negativo.

Proprietà dell'ambiente (variabili di ambiente)

Una serie di proprietà di ambiente predefinite fornisce l'accesso alle informazioni sull'ambiente di esecuzione del lavoro. Per un elenco completo delle proprietà dell'ambiente predefinite, vedi Risorse e proprietà dell'ambiente.

Puoi anche definire delle tue proprietà dell'ambiente. Ad esempio, puoi definire una proprietà API_KEY che passa una chiave API che viene utilizzata per accedere alle risorse IBM Cloud da tutti gli script nella pipeline.

Puoi aggiungere i seguenti tipi di proprietà:

Text: una chiave della proprietà con un valore a singola riga.
Text Area: una chiave della proprietà con un valore a più righe. È disponibile anche una versione base64 di ciascun valore della proprietà Text Area. Puoi accedere a questa versione utilizzando il nome della chiave della proprietà con un suffisso _base641 finale. Puoi decodificare la versione base64 di una proprietà Text Area eseguendo il comando echo immettendo echo "$(echo $multi_base64 | base64 -d)", dove multi è il nome della chiave della proprietà che hai definito e multi_base64 è la proprietà aggiuntiva fornita. L'immagine di base della pipeline contiene il supporto integrato per gestire la codifica multilinea in modo trasparente. Tuttavia, se utilizzi un'immagine personalizzata devi accodare la proprietà di suffisso _base64 per evitare problemi in cui il tuo valore viene troncato da una terminazione di riga.
Secure: una chiave della proprietà con un valore a singola riga che è protetta con una crittografia AES-128. Il valore viene visualizzato come degli asterischi.
Properties: un file nel repository del progetto. Questo file può contenere più proprietà. Ogni proprietà deve essere sulla propria riga. Per separare le coppie chiave - valore, utilizzare il segno uguale (=). Racchiudere tutti i valori stringa tra virgolette. Ad esempio, MY_STRING="SOME STRING VALUE".

Puoi esaminare le proprietà dell'ambiente per un lavoro della pipeline eseguendo il comando env nello script del lavoro.

Proprietà della pipeline

Per definire le proprietà della pipeline, dal menu overflow nella pagina Pipeline, seleziona Configure Pipeline.

di overflow della pipeline*Menu di overflow della

Dalla scheda ENVIRONMENT PROPERTIES nella pagina Pipeline configuration. imposta le proprietà dell'ambiente a livello della pipeline.

delle proprietà della conduttura*Pagina delle proprietà della

Proprietà della fase

Per definire le proprietà della fase, apri la pagina Stage configuration e fai clic sulla scheda ENVIRONMENT PROPERTIES.

Puoi definire una proprietà della fase utilizzando un valore iniziale (oppure un valore vuoto) e sovrascrivendo quindi il valore in un lavoro esportando una variabile di ambiente. Sovrascrivendo il valore iniziale, i lavori successivi nella fase possono vedere il nuovo valore. Ad esempio, è possibile includere il comando seguente per impostare la proprietà $API_KEY e renderla disponibile a un altro lavoro all'interno dello stage: export API_KEY=<insert API key here>

Proprietà calcolate

Puoi calcolare i valori delle proprietà di ambiente che sono condivisi nelle fasi creando un file build.properties mentre la fase è in esecuzione e lasciare quindi che la fase successiva esegua il file. Ad esempio, il tuo lavoro di build può includere il seguente comando nello script di build:

echo "IMAGE_NAME=${FULL_REPOSITORY_NAME}" >> $ARCHIVE_DIR/build.properties

Tutti i lavori iniziano eseguendo il file build.properties, se esiste.

Creazione e utilizzo di risorse utente

I lavori di build recuperano automaticamente il contenuto nella cartella corrente dove viene eseguito lo script utente. Se non ti serve tutto il contenuto del repository git per la successiva distribuzione, è preferibile che configuri una directory di output esplicita e che quindi copi o crei lì le risorse utente pertinenti. Gli script del lavoro vengono eseguiti nel risultato della build (directory di output).

I lavori di distribuzione che eseguono la distribuzione a IBM Cloud Kubernetes Service hanno bisogno di specificare la chiave API della piattaforma di un utente per cui tali lavori di autorità sono eseguiti, un Dockerfile e, facoltativamente, un grafico Helm.

Lo script del lavoro viene eseguito dopo che il lavoro ha eseguito l'accesso all'ambiente di destinazione utilizzando la chiave API della piattaforma assegnata ad esso (in modo che tu possa eseguire i comandi cf push o kubectl nello script).

Una pipeline di esempio

Una pipeline di esempio può contenere tre fasi:

Una fase di build che compila ed esegue i processi di creazione su un'applicazione.
Una fase di verifica che distribuisce un'istanza dell'applicazione e successivamente esegue le verifiche su di essa.
Una fase di produzione che distribuisce un'istanza di produzione dell'applicazione verificata.

Questa pipeline viene mostrata nel seguente diagramma concettuale:

Un diagramma concettuale delle fasi e dei lavori in una pipeline*Modello — di una

a tre fasi*

Le fasi ricevono i loro input dai repository e dai lavori di creazione e i lavori all'interno di una fase eseguono in sequenza e indipendentemente ogni lavoro. Nella pipeline di esempio, le fasi sono eseguite in sequenza, anche se le fasi di verifica e produzione prendono entrambe l'output della fase di build come proprio input.