Übersicht über die klassische Delivery Pipeline

DevOps Insights wird am 31. August 2026 das Ende des Betriebs erreichen und eingestellt werden. Continuous Delivery wird am 12. Februar 2027 in den folgenden Regionen eingestellt: au-syd, ca-tor, us-east. Code Risk Analyzer wird zu diesem Zeitpunkt ebenfalls in allen Regionen eingestellt. Wenn diese Funktionen in einer Region nicht aktiv genutzt werden, können sie in dieser Region vorzeitig eingestellt werden, sodass keine neuen Instanzen mehr akzeptiert werden. Weitere Informationen

IBM Cloud® Continuous Delivery enthält die klassische Delivery Pipeline, die reproduzierbare Builds, Tests und Bereitstellungen ermöglicht und nur geringe manuelle Eingriffe erfordert. In einer Pipeline rufen Abfolgen von Phasen Eingabe- und Ausgabejobs wie Builds, Tests und Bereitstellungen ab.

Sie können sowohl mit Classic- als auch mit Tekton-Bereitstellungspipelines arbeiten, indem Sie den Browser oder die IBM Cloud Developer Tools CLI-Befehle(ibmcloud dev). Sie können auch mit Tekton-Bereitstellungspipelines arbeiten, indem Sie die Tekton-Pipeline-API HTTP und SDKs oder den IBM Cloud Terraform-Provider verwenden. Weitere Informationen zu Tekton-Bereitstellungspipelines finden Sie unter Arbeiten mit Tekton-Pipelines.

Ihre Berechtigungen zum Anzeigen, Ändern oder Ausführen einer Pipeline basieren auf der Zugriffssteuerung für die Toolchain, die Eigner der Pipeline ist. Weitere Informationen zur Zugriffssteuerung für Toolchains finden Sie unter Zugriff auf Toolchains in Ressourcengruppen verwalten.

Sie können die Scripts angeben, die in einer Vielzahl von Jobtypen ausgeführt werden sollen, die von der Pipeline bereitgestellt werden; Sie können darüber steuern, was durch den Job ausgeführt wird. Diese Scripts werden in einem Docker-Image ausgeführt, das eine Reihe von Standardentwicklungstools enthält; dazu gehören Tools, die für die Interaktion mit den IBM Cloud-Laufzeiten erforderlich sind. Weitere Informationen darüber, was das Standard-Docker-Image enthält, finden Sie im Abschnitt Vorinstallierte Ressourcen. Wenn für Ihren Job Entwicklungstools erforderlich sind, die im Standardimage nicht verfügbar sind, oder Sie unterschiedliche Versionen dieser Tools benötigen, können Sie ein angepasstes Image verwenden. Weitere Informationen zu angepassten Images finden Sie im Abschnitt Mit benutzerdefinierten Docker-Images arbeiten.

Wenn die Pipeline Scripts ausführt, werden die Eigenschaften, die den Kontext beschreiben, in dem der Job ausgeführt wird, an das Script übergeben, und zwar mithilfe von Umgebungsvariablen. Beispiel: Die URL des Repositorys, das die Eingabe für die Phase ist, der Name der Phase und der Job, der ausgeführt wird, die Parameter, die durch den Jobtyp angegeben werden, usw. Informationen zum Anzeigen einer Liste der verfügbaren Umgebungsvariablen finden Sie unter Vorinstallierte Ressourcen.

Sie können Eigenschaften sowohl auf der Pipeline- als auch auf der Phase-Ebene definieren. Pipeline-Eigenschaften werden über alle Phasen und Jobs in einer Pipeline gemeinsam genutzt. Phase-Eigenschaften sind für eine bestimmte Phase eindeutig und werden von allen Jobs dieser Phase gemeinsam genutzt. Weitere Informationen zu Eigenschaften finden Sie unter Umgebungseigenschaften (Umgebungsvariablen).

Phasen

Phasen organisieren Eingabe- und Ausgabejobs während ein Build für den Code erstellt, dieser implementiert und getestet wird. Phasen akzeptieren Eingaben von den Quellcodeverwaltungsrepositorys (SCM-Repositorys) oder von Buildjobs in anderen Phasen. Bei SCM-Repositorys ist die Eingabe der Inhalt eines bestimmten Zweigs im Repository; bei Buildjobs handelt es sich bei der Eingabe um die Artefakte, die der Job produziert. Wenn Sie Ihre erste Phase erstellen, sind auf der Registerkarte EINGABE die Standardeinstellungen festgelegt.

Wenn eine Phase ausgeführt wird, wird die Eingabe der Phase an die einzelnen Jobs in der Phase übergeben. Jeder Job wird in einem bereinigten Container ausgeführt. Daher können die Jobs in einer Phase einander keine Artefakte übergeben. Um Artefakte in Jobs zu übergeben, unterteilen Sie die Jobs in zwei Phasen und verwenden Sie die Ausgabe des Jobs in der ersten Phase als Eingabe für die zweite Phase. Jeder beliebige Build-Job kann als Eingabe an jeden beliebigen anderen Job in einer anderen Phase übergeben werden. Standardmäßig wird die Ausgabe im Ordner ./ erstellt. Wenn keine Ausgabe für einen Build-Job erstellt werden soll, konfigurieren Sie einen Ordner als Ausgabe und senden Sie keine Ausgabe an diesen Ordner.

Ähnlich wie Sie Pipeline-Eigenschaften definieren können, können Sie auch Phase-Eigenschaften definieren, die in allen Jobs in einer bestimmten Phase verwendet werden sollen. Sie könnten zum Beispiel die Eigenschaft TEST_URL definieren, die eine URL an die Bereitstellungs- und Testjobs in einer Phase übergibt. Der Bereitstellungsjob führt an dieser URL eine Bereitstellung aus und der Testjob testet die App, die an dieser URL ausgeführt wird. Phase-Eigenschaften werden außerdem mithilfe von Umgebungsvariablen an Job-Scripts übergeben. Wenn dieselbe Eigenschaft sowohl auf der Pipeline- als auch auf der Phase-Ebene definiert ist, wird der Wert der Phase-Eigenschaft verwendet.

In einer Phase werden standardmäßig Builds und Bereitstellungen automatisch ausgeführt, sobald Änderungen an ein SCM-Repository des Projekts übermittelt werden. Phasen und Jobs werden seriell ausgeführt. Sie ermöglichen die Ablaufsteuerung für Ihre Arbeit. Sie können zum Beispiel eine Phase für den Test vor einer Phase für die Bereitstellung anordnen. Falls die Tests in der Phase für den Test fehlschlagen, wird die Phase für die Bereitstellung nicht ausgeführt.

