Présentation de Classic Delivery Pipeline

DevOps Insights Le service prendra fin et sera interrompu le 31 août 2026. Le service Continuous Delivery sera interrompu dans les régions suivantes le 12 février 2027 : au-syd, ca-tor, us-east. Code Risk Analyzer sera également retiré du marché dans toutes les régions à cette date. Si ces fonctionnalités ne sont pas activement utilisées dans une région donnée, elles pourraient y être supprimées plus tôt et ne plus accepter de nouvelles instances. En savoir plus

IBM Cloud® Continuous Delivery inclut Classic Delivery Pipeline qui vous permet de générer, tester et déployer d'une manière reproductible avec un minimum d'intervention humaine. Dans un pipeline, des séquences d'étapes permettent d'extraire des entrées et d'exécuter des travaux, par exemple, des générations, des tests et des déploiements.

Vous pouvez travailler avec les pipelines de livraison Classic et Tekton à l'aide du navigateur ou à l'aide du IBM Cloud Commandes CLI Developer Tools(ibmcloud dev). Vous pouvez également travailler avec les pipelines de livraison Tekton en utilisant l 'API et les HTTP SDK du pipeline Tekton, ou en utilisant le fournisseur IBM Cloud Terraform. Pour plus d'informations sur les pipelines de livraison Tekton, consultez la section Utilisation des pipelines Tekton.

Vos autorisations pour afficher, modifier ou exécuter un pipeline dépendent du contrôle d'accès de la chaîne d'outils propriétaire du pipeline. Pour plus d'informations sur le contrôle d'accès pour les chaînes d'outils, voir Gestion de l'accès aux chaînes d'outils dans les groupes de ressources.

Vous pouvez spécifier l'exécution de scripts dans plusieurs types de travaux fournis par le pipeline pour obtenir un contrôle direct de ce qui est exécuté par le travail. Ces scripts s'exécutent dans une image Docker contenant une série d'outils de développement standard, y compris les outils requis pour interagir avec les environnements d'exécution IBM Cloud. Pour en savoir plus sur ce que contient l'image Docker standard, voir Ressources préinstallées. Si votre travail requiert des outils de développement qui ne sont pas disponibles dans l'image standard ou si vous avez besoin de versions différentes de ces outils, vous pouvez utiliser une image personnalisée. Pour en savoir plus sur les images personnalisées, voir Utilisation des images Docker personnalisées.

Lorsque le pipeline exécute les scripts, les propriétés qui décrivent le contexte où le travail s'exécute sont transmises au script à l'aide des variables d'environnement. Par exemple, l'URL du référentiel qui est l'entrée de l'étape, le nom de l'étape et le travail qui est exécuté, les paramètres spécifiés par le type de travail, etc. Pour afficher une liste des variables d'environnement disponibles, voir Ressources préinstallées.

Vous pouvez définir les propriétés au niveau du pipeline et au niveau de l'étape. Les propriétés d'un pipeline sont partagées entre toutes les étapes et tous les travaux d'un pipeline. Les propriétés d'étape sont spécifiques à une étape particulière et sont partagées entre tous les travaux de cette étape. Pour en savoir plus sur les propriétés, voir Propriétés d'environnement (variables d'environnement).

Etapes

Les étapes organisent des entrées et des travaux à mesure que votre code est généré, déployé et testé. Les étapes acceptent les entrées des référentiels de contrôle des sources (référentiels SCM) ou des travaux de génération appartenant à d'autres étapes. Pour les référentiels SCM, les entrées sont le contenu d'une branche particulière du référentiel ; pour les travaux de génération, les entrées sont les artefacts produits par le travail. Lorsque vous créez votre première étape, l'onglet INPUT contient les paramètres par défaut.

Lorsqu'une étape s'exécute, l'entrée de l'étape est transmise à chaque travail de l'étape. Chaque travail obtient un conteneur propre dans lequel il peut s'exécuter. Par conséquent, les travaux à l'intérieur d'une étape ne peuvent pas se transmettre des artefacts entre eux. Pour transmettre des artefacts dans des travaux, séparez ces travaux en deux étapes et utilisez la sortie du travail de la première étape comme entrée de la seconde étape. Tout travail de génération peut être transféré à un autre travail dans une autre étape. Par défaut, la sortie est créée dans le dossier ./. Si vous ne souhaitez pas récupérer la sortie du travail de génération, configurez un dossier comme sortie et n'envoyez aucune sortie vers ce dossier.

De la même façon que vous pouvez définir les propriétés du pipeline, vous pouvez définir des propriétés d'étapes pour les utiliser dans tous les travaux d'une étape particulière. Par exemple, vous pouvez définir une propriété TEST_URL qui transmet une URL aux travaux de déploiement et de test dans une étape. Le travail de déploiement déploie dans cette URL et le travail de test teste l'application active sur l'URL. Les propriétés des étapes sont également transmises aux scripts de travail à l'aide des variables d'environnement. Si la même propriété est définie au niveau du pipeline et au niveau de l'étape, la valeur de la propriété d'étape est utilisée.

Par défaut dans une étape, les générations et les déploiements sont exécutés automatiquement à chaque fois que des changements sont livrés au référentiel SCM d'un projet. Les étapes et les travaux s'exécutent en série ; ils activent le contrôle du débit pour votre travail. Par exemple, vous pouvez placer une étape de test avant une étape de déploiement. Si les tests de l'étape de test échouent, l'étape de déploiement ne s'exécute pas.