Delivery Pipeline verwendet öffentliche und private Worker für die Ausführung der Jobs in einer Phase. Standardmäßig werden Pipelinejobs ausgeführt, indem öffentliche Worker in einer öffentlichen von IBM verwalteten und gemeinsam genutzten Infrastruktur verwendet werden.

In bestimmten Szenarios benötigt Delivery Pipeline möglicherweise Zugriff auf interne oder lokale Ressourcen. In diesen Situationen können Sie eine Verbindung zu einem privaten Delivery Pipeline-Worker herstellen und ihn für die Ausführung in Ihrer eigenen Kubernetes-Infrastruktur integrieren.

Möglicherweise wünschen Sie eine engere Steuerung einer bestimmten Phase. Wenn Sie nicht möchten, dass eine Phase immer dann ausgeführt wird, wenn eine Änderung bei ihrer Eingabe auftritt, können Sie diese Funktion inaktivieren. Klicken Sie auf der Registerkarte EINGABE im Abschnitt für Auslöser von Phasen auf Jobs nur ausführen, wenn diese Phase manuell ausgeführt wird.

Registerkarte „Eingabe“Registerkarte — „Eingabe“

Für Phasen, die den Eingabetyp 'Git-Repository' verwenden, stehen weitere Optionen für Auslöser für Phasen zur Verfügung. Sie können beispielsweise auswählen, dass Jobs automatisch für Git-Ereignisse in dem ausgewählten Zweig ausgeführt werden sollen. Wenn Sie diesen Auslösertyp auswählen, müssen Sie einen oder mehrere der folgenden Ereignistypen auswählen:

Wenn ein Commit mit einer Push-Operation übertragen wird löst aus, wenn eine Push-Operation in den ausgewählten Repositoryzweig durchgeführt wird.
Wenn eine Pull-/Zusammenführungsanforderung geöffnet oder aktualisiert wird löst aus, wenn eine Pull- oder eine Zusammenführungsanforderung geöffnet oder bearbeitet wird.
Wenn eine Pull-/Zusammenführungsanforderung geschlossen wird löst aus, wenn eine Pull- oder eine Zusammenführungsanforderung geschlossen wird, auch ohne zugehörige Commitoperation.

auf der Registerkarte Eingabe*

Wenn Sie das Kontrollkästchen Wenn eine Pull-/Zusammenführungsanforderung geöffnet oder aktualisiert wird auswählen, wird der Status der Pipeline an das Git-Repository zurückgegeben. Wenn eine Pull- oder eine Zusammenführungsanforderung Ihre Pipeline auslöst, wird auf der Seite eine integrierte Statusprüfung angezeigt. Für jede Phase, die in Ihrer Pipeline ausgeführt wird, wird eine Statusprüfung angezeigt, und es werden Links zu den Protokollen und der Historie für jede Phase bereitgestellt. Wenn die Statusprüfung ausgeführt wird, wird sie von 'anstehend' auf 'erfolgreich' oder 'fehlgeschlagen' aktualisiert. Wenn Ihre Pipeline mehrere Phasen enthält, wird der Status jeder Phase in der Prüfliste aufgelistet.

Diese Statusrückmeldung wird auch vom von IBM gehosteten GitLab Community Edition-Tool für Zusammenführungsanforderungen unterstützt.

Sie können auch das Zusammenführen basierend auf den Ergebnissen der Statusprüfungen durch Git-Zweigschutzregeln einschränken. Nachdem eine Zweigschutzregel erstellt wurde, wird jegliche Zusammenführung blockiert, bis alle erforderlichen Statusprüfungen erfolgreich sind.

Pull-Anforderungen für Bitbucket-Cloud

Bitbucket-Cloud unterstützt momentan keine Repositoryreferenzen für Pull-Anforderungen, die für den Continuous Delivery-Service erforderlich sind. Dieses Feature ermöglicht das Senden von Pull-Anforderungen an das Repository, auf das Sie zugreifen möchten, mithilfe von Referenzen im folgenden Format: refs/pull/123/…

Sie können einen Pull-Request lokal abrufen und auschecken, indem Sie das Quell-Repo URL verwenden. Wenn das Quellenrepository ein privates, verzweigtes Repo ist, hat der Continuous Delivery-Service nicht den erforderlichen Zugriff zur Verwaltung von Pull-Anforderungen. Um diese Einschränkung zu umgehen, müssen Sie den erforderlichen Zugriff für das verzweigte Repo explizit im Pipeline-Script erteilen.

Im folgenden Beispiel für ein Bash-Pipeline-Script verwenden zwei Benutzer die Bitbucket-Cloud und verfügen jeweils über eine private Verzweigung ihres Hauptrepositorys (bitbucket.org/userA/repo-forked-A und bitbucket.org/userB/repo-forked-B). Das Script prüft die Pull-Anforderung, wenn ein Buildjob von einem Ereignis 'Öffnen einer Pull-Anforderung' oder von einem Ereignis 'Aktualisierung eines der beiden verzweigten Repos' ausgelöst wird.

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

Build-Stage

Die Buildphase gibt einen Buildertyp an, um darzustellen, wie Artefakte erstellt werden sollen.

Viele Felder, die in Buildjobs verfügbar sind, treten buildertypunabhängig auf.

Folgende Buildertypen sind verfügbar:

Bauherren-Typen
Buildertyp	Beschreibung	Unterstützte Jobtypen
Einfach	Archiviert die Eingabe der aktuellen Phase ohne Änderung zur Verwendung in zukünftigen Phasen. Normalerweise ist dieser Buildertyp nur nützlich, wenn die Eingabe der Phase aus einem SCM-Repository stammt.	Pipeline-Image-Version: Wird in einem Container mithilfe eines integrieren Docker-Images ausgeführt, das verschiedene integrierte Befehle bereitstellt. Nutzen Sie eine neuere Imageversion, um neuere Versionen dieser Befehle zu verwenden.
Ant	Verwaltet den Buildjob mithilfe von Apache Ant-Dateien.	Pipeline-Image-Version: Wird in einem Container mithilfe eines integrieren Docker-Images ausgeführt, das verschiedene integrierte Befehle bereitstellt. Nutzen Sie eine neuere Imageversion, um neuere Versionen dieser Befehle zu verwenden. Build-Script: Wird in einer neuen Ubuntu-Shell ausgeführt, wann immer der Job ausgeführt wird. Geben Sie im Scriptfeld ein Script ein oder referenzieren Sie Scripts, die in der Quellcodeverwaltung Ihres Projekts gespeichert sind. Arbeitsverzeichnis: Gibt das Verzeichnis an, in dem das Script ausgeführt wird. Archivverzeichnis erstellen: Gibt das Verzeichnis an, das die zu archivierende Ausgabe des Jobs zur Verwendung durch eine nachfolgende Phase enthält. Testbericht aktivieren: Wählen Sie dieses Kontrollkästchen aus, um anzugeben, dass der Buildjob Tests ausführt, die Ergebnisdateien im JUnit XML-Format erzeugen. Auf der Registerkarte 'Tests' auf der Seite 'Jobergebnisse' wird ein Bericht auf der Basis der Ergebnisdateien angezeigt. Wenn ein Test fehlschlägt, wird der Job als fehlgeschlagen gekennzeichnet. Codeabdeckungsbericht aktivieren: Wählen Sie dieses Kontrollkästchen aus, um weitere Felder anzuzeigen, die Sie für den Codeabdeckungsbericht verwenden können. Sie können den Coverage-Runner (z. B. JaCoCo, und Cobertura), den Speicherort der Coverage-Ergebnisdatei sowie das Coverage-Ergebnisverzeichnis relativ zum Arbeitsverzeichnis angeben.
Container-Registry	Erstellt Docker-Images und lädt diese in die IBM Cloud Container Registry hoch.	Pipeline-Image-Version: Wird in einem Container mithilfe eines integrieren Docker-Images ausgeführt, das verschiedene integrierte Befehle bereitstellt. Nutzen Sie eine neuere Imageversion, um neuere Versionen dieser Befehle zu verwenden. API-Schlüssel: Der IBM Cloud-API-Schlüssel zum Bereitstellen von Berechtigungen für Kontoressourcen. Namensbereich Container Registry: Der Namensbereich, in dem Sie Ihr erstelltes Image speichern wollen. Name des Docker-Image: Der Name des Image, das dieser Job erstellt und in IBM Cloud Container Registry hochlädt. Build-Script: Wird in einer neuen Ubuntu-Shell ausgeführt, wann immer der Job ausgeführt wird. Geben Sie im Scriptfeld ein Script ein oder referenzieren Sie Scripts, die in der Quellcodeverwaltung Ihres Projekts gespeichert sind. Arbeitsverzeichnis: Gibt das Verzeichnis an, in dem das Script ausgeführt wird. Archivverzeichnis erstellen: Gibt das Verzeichnis an, das die zu archivierende Ausgabe des Jobs zur Verwendung durch eine nachfolgende Phase enthält. Testbericht aktivieren: Wählen Sie dieses Kontrollkästchen aus, um anzugeben, dass der Buildjob Tests ausführt, die Ergebnisdateien im JUnit XML-Format erzeugen. Auf der Registerkarte 'Tests' auf der Seite 'Jobergebnisse' wird ein Bericht auf der Basis der Ergebnisdateien angezeigt. Wenn ein Test fehlschlägt, wird der Job als fehlgeschlagen gekennzeichnet. Codeabdeckungsbericht aktivieren: Wählen Sie dieses Kontrollkästchen aus, um weitere Felder anzuzeigen, die Sie für den Codeabdeckungsbericht verwenden können. Sie können den Coverage-Runner (z. B. JaCoCo, und Cobertura), den Speicherort der Coverage-Ergebnisdatei sowie das Coverage-Ergebnisverzeichnis relativ zum Arbeitsverzeichnis angeben.
Angepasstes Docker-Image	Erstellt Builds unter Verwendung Ihres benutzerdefinierten Docker-Images mit detaillierter Kontrolle über die Versionen von Node, Java™ oder anderen Tools.	Name des Docker-Images: Der Name des Images, das durch diesen Job erstellt und in die IBM Cloud Container Registry hochgeladen wird. Build-Script: Wird in einer neuen Ubuntu-Shell ausgeführt, wann immer der Job ausgeführt wird. Geben Sie im Scriptfeld ein Script ein oder referenzieren Sie Scripts, die in der Quellcodeverwaltung Ihres Projekts gespeichert sind. Archivverzeichnis erstellen: Gibt das Verzeichnis an, das die Ausgabe des Jobs enthält, die zur Verwendung durch eine nachfolgende Phase archiviert werden soll. Testbericht aktivieren: Wählen Sie dieses Kontrollkästchen aus, um anzugeben, dass der Buildjob Tests ausführt, die Ergebnisdateien im JUnit XML-Format erzeugen. Auf der Registerkarte 'Tests' auf der Seite 'Jobergebnisse' wird ein Bericht auf der Basis der Ergebnisdateien angezeigt. Wenn ein Test fehlschlägt, wird der Job als fehlgeschlagen gekennzeichnet. Codeabdeckungsbericht aktivieren: Wählen Sie dieses Kontrollkästchen aus, um weitere Felder anzuzeigen, die Sie für den Codeabdeckungsbericht verwenden können. Sie können den Coverage-Runner (z. B. JaCoCo, und Cobertura), den Speicherort der Coverage-Ergebnisdatei sowie das Coverage-Ergebnisverzeichnis relativ zum Arbeitsverzeichnis angeben.
Gradle	Führt den Build mithilfe von Gradle durch.	Pipeline-Image-Version: Wird in einem Container mithilfe eines integrieren Docker-Images ausgeführt, das verschiedene integrierte Befehle bereitstellt. Nutzen Sie eine neuere Imageversion, um neuere Versionen dieser Befehle zu verwenden. Build-Script: Wird in einer neuen Ubuntu-Shell ausgeführt, wann immer der Job ausgeführt wird. Geben Sie im Scriptfeld ein Script ein oder referenzieren Sie Scripts, die in der Quellcodeverwaltung Ihres Projekts gespeichert sind. Arbeitsverzeichnis: Gibt das Verzeichnis an, in dem das Script ausgeführt wird. Archivverzeichnis erstellen - Gibt das Verzeichnis an, das die Ausgabe des Jobs enthält, die zur Verwendung durch eine nachfolgende Phase archiviert werden soll. Testbericht aktivieren: Wählen Sie dieses Kontrollkästchen aus, um anzugeben, dass der Buildjob Tests ausführt, die Ergebnisdateien im JUnit XML-Format erzeugen. Auf der Registerkarte 'Tests' auf der Seite 'Jobergebnisse' wird ein Bericht auf der Basis der Ergebnisdateien angezeigt. Wenn ein Test fehlschlägt, wird der Job als fehlgeschlagen gekennzeichnet. Codeabdeckungsbericht aktivieren: Wählen Sie dieses Kontrollkästchen aus, um weitere Felder anzuzeigen, die Sie für den Codeabdeckungsbericht verwenden können. Sie können den Coverage-Runner (z. B. JaCoCo, und Cobertura), den Speicherort der Coverage-Ergebnisdatei sowie das Coverage-Ergebnisverzeichnis relativ zum Arbeitsverzeichnis angeben.
Grunt	Führt den Build mithilfe von Grunt durch.	Pipeline-Image-Version: Wird in einem Container mithilfe eines integrieren Docker-Images ausgeführt, das verschiedene integrierte Befehle bereitstellt. Nutzen Sie eine neuere Imageversion, um neuere Versionen dieser Befehle zu verwenden. Build-Script: Wird in einer neuen Ubuntu-Shell ausgeführt, wann immer der Job ausgeführt wird. Geben Sie im Scriptfeld ein Script ein oder referenzieren Sie Scripts, die in der Quellcodeverwaltung Ihres Projekts gespeichert sind. Arbeitsverzeichnis: Gibt das Verzeichnis an, in dem das Script ausgeführt wird. Archivverzeichnis erstellen: Gibt das Verzeichnis an, das die zu archivierende Ausgabe des Jobs zur Verwendung durch eine nachfolgende Phase enthält. Testbericht aktivieren: Wählen Sie dieses Kontrollkästchen aus, um anzugeben, dass der Buildjob Tests ausführt, die Ergebnisdateien im JUnit XML-Format erzeugen. Auf der Registerkarte 'Tests' auf der Seite 'Jobergebnisse' wird ein Bericht auf der Basis der Ergebnisdateien angezeigt. Wenn ein Test fehlschlägt, wird der Job als fehlgeschlagen gekennzeichnet. Codeabdeckungsbericht aktivieren: Wählen Sie dieses Kontrollkästchen aus, um weitere Felder anzuzeigen, die Sie für den Codeabdeckungsbericht verwenden können. Sie können den Coverage-Runner (z. B. JaCoCo, und Cobertura), den Speicherort der Coverage-Ergebnisdatei sowie das Coverage-Ergebnisverzeichnis relativ zum Arbeitsverzeichnis angeben.
Maven	Führt den Build mithilfe von Apache Maven durch.	Pipeline-Image-Version: Wird in einem Container mithilfe eines integrieren Docker-Images ausgeführt, das verschiedene integrierte Befehle bereitstellt. Nutzen Sie eine neuere Imageversion, um neuere Versionen dieser Befehle zu verwenden. Build-Script: Wird in einer neuen Ubuntu-Shell ausgeführt, wann immer der Job ausgeführt wird. Geben Sie im Scriptfeld ein Script ein oder referenzieren Sie Scripts, die in der Quellcodeverwaltung Ihres Projekts gespeichert sind. Arbeitsverzeichnis: Gibt das Verzeichnis an, in dem das Script ausgeführt wird. Archivverzeichnis erstellen: Gibt das Verzeichnis an, das die zu archivierende Ausgabe des Jobs zur Verwendung durch eine nachfolgende Phase enthält. Testbericht aktivieren: Wählen Sie dieses Kontrollkästchen aus, um anzugeben, dass der Buildjob Tests ausführt, die Ergebnisdateien im JUnit XML-Format erzeugen. Auf der Registerkarte 'Tests' auf der Seite 'Jobergebnisse' wird ein Bericht auf der Basis der Ergebnisdateien angezeigt. Wenn ein Test fehlschlägt, wird der Job als fehlgeschlagen gekennzeichnet. Codeabdeckungsbericht aktivieren: Wählen Sie dieses Kontrollkästchen aus, um weitere Felder anzuzeigen, die Sie für den Codeabdeckungsbericht verwenden können. Sie können den Coverage-Runner (z. B. JaCoCo, und Cobertura), den Speicherort der Coverage-Ergebnisdatei sowie das Coverage-Ergebnisverzeichnis relativ zum Arbeitsverzeichnis angeben.
npm	Installiert Abhängigkeiten mit dem Node Package Manager.	Pipeline-Image-Version: Wird in einem Container mithilfe eines integrieren Docker-Images ausgeführt, das verschiedene integrierte Befehle bereitstellt. Nutzen Sie eine neuere Imageversion, um neuere Versionen dieser Befehle zu verwenden. Build-Script: Wird in einer neuen Ubuntu-Shell ausgeführt, wann immer der Job ausgeführt wird. Geben Sie im Scriptfeld ein Script ein oder referenzieren Sie Scripts, die in der Quellcodeverwaltung Ihres Projekts gespeichert sind. Arbeitsverzeichnis: Gibt das Verzeichnis an, in dem das Script ausgeführt wird. Archivverzeichnis erstellen: Gibt das Verzeichnis an, das die zu archivierende Ausgabe des Jobs zur Verwendung durch eine nachfolgende Phase enthält. Testbericht aktivieren: Wählen Sie dieses Kontrollkästchen aus, um anzugeben, dass der Buildjob Tests ausführt, die Ergebnisdateien im JUnit XML-Format erzeugen. Auf der Registerkarte 'Tests' auf der Seite 'Jobergebnisse' wird ein Bericht auf der Basis der Ergebnisdateien angezeigt. Wenn ein Test fehlschlägt, wird der Job als fehlgeschlagen gekennzeichnet. Codeabdeckungsbericht aktivieren: Wählen Sie dieses Kontrollkästchen aus, um weitere Felder anzuzeigen, die Sie für den Codeabdeckungsbericht verwenden können. Sie können den Coverage-Runner (z. B. JaCoCo, und Cobertura), den Speicherort der Coverage-Ergebnisdatei sowie das Coverage-Ergebnisverzeichnis relativ zum Arbeitsverzeichnis angeben.
Shell-Script	Führt ein UNIX-Shell-Script aus, z. B. Bash.	Pipeline-Image-Version: Wird in einem Container mithilfe eines integrieren Docker-Images ausgeführt, das verschiedene integrierte Befehle bereitstellt. Nutzen Sie eine neuere Imageversion, um neuere Versionen dieser Befehle zu verwenden. Build-Script: Wird in einer neuen Ubuntu-Shell ausgeführt, wann immer der Job ausgeführt wird. Geben Sie im Scriptfeld ein Script ein oder referenzieren Sie Scripts, die in der Quellcodeverwaltung Ihres Projekts gespeichert sind. Arbeitsverzeichnis: Gibt das Verzeichnis an, in dem das Script ausgeführt wird. Archivverzeichnis erstellen: Gibt das Verzeichnis an, das die zu archivierende Ausgabe des Jobs zur Verwendung durch eine nachfolgende Phase enthält. Testbericht aktivieren: Wählen Sie dieses Kontrollkästchen aus, um anzugeben, dass der Buildjob Tests ausführt, die Ergebnisdateien im JUnit XML-Format erzeugen. Auf der Registerkarte 'Tests' auf der Seite 'Jobergebnisse' wird ein Bericht auf der Basis der Ergebnisdateien angezeigt. Wenn ein Test fehlschlägt, wird der Job als fehlgeschlagen gekennzeichnet. Codeabdeckungsbericht aktivieren: Wählen Sie dieses Kontrollkästchen aus, um weitere Felder anzuzeigen, die Sie für den Codeabdeckungsbericht verwenden können. Sie können den Coverage-Runner (z. B. JaCoCo, und Cobertura), den Speicherort der Coverage-Ergebnisdatei sowie das Coverage-Ergebnisverzeichnis relativ zum Arbeitsverzeichnis angeben.
Gradle (Artifactory, Nexus oder SonarQube)	Führt den Build und die Bereitstellung mithilfe von Gradle mit einem Nexus- oder Artifactory-Repository durch. Gradle ermöglicht auch die Integration mit SonarQube.	Pipeline-Image-Version: Wird in einem Container mithilfe eines integrieren Docker-Images ausgeführt, das verschiedene integrierte Befehle bereitstellt. Nutzen Sie eine neuere Imageversion, um neuere Versionen dieser Befehle zu verwenden. Repository-Tool Integrationsinstanz: Der Name der Repository-Tool Integrationsinstanz, die mit diesem Buildjob verwendet wird. Integrationstyp des Repository-Tools: Der Typ der Toolintegration, von der Gradle-Informationen abgerufen werden sollen. SonarQube-Integrationsinstanz: Der Name der SonarQube-Integrationsinstanz, die bei diesem Buildjob verwendet werden soll. Buildbefehl: Der Buildbefehl, der bei jeder Ausführung des Jobs ausgeführt werden soll. Geben Sie im Feld Script ein Script ein oder referenzieren Sie Scripts, die in der Quellcodeverwaltung Ihres Projekts gespeichert sind. Arbeitsverzeichnis: Gibt das Verzeichnis an, in dem das Script ausgeführt wird. Archivverzeichnis erstellen: Gibt das Verzeichnis an, das die zu archivierende Ausgabe des Jobs zur Verwendung durch eine nachfolgende Phase enthält.
Maven (Artifactory, Nexus oder SonarQube)	Führt den Build und die Bereitstellung mithilfe von Maven mit einem Nexus- oder Artifactory-Repository durch. Maven ermöglicht auch die Integration mit SonarQube.	Pipeline-Image-Version: Wird in einem Container mithilfe eines integrieren Docker-Images ausgeführt, das verschiedene integrierte Befehle bereitstellt. Nutzen Sie eine neuere Imageversion, um neuere Versionen dieser Befehle zu verwenden. Repository-Tool Integrationsinstanz: Name der Repository-Tool Integrationsinstanz, die für diesen Build-Job verwendet werden soll. Integrationstyp des Repository-Tools: Typ der Toolintegration, von der Gradle-Informationen abgerufen werden sollen. SonarQube-Integrationsinstanz: Name der SonarQube-Integrationsinstanz, die mit diesem Buildjob verwendet werden soll. Buildbefehl: Buildbefehl, der bei jeder Ausführung des Jobs ausgeführt werden soll. Geben Sie im Scriptfeld ein Script ein oder referenzieren Sie Scripts, die in der Quellcodeverwaltung Ihres Projekts gespeichert sind. Arbeitsverzeichnis: Gibt das Verzeichnis an, in dem das Script ausgeführt wird. Archivverzeichnis erstellen: Gibt das Verzeichnis an, das die zu archivierende Ausgabe des Jobs zur Verwendung durch eine nachfolgende Phase enthält.
npm (Artifactory oder Nexus)	Führt den Build mithilfe von 'npm' mit einem Nexus- oder Artifactory-Repository durch.	Pipeline-Image-Version: Wird in einem Container mithilfe eines integrieren Docker-Images ausgeführt, das verschiedene integrierte Befehle bereitstellt. Nutzen Sie eine neuere Imageversion, um neuere Versionen dieser Befehle zu verwenden. Repository-Tool Integrationsinstanz: Der Name der Repository-Tool Integrationsinstanz, die mit diesem Buildjob verwendet wird. Integrationstyp des Repository-Tools: Der Typ der Toolintegration, von der Gradle-Informationen abgerufen werden sollen. SonarQube-Integrationsinstanz: Der Name der SonarQube-Integrationsinstanz, die bei diesem Buildjob verwendet werden soll. Buildbefehl: Der Buildbefehl, der bei jeder Ausführung des Jobs ausgeführt werden soll. Geben Sie im Feld Script ein Script ein oder referenzieren Sie Scripts, die in der Quellcodeverwaltung Ihres Projekts gespeichert sind. Snapshotmodulversion erhöhen: Unterstützt Continuous Delivery, indem die Modulversion lokal auf Basis des Inhalts der Datei `package.json` und des aktuell gemeldeten Snapshots in der npm-Registry beim Veröffentlichungsschritt erhöht wird. Arbeitsverzeichnis: Gibt das Verzeichnis an, in dem das Script ausgeführt wird. Archivverzeichnis erstellen: Gibt das Verzeichnis an, das die zu archivierende Ausgabe des Jobs zur Verwendung durch eine nachfolgende Phase enthält.