Delivery Pipeline utilise des agents publics et privés pour exécuter les travaux d'une étape. Par défaut, les travaux de pipeline sont exécutés à l'aide d'agents publics sur une infrastructure partagée publique gérée par IBM.

Dans certains scénarios, votre Delivery Pipeline peut nécessiter un accès à des ressources internes ou sur site. Dans ces situations, vous pouvez vous connecter et intégrer un agent Delivery Pipeline privé pour qu'il s'exécute sur votre propre infrastructure Kubernetes.

Vous souhaiterez peut-être avoir un contrôle plus strict d'une étape spécifique. Si vous ne souhaitez pas qu'une étape s'exécute à chaque fois qu'une modification se produit au niveau de son entrée, vous pouvez désactiver cette fonction. Sur l'onglet Entrée, dans la section Déclencheur d'étape, cliquez sur Exécuter les travaux lorsque cette étape est exécutée manuellement.

D'autres options de déclenchement des étapes sont disponibles pour les étapes qui utilisent le type d'entrée de référentiel Git. Par exemple, vous pouvez choisir d'exécuter des travaux automatiquement pour des événements Git sur une branche choisie. Lorsque vous sélectionnez ce type de déclencheur, vous devez sélectionner le ou les types d'événements suivants :

L'option When a commit is pushed se déclenche lorsqu'une commande push est envoyée à la branche de référentiel sélectionnée.
L'option When a pull/merge request is opened or updated se déclenche lorsqu'une demande d'extraction ou de fusion est ouverte ou éditée.
L'option When a pull/merge request is closed se déclenche lorsqu'une demande d'extraction ou de fusion est fermée, même sans validation associée.

Si vous cochez la case When a pull/merge request is opened or updated, le statut du pipeline est renvoyé au référentiel Git. Lorsqu'une demande d'extraction ou de fusion déclenche votre pipeline, une vérification de statut en ligne s'affiche sur la page. Une vérification de statut s'affiche pour chacune des étapes exécutées dans votre pipeline et des liens vers les protocoles et l'historique sont fournis pour chaque étape. Au fur et à mesure que la vérification de statut s'exécute, le statut passe de En attente à Réussite ou Echec. Si votre pipeline contient plusieurs étapes, chacune d'entre elles indique son état dans la liste de contrôle.

Ce compte-rendu de statut est également pris en charge par l'outil GitLab Community Edition hébergé par IBM pour les demandes de fusion.

Vous pouvez également limiter la fusion en fonction des résultats des vérifications de statut à l'aide des règles de protection des branches Git. Une fois qu'une règle de protection de branche est créée, toute fusion est bloquée jusqu'à ce que toutes les vérifications de statut requises aboutissent.

Demandes d'extraction Bitbucket Cloud

Actuellement, Bitbucket Cloud ne prend pas en charge les références de référentiel pour les demandes d'extraction, ce qui est requis par le service Continuous Delivery. Cette fonction permet d'envoyer des demandes d'extraction au référentiel auquel vous souhaitez accéder en utilisant des références au format suivant : refs/pull/123/…

Vous pouvez récupérer et valider localement une pull request à l'aide du dépôt source URL. Toutefois, si le référentiel source est un référentiel dévié privé, le service Continuous Delivery ne dispose pas de l'accès requis pour gérer les demandes d'extraction. Pour contourner cette limitation, vous devez fournir explicitement l'accès requis au référentiel dévié dans le script de pipeline.

Dans l'exemple de script de pipeline bash ci-après, deux utilisateurs utilisent Bitbucket Cloud et chacun d'eux dispose d'une déviation privée de leur référentiel principal (bitbucket.org/userA/repo-forked-A et bitbucket.org/userB/repo-forked-B). Le script est configuré pour réserver la demande d'extraction lorsqu'un travail de génération est déclenché par un événement d'ouverture ou de mise à jour de demande d'extraction à partir de l'un des deux référentiels déviés.

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

Etape de génération

L'étape de génération spécifie un type de générateur pour indiquer comment générer les artefacts.

Plusieurs des zones disponibles dans les travaux de génération sont communes aux différents types de générateurs.

Les types de générateurs suivants sont disponibles :