Bereitstellungsphase

Die Phase für die Bereitstellung gibt die Eingabe von einer Buildphase an. Die Jobs in der Phase für die Bereitstellung geben einen Deployer-Typ an. Folgende Deployer-Typen sind verfügbar:

Typen von Einsatzkräften
Bereitstellertyp	Beschreibung	Unterstützte Jobtypen
Angepasstes Docker-Image	Die Bereitstellung erfolgt mithilfe Ihres benutzerdefinierten Docker-Images mit detaillierter Kontrolle über die Versionen von Node, Java™ oder anderen Tools.	Pipeline-Image-Version: Wird in einem Container mithilfe eines integrieren Docker-Images ausgeführt, das verschiedene integrierte Befehle bereitstellt. Nutzen Sie eine neuere Imageversion, um neuere Versionen dieser Befehle zu verwenden. API-Schlüssel: Der IBM Cloud-API-Schlüssel zum Bereitstellen von Berechtigungen für Kontoressourcen. Docker Image-Name: Der Name des Images, das dieser Job erstellt und in die IBM Cloud Container Registry hochlädt. Bereitstellungsscript: Bereitstellungsbefehl, der bei Ausführung des Jobs ausgeführt werden soll. Geben Sie im Scriptfeld ein Script ein oder referenzieren Sie Scripts, die in der Quellcodeverwaltung Ihres Projekts gespeichert sind.
Kubernetes	Stellt Anwendungen in Kubernetes-Clustern bereit, z. B. im IBM Cloud Container Service.	Pipeline-Image-Version: Wird in einem Container mithilfe eines integrieren Docker-Images ausgeführt, das verschiedene integrierte Befehle bereitstellt. Nutzen Sie eine neuere Imageversion, um neuere Versionen dieser Befehle zu verwenden. API-Schlüssel: Der IBM Cloud-API-Schlüssel zum Bereitstellen von Berechtigungen für Kontoressourcen. Clustername: Der Name des Kubernetes-Clusters; die Plattform, auf der Sie Ihre Kubernetes-Komponenten bereitstellen. Bereitstellungsscript: Bereitstellungsbefehl, der bei Ausführung des Jobs ausgeführt werden soll. Geben Sie im Scriptfeld ein Script ein oder referenzieren Sie Scripts, die in der Quellcodeverwaltung Ihres Projekts gespeichert sind.