Types de constructeurs
Type de générateur	Description	Types de travaux pris en charge
Simple	Archive l'entrée de l'étape en cours sans modification pour les étapes ultérieures. Généralement, ce type de générateur n'est utile que lorsque l'entrée de l'étape provient d'un référentiel SCM.	Version d'image Pipeline : s'exécute dans un conteneur à l'aide d'une image Docker intégrée, qui fournit différentes commandes intégrées. Pour adopter les dernières versions de ces commandes, utilisez une version d'image plus récente.
Ant	Utilise les fichiers Apache Ant pour gérer le travail de génération.	Version d'image Pipeline : s'exécute dans un conteneur à l'aide d'une image Docker intégrée, qui fournit différentes commandes intégrées. Pour adopter les dernières versions de ces commandes, utilisez une version d'image plus récente. Script de génération : Exécutions dans un nouveau shell Ubuntu chaque fois que le travail s'exécute. Dans la zone Script, entrez un script ou des scripts de référence stockés dans le contrôle des sources de votre projet. Répertoire de travail : Indique le répertoire d'exécution du script. Générer un répertoire d'archive : Indique le répertoire qui contient la sortie du travail à archiver pour une utilisation ultérieure. Activer le rapport de test : Cochez cette case pour indiquer que le travail de génération exécute des tests qui produisent des fichiers de résultats au format JUnit XML. Un rapport basé sur les fichiers de résultats est affiché sur l'onglet Tests de la page de résultat de travail. Si un test échoue, le travail est marqué comme ayant échoué. Activer le rapport de couverture de code : Cochez cette case pour afficher plus de zones que vous pouvez utiliser pour le rapport de couverture de code. Vous pouvez spécifier l'outil de mesure de couverture (tel qu' JaCoCo, ou Cobertura), l'emplacement du fichier de résultats de couverture et le répertoire de résultats de couverture, par rapport au répertoire de travail.
Registre de conteneurs	Génères des images docker et les télécharge dans le registre IBM Cloud Container Registry.	Version d'image Pipeline : s'exécute dans un conteneur à l'aide d'une image Docker intégrée, qui fournit différentes commandes intégrées. Pour adopter les dernières versions de ces commandes, utilisez une version d'image plus récente. Clé d'interface de programmation : la clé de l'interface de programmation IBM Cloud à utiliser pour fournir des droits d'accès aux ressources. Espace de nom de registre de conteneur : l'espace de nom dans lequel vous souhaitez stocker l'image générée. Nom de l'image Docker : nom de l'image que ce travail génère et télécharge dans le registre de conteneur IBM Cloud. Script de génération : Exécutions dans un nouveau shell Ubuntu chaque fois que le travail s'exécute. Dans la zone Script, entrez un script ou des scripts de référence stockés dans le contrôle des sources de votre projet. Répertoire de travail : Indique le répertoire d'exécution du script. Générer un répertoire d'archive : Indique le répertoire qui contient la sortie du travail à archiver pour une utilisation ultérieure. Activer le rapport de test : Cochez cette case pour indiquer que le travail de génération exécute des tests qui produisent des fichiers de résultats au format JUnit XML. Un rapport basé sur les fichiers de résultats est affiché sur l'onglet Tests de la page de résultat de travail. Si un test échoue, le travail est marqué comme ayant échoué. Activer le rapport de couverture de code : Cochez cette case pour afficher plus de zones que vous pouvez utiliser pour le rapport de couverture de code. Vous pouvez spécifier l'outil de mesure de couverture (tel qu' JaCoCo, ou Cobertura), l'emplacement du fichier de résultats de couverture et le répertoire de résultats de couverture, par rapport au répertoire de travail.
Image Docker personnalisée	Permet de créer des images en utilisant votre image Docker personnalisée, avec un contrôle précis sur les versions de Node, d' Java™ ou d'autres outils.	Nom d'image Docker : nom de l'image que ce travail génère et télécharge dans IBM Cloud Container Registry. Script de génération : Exécutions dans un nouveau shell Ubuntu chaque fois que le travail s'exécute. Dans la zone Script, entrez un script ou des scripts de référence stockés dans le contrôle des sources de votre projet. Générez un répertoire d'archive : Indique le répertoire qui contient la sortie du travail à archiver pour une utilisation ultérieure. Activer le rapport de test : Cochez cette case pour indiquer que le travail de génération exécute des tests qui produisent des fichiers de résultats au format JUnit XML. Un rapport basé sur les fichiers de résultats est affiché sur l'onglet Tests de la page de résultat de travail. Si un test échoue, le travail est marqué comme ayant échoué. Activer le rapport de couverture de code : Cochez cette case pour afficher plus de zones que vous pouvez utiliser pour le rapport de couverture de code. Vous pouvez spécifier l'outil de mesure de couverture (tel qu' JaCoCo, ou Cobertura), l'emplacement du fichier de résultats de couverture et le répertoire de résultats de couverture, par rapport au répertoire de travail.
Gradle	Génération à l'aide de Gradle.	Version d'image Pipeline : s'exécute dans un conteneur à l'aide d'une image Docker intégrée, qui fournit différentes commandes intégrées. Pour adopter les dernières versions de ces commandes, utilisez une version d'image plus récente. Script de génération : Exécutions dans un nouveau shell Ubuntu chaque fois que le travail s'exécute. Dans la zone Script, entrez un script ou des scripts de référence stockés dans le contrôle des sources de votre projet. Répertoire de travail : Indique le répertoire d'exécution du script. Générez un répertoire d'archive - Indique le répertoire contenant la sortie du travail à archiver pour une étape ultérieure. Activer le rapport de test : Cochez cette case pour indiquer que le travail de génération exécute des tests qui produisent des fichiers de résultats au format JUnit XML. Un rapport basé sur les fichiers de résultats est affiché sur l'onglet Tests de la page de résultat de travail. Si un test échoue, le travail est marqué comme ayant échoué. Activer le rapport de couverture de code : Cochez cette case pour afficher plus de zones que vous pouvez utiliser pour le rapport de couverture de code. Vous pouvez spécifier l'outil de mesure de couverture (tel qu' JaCoCo, ou Cobertura), l'emplacement du fichier de résultats de couverture et le répertoire de résultats de couverture, par rapport au répertoire de travail.
Grunt	Génération à l'aide de Grunt.	Version d'image Pipeline : s'exécute dans un conteneur à l'aide d'une image Docker intégrée, qui fournit différentes commandes intégrées. Pour adopter les dernières versions de ces commandes, utilisez une version d'image plus récente. Script de génération : Exécutions dans un nouveau shell Ubuntu chaque fois que le travail s'exécute. Dans la zone Script, entrez un script ou des scripts de référence stockés dans le contrôle des sources de votre projet. Répertoire de travail : Indique le répertoire d'exécution du script. Générer un répertoire d'archive : Indique le répertoire qui contient la sortie du travail à archiver pour une utilisation ultérieure. Activer le rapport de test : Cochez cette case pour indiquer que le travail de génération exécute des tests qui produisent des fichiers de résultats au format JUnit XML. Un rapport basé sur les fichiers de résultats est affiché sur l'onglet Tests de la page de résultat de travail. Si un test échoue, le travail est marqué comme ayant échoué. Activer le rapport de couverture de code : Cochez cette case pour afficher plus de zones que vous pouvez utiliser pour le rapport de couverture de code. Vous pouvez spécifier l'outil de mesure de couverture (tel qu' JaCoCo, ou Cobertura), l'emplacement du fichier de résultats de couverture et le répertoire de résultats de couverture, par rapport au répertoire de travail.
Maven	Génération à l'aide d'Apache Maven.	Version d'image Pipeline : s'exécute dans un conteneur à l'aide d'une image Docker intégrée, qui fournit différentes commandes intégrées. Pour adopter les dernières versions de ces commandes, utilisez une version d'image plus récente. Script de génération : Exécutions dans un nouveau shell Ubuntu chaque fois que le travail s'exécute. Dans la zone Script, entrez un script ou des scripts de référence stockés dans le contrôle des sources de votre projet. Répertoire de travail : Indique le répertoire d'exécution du script. Générer un répertoire d'archive : Indique le répertoire qui contient la sortie du travail à archiver pour une utilisation ultérieure. Activer le rapport de test : Cochez cette case pour indiquer que le travail de génération exécute des tests qui produisent des fichiers de résultats au format JUnit XML. Un rapport basé sur les fichiers de résultats est affiché sur l'onglet Tests de la page de résultat de travail. Si un test échoue, le travail est marqué comme ayant échoué. Activer le rapport de couverture de code : Cochez cette case pour afficher plus de zones que vous pouvez utiliser pour le rapport de couverture de code. Vous pouvez spécifier l'outil de mesure de couverture (tel qu' JaCoCo, ou Cobertura), l'emplacement du fichier de résultats de couverture et le répertoire de résultats de couverture, par rapport au répertoire de travail.
npm	Installe les dépendances avec le gestionnaire de package Node.	Version d'image Pipeline : s'exécute dans un conteneur à l'aide d'une image Docker intégrée, qui fournit différentes commandes intégrées. Pour adopter les dernières versions de ces commandes, utilisez une version d'image plus récente. Script de génération : Exécutions dans un nouveau shell Ubuntu chaque fois que le travail s'exécute. Dans la zone Script, entrez un script ou des scripts de référence stockés dans le contrôle des sources de votre projet. Répertoire de travail : Indique le répertoire d'exécution du script. Générer un répertoire d'archive : Indique le répertoire qui contient la sortie du travail à archiver pour une utilisation ultérieure. Activer le rapport de test : Cochez cette case pour indiquer que le travail de génération exécute des tests qui produisent des fichiers de résultats au format JUnit XML. Un rapport basé sur les fichiers de résultats est affiché sur l'onglet Tests de la page de résultat de travail. Si un test échoue, le travail est marqué comme ayant échoué. Activer le rapport de couverture de code : Cochez cette case pour afficher plus de zones que vous pouvez utiliser pour le rapport de couverture de code. Vous pouvez spécifier l'outil de mesure de couverture (tel qu' JaCoCo, ou Cobertura), l'emplacement du fichier de résultats de couverture et le répertoire de résultats de couverture, par rapport au répertoire de travail.
Script shell	Exécute un script shell UNIX, tel que Bash.	Version d'image Pipeline : s'exécute dans un conteneur à l'aide d'une image Docker intégrée, qui fournit différentes commandes intégrées. Pour adopter les dernières versions de ces commandes, utilisez une version d'image plus récente. Script de génération : Exécutions dans un nouveau shell Ubuntu chaque fois que le travail s'exécute. Dans la zone Script, entrez un script ou des scripts de référence stockés dans le contrôle des sources de votre projet. Répertoire de travail : Indique le répertoire d'exécution du script. Générer un répertoire d'archive : Indique le répertoire qui contient la sortie du travail à archiver pour une utilisation ultérieure. Activer le rapport de test : Cochez cette case pour indiquer que le travail de génération exécute des tests qui produisent des fichiers de résultats au format JUnit XML. Un rapport basé sur les fichiers de résultats est affiché sur l'onglet Tests de la page de résultat de travail. Si un test échoue, le travail est marqué comme ayant échoué. Activer le rapport de couverture de code : Cochez cette case pour afficher plus de zones que vous pouvez utiliser pour le rapport de couverture de code. Vous pouvez spécifier l'outil de mesure de couverture (tel qu' JaCoCo, ou Cobertura), l'emplacement du fichier de résultats de couverture et le répertoire de résultats de couverture, par rapport au répertoire de travail.
Gradle (Artifactory, Nexus ou SonarQube)	Génération et déploiement à l'aide de Gradle avec un référentiel Nexus ou Artifactory. Gradle est également intégré à SonarQube.	Version d'image Pipeline : s'exécute dans un conteneur à l'aide d'une image Docker intégrée, qui fournit différentes commandes intégrées. Pour adopter les dernières versions de ces commandes, utilisez une version d'image plus récente. Instance d'intégration d'outil de référentiel : nom de l'instance d'intégration de l'outil de référentiel à utiliser avec ce travail de génération. Type d'intégration de l'outil de référentiel : Type d'intégration d'outil permettant d'obtenir des informations Gradle à partir de. Instance d'intégration SonarQube : Nom de l'instance d'intégration SonarQube à utiliser avec ce travail de génération. Commande de génération : exécution de la commande de génération à chaque exécution du travail. Dans la zone Script, entrez un script ou des scripts de référence stockés dans le contrôle des sources de votre projet. Répertoire de travail : Indique le répertoire d'exécution du script. Générer un répertoire d'archive : Indique le répertoire qui contient la sortie du travail à archiver pour une utilisation ultérieure.
Maven (Artifactory, Nexus ou SonarQube)	Génération et déploiement à l'aide de Maven avec un référentiel Nexus ou Artifactory. Maven est également intégré à SonarQube.	Version d'image Pipeline : s'exécute dans un conteneur à l'aide d'une image Docker intégrée, qui fournit différentes commandes intégrées. Pour adopter les dernières versions de ces commandes, utilisez une version d'image plus récente. Instance d'intégration d'outil de référentiel : Nom de l'instance d'intégration de l'outil de référentiel à utiliser avec ce travail de génération. Type d'intégration de l'outil de référentiel : Type d'intégration d'outil permettant d'obtenir des informations Gradle à partir de. Instance d'intégration SonarQube : nom de l'instance d'intégration SonarQube à utiliser avec ce travail de génération. Commande de génération : commande de génération à exécuter chaque fois que le travail s'exécute. Dans la zone Script, entrez un script ou des scripts de référence stockés dans le contrôle des sources de votre projet. Répertoire de travail : Indique le répertoire d'exécution du script. Générer un répertoire d'archive : Indique le répertoire qui contient la sortie du travail à archiver pour une utilisation ultérieure.
npm (Artifactory ou Nexus)	Génération à l'aide de npm avec un référentiel Nexus ou Artifactory.	Version d'image Pipeline : s'exécute dans un conteneur à l'aide d'une image Docker intégrée, qui fournit différentes commandes intégrées. Pour adopter les dernières versions de ces commandes, utilisez une version d'image plus récente. Instance d'intégration d'outil de référentiel : nom de l'instance d'intégration de l'outil de référentiel à utiliser avec ce travail de génération. Type d'intégration de l'outil de référentiel : Type d'intégration d'outil permettant d'obtenir des informations Gradle à partir de. Instance d'intégration SonarQube : Nom de l'instance d'intégration SonarQube à utiliser avec ce travail de génération. Commande de génération : exécution de la commande de génération à chaque exécution du travail. Dans la zone Script, entrez un script ou des scripts de référence stockés dans le contrôle des sources de votre projet. Version du module d'image instantanée d'incrément: prend en charge la distribution continue en incrémentant localement la version du module en fonction du contenu du fichier `package.json` et de l'instantané courant signalé dans le registre npm à l'étape de publication. Répertoire de travail : Indique le répertoire d'exécution du script. Générer un répertoire d'archive : Indique le répertoire qui contient la sortie du travail à archiver pour une utilisation ultérieure.

Étape de déploiement

L'étape de déploiement spécifie l'entrée d'une étape de génération. Les travaux d'une étape de déploiement spécifient un type de déployeur. Les types de déployeurs suivants sont disponibles :

Types de déployeurs
Type de déployeur	Description	Types de travaux pris en charge
Image Docker personnalisée	Déploiement à l'aide de votre image personnalisée d' Docker, avec un contrôle précis des versions de Node, d' Java™ ou d'autres outils.	Version d'image Pipeline : s'exécute dans un conteneur à l'aide d'une image Docker intégrée, qui fournit différentes commandes intégrées. Pour adopter les dernières versions de ces commandes, utilisez une version d'image plus récente. Clé d'interface de programmation : la clé de l'interface de programmation IBM Cloud à utiliser pour fournir des droits d'accès aux ressources. Docker Nom de l'image: nom de l'image que cette tâche génère et télécharge vers l' IBM Cloud Container Registry. Script de déploiement : commande de déploiement à exécuter chaque fois que le travail s'exécute. Dans la zone Script, entrez un script ou des scripts de référence stockés dans le contrôle des sources de votre projet.
Kubernetes	Déploie des applications dans des clusters Kubernetes, comme ceux disponibles dans le service IBM Cloud Container.	Version d'image Pipeline : s'exécute dans un conteneur à l'aide d'une image Docker intégrée, qui fournit différentes commandes intégrées. Pour adopter les dernières versions de ces commandes, utilisez une version d'image plus récente. Clé d'interface de programmation : la clé de l'interface de programmation IBM Cloud à utiliser pour fournir des droits d'accès aux ressources. Nom du cluster: nom du cluster Kubernetes ; plateforme sur laquelle vous déployez vos composants Kubernetes. Script de déploiement : commande de déploiement à exécuter chaque fois que le travail s'exécute. Dans la zone Script, entrez un script ou des scripts de référence stockés dans le contrôle des sources de votre projet.

étape de test

L'étape de test spécifie la configuration de test. Les travaux d'une étape de test spécifient un Type de testeur. Les types de testeur suivants sont disponibles :

Types de testeurs
Type de testeur	Description	Types de travaux pris en charge
Simple	Lance une commande shell pour exécuter les tests automatisés, avec un rapport de test facultatif.	Version de l'image de pipeline : non utilisée. Script de test : commande de test à exécuter chaque fois que le travail s'exécute. Dans la zone Script, entrez un script ou des scripts de référence stockés dans le contrôle des sources de votre projet. Répertoire de travail: répertoire dans lequel le script de test est exécuté. Activer le rapport de test : non utilisé. Activer le rapport de couverture de code : non utilisé.
Image Docker personnalisée	Effectuez des tests à l'aide de votre image personnalisée d' Docker, avec un contrôle précis des versions de Node, d' Java™ ou d'autres outils.	Nom d'image Docker : nom de l'image Docker pour l'exécution du travail. Pour vous assurer que vos travaux s'exécutent dans un contexte propre, exécutez-les dans des conteneurs Docker. Script de test : commande de test à exécuter chaque fois que le travail s'exécute. Dans la zone Script, entrez un script ou des scripts de référence stockés dans le contrôle des sources de votre projet. Répertoire de travail: répertoire dans lequel le script de test est exécuté. Activer le rapport de test : non utilisé. Activer le rapport de couverture de code : non utilisé.
Vulnerability Advisor	Exécute une vérification de conformité et de vulnérabilité par rapport à l'image spécifiée et affiche les résultats. Si des problèmes sont détectés, cette étape échoue.	Version d'image Pipeline : s'exécute dans un conteneur à l'aide d'une image Docker intégrée, qui fournit différentes commandes intégrées. Pour adopter les dernières versions de ces commandes, utilisez une version d'image plus récente. Clé d'interface de programmation : la clé de l'interface de programmation IBM Cloud à utiliser pour fournir des droits d'accès aux ressources. Espace de nom de registre de conteneur : Espace de nom dans lequel l'image générée est stockée. Nom de l'image Docker : Nom de l'image Docker pour l'exécution du travail. Pour vous assurer que vos travaux s'exécutent dans un contexte propre, exécutez-les dans des conteneurs Docker. Balise d'image Docker : balise de l'image Docker qui s'affiche dans le registre de conteneurIBM Cloud. Script de test : commande de test à exécuter chaque fois que le travail s'exécute. Dans la zone Script, entrez un script ou des scripts de référence stockés dans le contrôle des sources de votre projet. Répertoire de travail: répertoire dans lequel le script de test est exécuté. Activer le rapport de test : non utilisé. Activer le rapport de couverture de code : non utilisé.
Sauce Labs	Exécute des tests JavaScript,, Node ou Java™ à l’aide de Sauce Labs.	Version d'image Pipeline : s'exécute dans un conteneur à l'aide d'une image Docker intégrée, qui fournit différentes commandes intégrées. Pour adopter les dernières versions de ces commandes, utilisez une version d'image plus récente. Instance de service : Sélectionnez une Instance de configuration ou créez en une.

Types de travaux obsolètes

Plusieurs types de tâches, tels que la tâche de compilation IBM Globalization Pipeline, la tâche de test Space Shell et la tâche de test de passerelle DevOps Insights, sont obsolètes. Bien que ces types de travaux soient obsolètes, vous pouvez toujours les charger dans l'interface utilisateur, avec un indicateur indiquant que le type de travail est obsolète. Sinon, votre travail peut revenir à un autre type de travail qui est toujours pris en charge, avec une notification d'avertissement.

Si vous devez utiliser la configuration à partir d'un type de travail obsolète, utilisez l'une des méthodes suivantes pour accéder à la configuration du pipeline.

Utilisez l'outil IBM Cloud Devtool :

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

Utilisez l'interface de programmation Delivery Pipeline :

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>

Dans l'onglet Réseau de l'interface utilisateur Delivery Pipeline, filtrez par ID de pipeline pour localiser le pipeline contenant les données de type de travail obsolètes.

Clés d'API

Certaines tâches standard du pipeline utilisent des clés API d' IBM Cloud pour accéder à des services, par exemple pour effectuer un déploiement sur Kubernetes. Le service IBM Cloud Identity and Access Management (IAM) fournit deux types de clés d'API :

Clés d'API d'utilisateur : ces clés d'API fournissent un accès complet à tous les services et ressources auquel l'utilisateur a accès.
Clés d'API de service : vous pouvez configurer des clés d'API de service pour fournir un accès spécifique à différents services et ressources.

Certains services ne peuvent pas utiliser les clés d'API d'ID de service. Dans ce cas, l'interface utilisateur du pipeline vous invite à spécifier une clé d'API utilisateur.

Etant donné que les travaux de pipeline exécutent des scripts créés par l'utilisateur qui peuvent utiliser des clés d'API de service de manière arbitraire, le pipeline ne peut pas déterminer l'ensemble de restrictions à appliquer à une clé particulière. Dans ce cas, si vous demandez que le pipeline crée une clé d'API, il crée une clé d'API utilisateur. Pour maintenir une sécurité forte, utilisez à la place une clé d'API de service avec accès limité uniquement aux services et aux ressources dont vous avez besoin dans le script. Dans cette instance, vous devez créer vous-même la clé d'API. Pour plus d'informations sur la création d'une clé d'API, voir Clés d'API IBM Cloud.

Travaux

Un travail est une unité d'exécution au sein d'une étape. Une étape peut contenir plusieurs travaux et les travaux d'une étape s'exécutent de manière séquentielle. Par défaut, si un travail échoue, les travaux suivants dans cette étape ne s'exécutent pas.

Les travaux s'exécutent dans des répertoires de travail distincts au sein des conteneurs Docker qui sont créés pour chaque exécution de pipeline. Avant l'exécution d'un travail, son répertoire de travail est renseigné avec des entrées définies au niveau de l'étape. Par exemple, vous pouvez avoir une étape qui contient un travail de test et un travail de déploiement. Si vous installez des dépendances sur un travail, elles ne sont pas disponibles pour l'autre travail. Toutefois, si vous rendez les dépendances disponibles dans l'entrée de l'étape, elles sont disponibles pour les deux travaux.

A l'exception des travaux de génération de type simple, lorsque vous configurez un travail, vous pouvez inclure des scripts shell UNIX qui incluent des commandes de génération, de test ou de déploiement. Les travaux étant exécutés dans des conteneurs ad hoc, les actions sur un travail ne peuvent pas affecter les environnements d'exécution d'autres travaux, même si ces travaux font partie de la même étape.

Des exemples de scripts de compilation et de déploiement sont disponibles à l'adresse https://github.com/open-toolchain/commons.

En outre, les travaux de pipeline peuvent exécuter uniquement les commandes suivantes en tant que 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

Une fois qu'un travail est exécuté, le conteneur qui a été créé pour lui est abandonné. Les résultats de l'exécution d'un travail peuvent être conservés, mais l'environnement dans lequel ce travail a été exécuté n'est pas conservé.

L'exécution des travaux peut prendre jusqu'à 60 minutes. Lorsqu'un travail dépasse cette limite, il échoue. Si un travail dépasse la limite, scindez-le en plusieurs travaux. Par exemple, si un travail effectue trois tâches, vous pouvez le scinder en trois travaux, un pour chaque tâche.

Pour savoir comment ajouter un travail à une étape, voir Ajout d'un travail à une étape.

Travaux de génération

Les travaux de génération compilent votre projet dans le cadre de la préparation au déploiement. Ils génèrent des artefacts qui peuvent être envoyés à un répertoire d'archivage de génération, bien que par défaut, les artefacts soient placés dans le répertoire racine du projet.

Les travaux qui utilisent des entrées provenant de travaux de génération doivent faire référence à des artefacts de génération figurant dans la même structure que celle dans laquelle ils ont été créés. Par exemple, si un travail de génération procède à l'archivage d'artefacts de génération dans un répertoire output, un script de déploiement doit faire référence au répertoire output et non au répertoire cible de projet pour déployer le projet compilé. Vous pouvez spécifier le répertoire d'archivage en indiquant son nom dans la zone Répertoire d'archivage de génération. Si vous laissez la zone vide, l'archivage est effectué dans le répertoire racine.

Si vous utilisez le type de générateur Simple, votre code n'est pas compilé ni généré ; il est conditionné et rendu disponible pour des étapes ultérieures.

Travaux de déploiement

Les travaux de déploiement téléchargent votre projet vers IBM Cloud en tant qu'application et sont accessibles depuis une URL. Une fois qu'un projet est déployé, l'application déployée apparaît sur votre tableau de bord IBM Cloud.

Les travaux de déploiement peuvent déployer de nouvelles applications ou mettre à jour des applications existantes. Même si vous avez d'abord déployé une application à l'aide d'une autre méthode, vous pouvez mettre à jour l'application à l'aide d'un travail de déploiement. Pour mettre à jour une application, dans le travail de déploiement, utilisez le nom de cette application.

Vous pouvez effectuer le déploiement dans une ou plusieurs régions et dans un ou plusieurs services. Par exemple, vous pouvez configurer votre Delivery Pipeline en vue d'utiliser un ou plusieurs services, le tester dans une région, et le déployer en production dans plusieurs régions.

Travaux de test

Si vous voulez exiger que des conditions soient respectées, ajoutez des travaux de test avant ou après vos travaux de génération et de déploiement. Vous pouvez personnaliser des travaux de test pour qu'ils soient simples ou complexes selon vos besoins. Par exemple, vous pouvez exécuter une commande cURL et attendre une réponse spécifique. Vous pouvez également exécuter une suite de tests unitaires ou des tests fonctionnels avec des services de test tiers, tels que Sauce Labs.

Si vos tests génèrent des fichiers de résultats au format JUnit XML, un rapport qui s'appuie sur les fichiers de résultats apparaît dans l'onglet Tests de chaque page de résultat de test. Si un test échoue, le travail échoue également.

Propriétés d'environnement (variables d'environnement)

Un ensemble de propriétés d'environnement prédéfinies donne accès à des informations sur l'environnement d'exécution du travail. Pour obtenir une liste complète des propriétés d'environnement prédéfinies, voir Propriétés et ressources d'environnement.

Vous pouvez également définir vos propres propriétés d'environnement. Par exemple, vous pouvez définir une propriété API_KEY qui transmet une clé d'API qui est utilisée pour accéder aux ressources IBM Cloud par tous les scripts du pipeline.

Vous pouvez ajouter les types de propriétés suivants :

Texte : Clé de propriété avec une valeur monoligne.
Zone de texte : Clé de propriété avec une valeur multiligne. Une version Base64 de chaque valeur de propriété de zone de texte est également disponible. Vous pouvez accéder à cette version en utilisant le nom de la clé de propriété suivi du suffixe _base641. Vous pouvez décoder la version Base64 de la propriété Zone de texte et la répercuter en tapant echo "$(echo $multi_base64 | base64 -d)", où multi est le nom de la clé de propriété que vous avez défini et multi_base64 est la propriété supplémentaire qui est fournie. L'image de base du pipeline intègre la prise en charge pour la gestion transparente du codage multiligne. Toutefois, si vous utilisez une image personnalisée, vous devez ajouter la propriété de suffixe _base64 pour éviter que votre valeur soit tronquée par une fin de ligne.
Sécurisé : Clé de propriété avec une valeur monoligne qui est sécurisée avec le chiffrement AES-128. La valeur s'affiche sous forme d'astérisques.
Propriétés : Fichier dans le référentiel du projet. Ce fichier peut contenir plusieurs propriétés. Chaque propriété doit figurer sur sa propre ligne. Pour séparer les paires clé-valeur, utilisez le signe égal (=). Enfermez toutes les valeurs de chaîne entre guillemets. Par exemple, MY_STRING="SOME STRING VALUE".

Vous pouvez examiner les propriétés d'environnement pour un travail de pipeline en exécutant la commande env dans le script du travail.

Propriétés du pipeline

Pour définir les propriétés du pipeline, dans le menu déroulant dynamique qui apparaît sur la page Pipeline, sélectionnez Configurer le pipeline.

débordement du pipelineMenu de débordement du pipeline

Dans l'onglet Propriétés d'environnement de la page de configuration de Pipeline, définissez les propriétés d'environnement au niveau du pipeline.

propriétés du pipelinePage des propriétés du pipeline

Caractéristiques d'emplacement

Pour définir les propriétés des étapes, ouvrez la page de configuration d'Etape et cliquez sur l'onglet Propriétés d'environnement.

Vous pouvez définir une propriété d'étape en utilisant une valeur initiale (ou une valeur vide), puis en remplaçant cette valeur dans un travail en exportant une variable d'environnement. En remplaçant la valeur initiale, les travaux suivants de l'étape peuvent voir la nouvelle valeur. Par exemple, vous pouvez inclure la commande suivante pour définir la propriété $API_KEY et la rendre disponible pour un autre travail dans l'étape : export API_KEY=<insert API key here>

Propriétés calculées

Vous pouvez calculer les valeurs des propriétés d'environnement qui sont partagées entre les étapes en créant un fichier build.properties pendant que l'étape s'exécute puis faire en sorte que l'étape suivante exécute le fichier. Par exemple, votre travail de génération peut inclure la commande suivante dans le script de génération :

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

Tous les travaux commencent à exécuter le fichier build.properties, s'il existe.

Création et utilisation d'artefacts

Les travaux de génération extraient automatiquement le contenu du dossier en cours dans lequel le script utilisateur est exécuté. Si vous n'avez pas besoin de tout le contenu du référentiel git pour un déploiement ultérieur, il est préférable de configurer un répertoire de sortie explicite puis de copier ou créer les artefacts pertinents. Les scripts de travail sont exécutés dans le résultat de génération (répertoire de sortie).

Les travaux de déploiement déployés sur IBM Cloud Kubernetes Service doivent spécifier la clé d'API de plateforme d'un utilisateur sous l'autorité duquel les travaux sont exécutés, un fichier Dockerfile et éventuellement une charte Helm.

Le script de travail s'exécute après la connexion du travail à l'environnement cible à l'aide de la clé d'API de plateforme qui lui est attribuée (vous pouvez donc exécuter des commandes cf push ou kubectl dans le script).

Exemple de pipeline

Un pipeline simple peut contenir trois étapes :

Une étape de génération qui compile et exécute des processus de génération sur une application.
Une étape de test qui déploie une instance de l'application, puis exécute des tests sur cette instance.
Une étape de production qui déploie une instance de production de l'application testée.

Ce pipeline est affiché dans le diagramme conceptuel suivant :

Schéma conceptuel des étapes et des tâches d'une filière*Modèle — d'une

en trois étapes*

Les étapes prennent leur entrée dans des référentiels et des travaux de génération et les travaux au sein d'une étape s'exécutent de façon séquentielle et indépendamment les uns des autres. Dans l'exemple de pipeline, les étapes s'exécutent de manière séquentielle, même si les étapes de test et de production utilisent la sortie de l'étape de génération comme entrée.