Testphase

In der Testphase wird die Testkonfiguration angegeben. Die Jobs in der Testphase geben einen Testertyp an. Die folgenden Testertypen sind verfügbar:

Tester-Typen
Testertyp	Beschreibung	Unterstützte Jobtypen
Einfach	Startet einen Shellbefehl zur Ausführung der automatisierten Tests mit einem optionalen Testbericht.	Pipeline-Image-Version: Nicht verwendet. Testscript: Testbefehl, der bei jeder Ausführung des Jobs ausgeführt werden soll. Geben Sie im Scriptfeld ein Script ein oder referenzieren Sie Scripts, die in der Quellcodeverwaltung Ihres Projekts gespeichert sind. Arbeitsverzeichnis: Das Verzeichnis, in dem das Testscript ausgeführt wird. Testbericht aktivieren: Nicht verwendet. Codeabdeckungsbericht aktivieren: Nicht verwendet.
Angepasstes Docker-Image	Führen Sie Tests mit Ihrem benutzerdefinierten Docker-Image durch und nutzen Sie dabei die detaillierte Kontrolle über die Versionen von Node, Java™ oder anderen Tools.	Name des Docker-Images: Der Name des Docker-Images, mit dem der Job ausgeführt werden soll. Führen Sie die Jobs in Docker-Containern aus, um sicherzustellen, dass sie in einem bereinigten Kontext ausgeführt werden. Testscript: Testbefehl, der bei jeder Ausführung des Jobs ausgeführt werden soll. Geben Sie im Scriptfeld ein Script ein oder referenzieren Sie Scripts, die in der Quellcodeverwaltung Ihres Projekts gespeichert sind. Arbeitsverzeichnis: Das Verzeichnis, in dem das Testscript ausgeführt wird. Testbericht aktivieren: Nicht verwendet. Codeabdeckungsbericht aktivieren: Nicht verwendet.
Vulnerability Advisor	Führt eine Compliance- und Sicherheitslückenprüfung für das angegebene Image durch und zeigt die Ergebnisse an. Wenn Probleme festgestellt werden, schlägt diese Phase fehl.	Pipeline-Image-Version: Wird in einem Container mithilfe eines integrieren Docker-Images ausgeführt, das verschiedene integrierte Befehle bereitstellt. Nutzen Sie eine neuere Imageversion, um neuere Versionen dieser Befehle zu verwenden. API-Schlüssel: Der IBM Cloud-API-Schlüssel zum Bereitstellen von Berechtigungen für Kontoressourcen. Namensbereich Container Registry: Der Namensbereich, in dem Ihr erstelltes Image gespeichert ist. Name des Docker-Image: Der Name des Docker-Images, mit dem der Job ausgeführt werden soll. Führen Sie die Jobs in Docker-Containern aus, um sicherzustellen, dass sie in einem bereinigten Kontext ausgeführt werden. Docker-Image-Tag: Ein Tag für das Docker-Images, das in der IBM Cloud Container Registry angezeigt wird. Testscript: Testbefehl, der bei jeder Ausführung des Jobs ausgeführt werden soll. Geben Sie im Scriptfeld ein Script ein oder referenzieren Sie Scripts, die in der Quellcodeverwaltung Ihres Projekts gespeichert sind. Arbeitsverzeichnis: Das Verzeichnis, in dem das Testscript ausgeführt wird. Testbericht aktivieren: Nicht verwendet. Codeabdeckungsbericht aktivieren: Nicht verwendet.
Sauce Labs	Führt Tests unter JavaScript,, Node oder Java™ mithilfe von Sauce Labs durch.	Pipeline-Image-Version: Wird in einem Container mithilfe eines integrieren Docker-Images ausgeführt, das verschiedene integrierte Befehle bereitstellt. Nutzen Sie eine neuere Imageversion, um neuere Versionen dieser Befehle zu verwenden. Serviceinstanz: Wählen Sie eine Konfigurationsinstanz aus oder erstellen Sie eine.

Veraltete Jobtypen

Mehrere Jobtypen, wie beispielsweise der IBM Globalization Pipeline-Build-Job, der Space Shell-Test-Job und der DevOps Insights-Gate-Test-Job, sind veraltet. Obwohl diese Jobtypen veraltet sind, können Sie sie möglicherweise trotzdem in die Benutzeroberfläche laden, mit einer Anzeigehinweis, dass der Jobtyp veraltet ist. Alternativ dazu kann Ihr Job mit einer Warnung auf einen anderen Jobtyp zurückgesetzt werden, der noch unterstützt wird.

Wenn Sie die Konfiguration eines veralteten Jobtyps verwenden müssen, verwenden Sie eine der folgenden Methoden, um auf die Pipelinekonfiguration zugreifen zu können.

Verwenden Sie das IBM Cloud Devtool:

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

Verwenden Sie die 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>

Filtern Sie auf der Registerkarte Netzwerk der Delivery Pipeline-Benutzeroberfläche nach der Pipeline-ID, um die Pipeline zu lokalisieren, welche die veralteten Jobtypdaten enthält.

API-Schlüssel

Einige der Standard-Pipeline-Jobs verwenden API-Schlüssel von IBM Cloud, um auf Dienste zuzugreifen, beispielsweise für die Bereitstellung auf Kubernetes. Der Service IBM Cloud Identity and Access Management (IAM) stellt zwei Typen von API-Schlüsseln bereit:

Benutzer-API-Schlüssel: Diese API-Schlüssel bieten vollständigen Zugriff auf alle Services und Ressourcen, auf die der Benutzer Zugriff hat.
Service-API-Schlüssel: Sie können Service-API-Schlüssel konfigurieren, um eingeschränkten Zugriff auf bestimmte Services und Ressourcen zu gewähren.

Einige Services können keine API-Schlüssel für Service-IDs verwenden. In solchen Fällen werden Sie von der Pipelinebenutzerschnittstelle aufgefordert, einen Benutzer-API-Schlüssel anzugeben.

Da Pipelinejobs vom Benutzer erstellte Scripts ausführen, die Service-API-Schlüssel in beliebiger Weise verwenden können, kann die Pipeline den Satz von Einschränkungen nicht bestimmen, die für einen bestimmten Schlüssel gelten. Wenn Sie in solchen Fällen anfordern, dass die Pipeline einen API-Schlüssel erstellt, wird ein Benutzer-API-Schlüssel erstellt. Verwenden Sie für eine kontinuierlich hohe Sicherheit stattdessen einen Service-API-Schlüssel mit beschränktem Zugriff auf die Services und Ressourcen, die Sie im Script benötigen. In dieser Instanz müssen Sie den API-Schlüssel selbst erstellen. Weitere Informationen zum Erstellen eines API-Schlüssels finden Sie unter IBM Cloud-API-Schlüssel.

Jobs

Ein Job ist eine Ausführungseinheit innerhalb einer Phase. Eine Phase kann mehrere Jobs enthalten und die Jobs in einer Phase werden nacheinander ausgeführt. Falls ein Job fehlschlägt, werden nachfolgende Jobs in der Phase nicht ausgeführt.

Erstellen und Testen von Aufträgen innerhalb einer — und Testen von Aufträgen innerhalb einer

Jobs werden in diskreten Arbeitsverzeichnissen innerhalb von Docker-Containern ausgeführt, die für jede Pipelineausführung erstellt werden. Vor der Ausführung eines Jobs wird sein Arbeitsverzeichnis mit Eingaben gefüllt, die auf der Ebene der Phase definiert wurden. Sie haben beispielsweise eine Phase, die einen Testjob und einen Bereitstellungsjob enthält. Wenn Sie Abhängigkeiten in einem Job installieren, so sind diese für den anderen Job nicht verfügbar. Falls Sie die Abhängigkeiten in der Eingabe der Phase verfügbar machen, stehen Sie beiden Jobs zur Verfügung.

Wenn Sie einen Job konfigurieren, können Sie mit Ausnahme von Buildjobs vom einfachen Typ (Simple), UNIX-Shell-Scripts einbeziehen, die Build-, Test- oder Bereitstellungsbefehle einschießen. Da Jobs in Ad-hoc-Containern ausgeführt werden, können die Aktionen eines Jobs nicht die Ausführungsumgebungen anderer Jobs beeinflussen, selbst wenn diese Jobs Teil derselben Phase sind.

Beispielskripte für die Erstellung und Bereitstellung finden Sie unter https://github.com/open-toolchain/commons.

Darüber hinaus können Pipeline-Jobs nur die folgenden Befehle als sudo ausführen:

/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

Nachdem ein Job ausgeführt wurde, wird der Container, der für ihn erstellt worden ist, gelöscht. Die Ergebnisse eines Jobs können erhalten bleiben, die Umgebung, in der der Job ausgeführt wurde, kann jedoch nicht erhalten bleiben.

Jobs können für eine Dauer von bis zu 60 Minuten ausgeführt werden. Wenn Jobs diesen Grenzwert überschreiten, schlagen sie fehl. Falls ein Job den Grenzwert überschreitet, teilen Sie ihn in mehrere Jobs auf. Wenn ein Job zum Beispiel drei Aufgaben ausführt, können Sie ihn möglicherweise in drei Jobs aufteilen: Ein Job für jede Aufgabe.

Informationen dazu, wie Sie einen Job zu einer Phase hinzufügen, enthält das Thema Einen Job zu einer Phase hinzufügen.

Buildjobs

Buildjobs kompilieren Ihr Projekt in Vorbereitung auf die Bereitstellung. Sie generieren Artefakte, die an ein Buildarchivverzeichnis gesendet werden können, obwohl die Artefakte standardmäßig in das Stammverzeichnis des Projekts gestellt werden.

Jobs, die Eingaben von Buildjobs erhalten, müssen Buildartefakte in derselben Struktur referenzieren, in der sie erstellt wurden. Wenn ein Buildjob zum Beispiel Buildartefakte in das Verzeichnis output archiviert, würde ein Bereitstellungsscript auf das Verzeichnis output und nicht auf das Projektstammverzeichnis verweisen, um das kompilierte Projekt zu implementieren. Sie können das Verzeichnis für die Archivierung angeben, indem Sie den Verzeichnisnamen in das Feld Buildarchivverzeichnis eingeben. Wenn Sie das Feld leer lassen, wird das Stammverzeichnis archiviert.

Wenn Sie den Buildertyp Simple verwenden, wird Ihr Code nicht kompiliert oder erstellt; er wird gepackt und für zukünftige Phasen zur Verfügung gestellt.

Bereitstellungsjobs

Bereitstellungsjobs laden Ihr Projekt als eine App in IBM Cloud hoch und sind über eine URL zugänglich. Nach der Bereitstellung eines Projekts finden Sie die bereitgestellte App in Ihrem IBM Cloud-Dashboard.

Bereitstellungsjobs können neue Apps bereitstellen oder vorhandene Apps aktualisieren. Selbst wenn Sie eine App zuerst mit einer anderen Methode bereitgestellt haben, können Sie die App mithilfe eines Bereitstellungsjobs aktualisieren. Verwenden Sie den Namen der App, um eine App in einem Bereitstellungsjob zu aktualisieren.

Es ist eine Bereitstellung für eine oder mehrere Regionen bzw. einen oder mehrere Services möglich. Sie können Ihre Delivery Pipeline beispielsweise so einrichten, dass sie mindestens einen Service verwendet, in einer einzigen Region getestet oder und in mehreren Regionen für die Produktion bereitgestellt wird.

Testjobs

Wenn Bedingungen eingehalten werden sollen, schließen Sie Testjobs vor oder nach Ihren Build- und Bereitstellungsjobs ein. Sie können Testjobs anpassen, damit diese so einfach oder so komplex wie erforderlich sind. Möglicherweise erwarten Sie eine bestimmte Antwort auf die Ausgabe eine cURL-Befehls. Möglicherweise möchten Sie eine Reihe von Komponententests ausführen oder Funktionstests mit Testservices Dritter wie beispielsweise Sauce Labs ausführen.

Wenn Ihre Tests Ergebnisdateien im JUnit XML-Format erzeugen, wird ein Bericht auf Grundlage der Ergebnisdateien auf der Registerkarte Tests jeder Seite mit Testergebnissen angezeigt. Wenn ein Test fehlschlägt, schlägt der Job ebenfalls fehl.

Umgebungseigenschaften (Umgebungsvariablen)

Eine Reihe vordefinierter Umgebungseigenschaften bietet Zugriff auf Informationen zur Ausführungsumgebung des Jobs. Eine vollständige Liste der vordefinierten Umgebungseigenschaften finden Sie im Abschnitt zu Umgebungseigenschaften und Ressourcen.

Sie können auch Ihre eigenen Umgebungseigenschaften definieren. Sie können z. B. die Eigenschaft API_KEY definieren, mit der ein API-Schlüssel übergeben wird, der für den Zugriff auf IBM Cloud-Ressourcen durch alle Scripts in der Pipeline verwendet wird.

Sie können die folgenden Typen von Eigenschaften hinzufügen:

Text: Ein Eigenschaftsschlüssel mit einem einzeiligen Wert.
Textbereich: Ein Eigenschaftsschlüssel mit einem mehrzeiligen Wert. Eine Base64-Version jedes Eigenschaftswerts für Textbereiche ist ebenfalls verfügbar. Auf diese Version können Sie zugreifen, indem Sie den Eigenschaftsschlüsselnamen mit dem abschließenden Suffix _base641 verwenden. Sie können die Base64-Version einer Textbereichseigenschaft entschlüsseln und ausgeben, indem Sie echo "$(echo $multi_base64 | base64 -d)" eingeben. Dabei ist multi der definierte Eigenschaftsschlüsselname und multi_base64 die bereitgestellte zusätzliche Eigenschaft. Das Basisimage der Pipeline enthält integrierte Unterstützung zur transparenten Verwaltung mehrzeiliger Verschlüsselungen. Wenn Sie jedoch ein angepasstes Image verwenden, müssen Sie die Eigenschaft mit dem Suffix _base64 verwenden, um zu verhindern, dass Probleme auftreten, weil der Wert am Zeilenende abgeschnitten wird.
Sicher: Ein Eigenschaftsschlüssel mit einem einzeiligen Wert, der mit der AES-128-Verschlüsselung gesichert ist. Der Wert wird in Form von Sternen angezeigt.
Eigenschaften: Eine Datei im Projektrepository. Diese Datei kann mehrere Eigenschaften enthalten. Jede Eigenschaft muss in einer eigenen Zeile stehen. Verwenden Sie zum Trennen von Schlüssel/Wert-Paaren das Gleichheitszeichen (=). Schließen Sie alle Zeichenfolgewerte in Anführungszeichen ein. Beispiel: MY_STRING="SOME STRING VALUE".

Sie können die Umgebungseigenschaften für einen Pipeline-Job prüfen, indem Sie den Befehl env im Job-Script ausführen.

Pipeline-Eigenschaften

Wählen Sie die Option Pipeline konfigurieren im Überlaufmenü auf der Seite 'Pipeline' aus, um Pipeline-Eigenschaften zu definieren.

Menü "Pipeline-Überlauf "*Menü " — caption-side=bottom"

Geben Sie auf der Registerkarte Umgebungseigenschaften auf der Seite 'Pipelinekonfiguration' die Umgebungseigenschaften auf Pipeline-Ebene an.

Stage-Eigenschaften

Öffnen Sie zur Definition der Phase-Eigenschaften die Seite für die Phase-Konfiguration und klicken Sie auf die Registerkarte Umgebungseigenschaften.

Bühnen-Eigenschaften-SeiteBühnen-Eigenschaften-Seite

Sie können eine Phaseneigenschaft unter Verwendung eines Anfangswerts (oder leeren Werts) definieren und diesen Wert dann in einem Job überschreiben, indem Sie eine Umgebungsvariable exportieren. Durch das Überschreiben des Anfangswerts können nachfolgende Jobs in der Phase den neuen Wert sehen. Sie können beispielsweise den folgenden Befehl einschließen, um die Eigenschaft $API_KEY festzulegen und für einen anderen Job innerhalb der Phase verfügbar zu machen: export API_KEY=<insert API key here>

Berechnete Eigenschaften

Sie können die Umgebungseigenschaftswerte berechnen, die von mehreren Phasen gemeinsam genutzt werden, indem Sie während er Ausführung der Phase eine Datei des Typs build.properties erstellen und die nächste Phase diese Datei ausführen lassen. Ihr Buildjob könnte beispielsweise den folgenden Befehl im Build-Script einbeziehen:

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

Alle Jobs beginnen mit der Ausführung der Datei build.properties, sofern sie vorhanden ist.

Artefakte erstellen und verwenden

Buildjobs rufen automatisch den Inhalt in dem aktuellen Ordner ab, in dem das Benutzerscript ausgeführt wird. Wenn Sie nicht den gesamten Git-Repo-Inhalt für eine spätere Bereitstellung benötigen, sollten Sie ein explizites Ausgabeverzeichnis konfigurieren und anschließend die relevanten Artefakte dort kopieren oder erstellen. Job-Scripts werden im Buildergebnis (Ausgabeverzeichnis) ausgeführt.

Bereitstellungsjobs, die Bereitstellungen für den IBM Cloud Kubernetes Service ausführen, müssen den Plattform-API-Schlüssel eines Benutzers, mit dessen Berechtigung Jobs ausgeführt werden, sowie eine Dockerfile und optional ein Helm-Chart angeben.

Das Job-Script wird ausgeführt, nachdem sich der Job in der Zielumgebung unter Verwendung des ihm zugeordneten Plattform-API-Schlüssels angemeldet hat (damit Sie die Befehle cf push oder kubectl im Script ausführen können).

Eine Beispielpipeline

Eine einfache Pipeline kann drei Phasen enthalten:

Eine Phase für den Build, die Erstellungsprozesse auf einer App kompiliert und einen Build ausführt.
Eine Phase für den Test, die eine Instanz der App bereitstellt und in dieser Instanz anschließend Tests ausführt.
Eine Phase für die Produktion, die eine Produktionsinstanz der getesteten App bereitstellt.

Diese Pipeline wird im folgenden Konzeptionsdiagramm dargestellt:

Ein konzeptionelles Diagramm der Phasen und Aufgaben in einer — einer dreistufigen

Phasen bekommen Ihre Eingaben von Repositorys und Buildjobs. Jobs innerhalb einer Phase werden nacheinander und unabhängig voneinander ausgeführt. In der Beispielpipeline werden die Phasen nacheinander ausgeführt, obwohl die Phasen für den Test und die Produktion beide die Ausgabe der Phase für den Build als Eingabe verwenden.