Configuration du pipeline de livraison, de la cible et de l'automatisation

Le ou les fichiers de configuration Cloud Deploy définissent le pipeline de livraison, les cibles vers lesquelles effectuer le déploiement et leur progression.

Le fichier de configuration du pipeline de livraison peut inclure des définitions de cibles, ou celles-ci peuvent se trouver dans un ou plusieurs fichiers distincts. Par convention, un fichier contenant à la fois la configuration du pipeline de livraison et les configurations cibles s'appelle clouddeploy.yaml, et une configuration de pipeline sans cibles s'appelle delivery-pipeline.yaml. Mais vous pouvez donner à ces fichiers le nom de votre choix.

Configuration matérielle

Cloud Deploy utilise deux fichiers de configuration principaux:

Il peut s'agir de fichiers distincts, ou vous pouvez configurer le pipeline de livraison et les cibles dans le même fichier.

Structure d'un fichier de configuration de pipeline de livraison

La configuration suivante inclut une définition de cible:

# Delivery pipeline config
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
 name:
 annotations:
 labels:
description:
suspended:
serialPipeline:
 stages:
 - targetId:
   profiles: []
# Deployment strategies
# One of:
#   standard:
#   canary:
# See the strategy section in this document for details.
   strategy:
     standard:
       verify:
       predeploy:
         actions: []
       postdeploy:
         actions: []
   deployParameters:
   - values:
     matchTargetLabels:
 - targetId:
   profiles: []
   strategy:
   deployParameters:
---

# Target config
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name:
 annotations:
 labels:
description:
multiTarget:
 targetIds: []
deployParameters:
requireApproval:
#
# Runtimes
# one of the following runtimes:
gke:
 cluster:
 internalIp:
#
# or:
anthosCluster:
 membership:
#
# or:
run:
 location:
# (End runtimes. See documentation in this article for more details.)
#
executionConfigs:
- usages:
  - [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY]
  workerPool:
  serviceAccount:
  artifactStorage:
  executionTimeout:

---

# Automation config
apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name:
  labels:
  annotations:
description:
suspended:
serviceAccount:
selector:
- target:
    id:
    # or
    labels:
rules:
- [RULE_TYPE]:
  name:
  [RULE-SPECIFIC_CONFIG]

Ce fichier YAML comporte trois composants principaux:

  • Pipeline de livraison principal et progression

    Le fichier de configuration peut inclure un nombre illimité de définitions de pipeline.

  • Définitions des cibles

    Par souci de simplicité, une seule cible est présentée dans cet exemple, mais il peut y en avoir autant. Les cibles peuvent également être définies dans un ou plusieurs fichiers distincts.

  • Définitions de l'automatisation

    Vous pouvez créer toutes les automatisations de déploiement dans le même fichier que votre pipeline de livraison et vos cibles, ou dans un ou plusieurs fichiers distincts. Par souci de simplicité, une seule propriété Automation est affichée ici, mais vous pouvez en créer autant que vous le souhaitez.

Ces composants sont définis dans la suite de ce document.

Définition et progression du pipeline

En plus des métadonnées de pipeline, telles que name, la définition principale du pipeline inclut une liste de références à des cibles dans l'ordre de déploiement. Autrement dit, la première cible répertoriée est la première cible de déploiement. Une fois le déploiement sur cette cible effectué, la promotion de la version est déployée sur la cible suivante de la liste.

Vous trouverez ci-dessous les propriétés de configuration d'un pipeline de livraison, à l'exclusion des définitions de cibles.

metadata.name

Le champ name accepte une chaîne qui doit être unique par projet et par emplacement.

metadata.annotations et metadata.labels

La configuration du pipeline de livraison peut inclure des annotations et des étiquettes. Les annotations et les étiquettes sont stockées avec la ressource du pipeline de livraison une fois que le pipeline a été enregistré.

Pour en savoir plus, consultez Utiliser des étiquettes et des annotations avec Cloud Deploy.

description

Chaîne arbitraire décrivant ce pipeline de livraison. Cette description est affichée dans les détails du pipeline de livraison dans la console Google Cloud.

suspended

Valeur booléenne, qui si true suspend le pipeline de livraison de sorte qu'il ne puisse pas être utilisé pour créer, promouvoir, effectuer un rollback ou redéployer des versions. En outre, si le pipeline de livraison est suspendu, vous ne pouvez pas approuver ni refuser un déploiement créé à partir de ce pipeline.

La valeur par défaut est false.

serialPipeline

Début de la définition d'un pipeline de livraison à progression en série. Cette strophe est obligatoire.

stages

Liste de toutes les cibles sur lesquelles ce pipeline de livraison est configuré pour être déployé.

La liste doit s'afficher dans l'ordre de la séquence de diffusion souhaitée. Par exemple, si vous avez des cibles appelées dev, staging et production, répertoriez-les dans le même ordre, de sorte que votre premier déploiement soit vers dev et que votre déploiement final soit dans production.

Renseignez chaque champ stages.targetId avec la valeur du champ metadata.name dans la définition de cible correspondante. Et sous targetId, incluez profiles:

serialPipeline:
 stages:
 - targetId:
   profiles: []
   strategy:
     standard:
       verify:

targetId

Identifie l'objectif spécifique à utiliser pour cette étape du pipeline de livraison. La valeur est la propriété metadata.name de la définition de la cible.

strategy.standard.verify défini sur true active la validation du déploiement sur la cible. Si aucune stratégie de déploiement n'est spécifiée, la stratégie de déploiement standard est utilisée, avec la validation définie sur false.

profiles

Prend une liste de zéro, un ou plusieurs noms de profil Skaffold, provenant de skaffold.yaml. Cloud Deploy utilise le profil avec skaffold render lors de la création de la version. Les profils Skaffold vous permettent de varier la configuration entre les cibles tout en utilisant un seul fichier de configuration.

strategy

Inclut les propriétés permettant de spécifier une stratégie de déploiement. Les stratégies suivantes sont acceptées:

  • standard:

    L'application est entièrement déployée sur la cible spécifiée.

    Il s'agit de la stratégie de déploiement par défaut. Si vous omettez strategy, Cloud Deploy utilise la stratégie de déploiement standard.

  • canary:

    Dans un déploiement Canary, vous déployez progressivement une nouvelle version de votre application, en remplaçant la version déjà en cours d'exécution par incréments basés sur un pourcentage (par exemple, 25%, puis 50%, 75%, puis entièrement).

La stratégie de déploiement est définie par cible. Par exemple, vous pouvez avoir une stratégie Canary pour votre cible prod, mais une stratégie standard (aucune stratégie strategy spécifiée) pour vos autres cibles.

Pour en savoir plus, consultez la section Utiliser une stratégie de déploiement.

Configuration du réseau strategy

Cette section présente les éléments de configuration de strategy, pour chaque environnement d'exécution compatible.

Stratégie de déploiement standard

La stratégie standard ne nécessite que les éléments suivants:

strategy:
  standard:
    verify: true|false

La propriété verify est facultative. La valeur par défaut est false, ce qui signifie qu'il n'y aura pas de phase de vérification pour les déploiements résultants.

Vous pouvez omettre l'élément strategy dans le cas d'une stratégie de déploiement standard.

Stratégie de déploiement Canary

Les sections suivantes décrivent la configuration d'une stratégie de déploiement Canary, pour chaque environnement d'exécution compatible avec Cloud Deploy.

Pour les cibles Cloud Run
strategy:
  canary:
    runtimeConfig:
      cloudRun:
        automaticTrafficControl: true | false
    canaryDeployment:
      percentages: [PERCENTAGES]
      verify: true | false
Pour les cibles GKE et GKE Enterprise

Le fichier YAML suivant montre comment configurer une stratégie de déploiement pour une cible GKE ou GKE Enterprise, à l'aide de la mise en réseau basée sur les services:

      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              disablePodOverprovisioning: true | false
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true | false

Le fichier YAML suivant montre comment configurer une stratégie de déploiement pour une cible GKE ou GKE Enterprise à l'aide de l'API Gateway:

      canary:
        runtimeConfig:
          kubernetes:
            gatewayServiceMesh:
              httpRoute: "HTTP_ROUTE_NAME"
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              routeUpdateWaitTime: "WAIT_TIME"
        canaryDeployment:
          percentages: ["PERCENTAGES"]
          verify: true | false

Notez que dans cet exemple, routeUpdateWaitTime. Ceci est inclus, car l'API Gateway divise le trafic à l'aide d'une ressource HTTPRoute et il arrive parfois que les modifications apportées à HTTPRoute soient retardées. Dans ce cas, les requêtes peuvent être abandonnées, car le trafic est envoyé à des ressources indisponibles. Vous pouvez utiliser routeUpdateWaitTime pour que Cloud Deploy attende après l'application des modifications de HTTPRoute, si vous observez ce délai.

Le fichier YAML suivant montre comment configurer une stratégie de déploiement Canary personnalisée ou automatisée personnalisée. La configuration spécifique à l'environnement d'exécution, dans la section runtimeConfig, est omise pour les versions Canary personnalisées, mais est incluse dans les configurations Canary automatisées et personnalisées.

strategy:
       canary:
         # Runtime configs are configured as shown in the
         # Canary Deployment Strategy section of this document.
         runtimeConfig:

         # Manual configuration for each canary phase
         customCanaryDeployment:
           - name: "PHASE1_NAME"
             percent: PERCENTAGE1
             profiles: [ "PROFILE1_NAME" ]
             verify: true | false
           - …
           - name: "stable"
             percent: 100
             profiles: [ "LAST_PROFILE_NAME" ]
             verify: true|false

verify

Valeur booléenne facultative indiquant si la validation du déploiement doit être prise en charge pour cette cible. La valeur par défaut est false.

L'activation de la validation du déploiement nécessite également un bloc verify dans le skaffold.yaml. Si vous ne fournissez pas cette propriété, la tâche de validation échouera.

deployParameters

Vous permet de spécifier des paires clé/valeur afin de transmettre des valeurs aux fichiers manifestes pour les cibles correspondant à des libellés, lors de l'utilisation de paramètres de déploiement.

Vous pouvez également l'inclure dans des cibles.

Pour déployer les paramètres définis sur un pipeline de livraison, utilisez des libellés pour faire correspondre les cibles:

deployParameters:
- values:
    someKey: "value1"
  matchTargetLabels:
    label1: firstLabel
- values:
    someKey: "value2"
  matchTargetLabels:
    label2: secondLabel

Dans cet exemple, deux valeurs sont fournies pour la clé et chaque valeur est associée à un libellé. La valeur est appliquée au fichier manifeste pour toute cible dont le libellé correspond.

predeploy et postdeploy tâches

Ils vous permettent de référencer des actions personnalisées (définies séparément, dans skaffold.yaml) à exécuter avant la tâche de déploiement (predeploy) et après la tâche de vérification, le cas échéant (postdeploy). En l'absence de tâche de vérification, la tâche de postdéploiement s'exécute après la tâche de déploiement.

Les hooks de déploiement sont configurés sous strategy.standard ou strategy.canary comme suit:

serialPipeline:
  stages:
  - targetId:
    strategy:
      standard:
        predeploy:
          actions: [ACTION_NAME]
        postdeploy:
          actions: [ACTION_NAME]

Où ACTION_NAME est le nom configuré dans skaffold.yaml pour customActions.name.

Vous pouvez configurer des tâches predeploy et postdeploy sous n'importe quelle stratégie (standard, canary, par exemple).

Pour en savoir plus sur la configuration et l'utilisation des hooks avant et après le déploiement, consultez la section Exécuter des hooks avant et après le déploiement.

Définitions des cibles

Le fichier de définition du pipeline de livraison peut contenir des définitions de cibles, mais vous pouvez aussi spécifier des cibles dans un fichier distinct. Vous pouvez répéter les noms de cibles dans un projet, mais ils doivent être uniques au sein d'un pipeline de livraison.

Vous pouvez réutiliser des cibles sur plusieurs pipelines de livraison. Cependant, vous ne pouvez référencer une cible qu'une seule fois dans la progression d'un seul pipeline de livraison.

Pour les cibles GKE

Le fichier YAML suivant montre comment configurer une cible qui se déploie sur un cluster GKE:

     apiVersion: deploy.cloud.google.com/v1
     kind: Target
     metadata:
      name:
      annotations:
      labels:
     description:
     deployParameters:
     multiTarget:
      targetIds: []

     requireApproval:
     gke:
      cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
      internalIp:

     executionConfigs:
     - usages:
       - [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY]
       workerPool:
       serviceAccount:
       artifactStorage:
       executionTimeout:

metadata.name

Nom de cette cible. Ce nom doit être unique.

metadata.annotations et metadata.labels

La configuration de la cible est compatible avec les annotations Kubernetes et les étiquettes, mais Cloud Deploy ne les nécessite pas.

Les annotations et les étiquettes sont stockées avec la ressource cible. Pour en savoir plus, consultez la page Utiliser des étiquettes et des annotations avec Cloud Deploy.

description

Ce champ accepte une chaîne arbitraire qui décrit l'utilisation de cette cible.

deployParameters

Vous pouvez inclure des paramètres de déploiement sur n'importe quelle cible, avec des valeurs. Ces valeurs sont attribuées aux clés correspondantes dans votre fichier manifeste, après le rendu.

Le bloc deployParameters utilise des paires clé/valeur, comme indiqué ci-dessous:

deployParameters:
  someKey: "someValue"
  someOtherKey: "someOtherValue"

Si vous définissez des paramètres de déploiement sur un multi-target, la valeur est attribuée au fichier manifeste de toutes ses cibles enfants.

multiTarget.targetIds: []

Cette propriété est facultative et permet de configurer un multi-target à utiliser pour un déploiement parallèle.

La valeur est une liste de cibles enfants séparées par une virgule. Les cibles enfants sont configurées comme des cibles normales et n'incluent pas cette propriété multiTarget.

requireApproval

Indique si la promotion vers cet objectif nécessite une approbation manuelle. Il peut s'agir de true ou false.

Cette propriété est facultative. La valeur par défaut est false.

Lorsque vous configurez un déploiement en parallèle, vous ne pouvez exiger une approbation que pour le groupe multicible, et non pour les cibles enfants.

gke

Pour les clusters GKE uniquement, le chemin d'accès à la ressource identifiant le cluster dans lequel votre application sera déployée:

gke:
  cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]

  • project_name

    Projet Google Cloud dans lequel réside le cluster.

  • location

    Emplacement du cluster. Par exemple, us-central1. Le cluster peut également être zonal (us-central1-c).

  • cluster_name

    Nom du cluster, tel qu'il apparaît dans la liste des clusters de la console Google Cloud.

Exemple :

gke:
  cluster: projects/cd-demo-01/locations/us-central1/clusters/prod

Omettez la propriété gke lorsque vous configurez un multi-target. À la place, le cluster GKE est configuré dans la cible enfant correspondante.

Pour obtenir une description des propriétés de l'environnement d'exécution, consultez la section executionConfigs de cet article.

internalIp

Indique si le cluster GKE spécifié utilise une adresse IP privée. Cette propriété est facultative. Par défaut, Cloud Deploy utilise l'adresse IP publique du cluster. S'il existe une adresse IP privée et que vous souhaitez l'utiliser, définissez ce paramètre sur true.

Pour les cibles Cloud Run

Le fichier YAML suivant montre comment configurer une cible qui se déploie sur un service Cloud Run:

     apiVersion: deploy.cloud.google.com/v1
     kind: Target
     metadata:
      name:
      annotations:
      labels:
     description:
     multiTarget:
      targetIds: []

     requireApproval:
     run:
      location: projects/[project_name]/locations/[location]

     executionConfigs:
     - usages:
       - [RENDER | PREDEPLOY|  DEPLOY | VERIFY | POSTDEPLOY]
       workerPool:
       serviceAccount:
       artifactStorage:
       executionTimeout:

metadata.name

Nom de cette cible. Ce nom doit être unique dans chaque région.

metadata.annotations et metadata.labels

La configuration de la cible est compatible avec les annotations et les libellés, mais Cloud Deploy ne les nécessite pas.

Les annotations et les étiquettes sont stockées avec la ressource cible. Pour en savoir plus, consultez la page Utiliser des étiquettes et des annotations avec Cloud Deploy.

description

Ce champ accepte une chaîne arbitraire qui décrit l'utilisation de cette cible.

multiTarget.targetIds: []

Cette propriété est facultative et permet de configurer un multi-target à utiliser pour un déploiement parallèle.

La valeur est une liste de cibles enfants séparées par une virgule. Les cibles enfants sont configurées comme des cibles normales et n'incluent pas cette propriété multiTarget.

requireApproval

Indique si la promotion vers cet objectif nécessite une approbation manuelle. Il peut s'agir de true ou false.

Cette propriété est facultative. La valeur par défaut est false.

Lorsque vous configurez un déploiement en parallèle, vous ne pouvez exiger une approbation que pour le groupe multicible, et non pour les cibles enfants.

run

Pour les services Cloud Run uniquement, l'emplacement dans lequel le service sera créé:

run:
  location: projects/[project_name]/locations/[location]

  • project_name

    Projet Google Cloud dans lequel le service résidera.

  • location

    Emplacement du service. Par exemple, us-central1.

Omettez la propriété run lorsque vous configurez un [groupe multicible]. L'emplacement du service Cloud Run est configuré à la place dans la cible enfant correspondante.

Pour obtenir une description des propriétés de l'environnement d'exécution, consultez la section executionConfigs de cet article.

Pour les cibles GKE Enterprise

La configuration cible pour le déploiement sur un cluster GKE est semblable à la configuration d'une cible pour une cible GKE, si ce n'est que la propriété est anthosCluster.membership, au lieu de gke.cluster, le chemin d'accès à la ressource est différent et internalIp n'est pas applicable.

anthosCluster:
  membership: projects/[project_name]/locations/global/memberships/[membership_name]

  • project_name

    Projet Google Cloud dans lequel se trouve le cluster GKE Enterprise.

  • /location/global/

    Emplacement dans lequel le cluster est enregistré. global, dans tous les cas.

  • membership_name

    Nom de l'appartenance au cluster GKE Enterprise.

Exemple :

anthosCluster:
  membership: projects/cd-demo-01/locations/global/memberships/prod

Omettez la propriété anthosCluster lorsque vous configurez un [groupe multicible]. À la place, le cluster GKE Enterprise est configuré dans la cible enfant correspondante.

Pour en savoir plus sur le déploiement sur des clusters GKE, consultez la page Déployer sur des clusters d'utilisateur Anthos.

executionConfigs

Ensemble de champs permettant de spécifier un environnement d'exécution autre que celui par défaut pour cette cible.

  • usages

    RENDER ou DEPLOY (ou les deux), plus PREDEPLOY, VERIFY ou POSTDEPLOY si la validation ou les hooks de déploiement sont activés sur la cible. Ceux-ci indiquent les opérations à effectuer pour cette cible à l'aide de cet environnement d'exécution. Pour indiquer qu'un environnement d'exécution personnalisé doit être utilisé pour le hook de prédéploiement, le rendu, le déploiement, le hook de post-déploiement et la vérification, vous devez le configurer comme suit:

    usages:
- RENDER
- PREDEPLOY
- DEPLOY
- VERIFY
- POSTDEPLOY

    Si la vérification est activée à l'étape du pipeline et que vous ne spécifiez pas VERIFY dans une stanza usages, Cloud Deploy utilise l'environnement d'exécution par défaut pour la validation. Les hooks de prédéploiement et de postdéploiement fonctionnent de la même manière.

    Toutefois, s'il existe un environnement d'exécution personnalisé pour RENDER et DEPLOY, vous devez en spécifier un pour VERIFY, PREDEPLOY ou POSTDEPLOY s'ils sont configurés sur le pipeline de livraison.VERIFY, PREDEPLOY et POSTDEPLOY peuvent se trouver dans le même usages que RENDER ou DEPLOY, ou dans des usages distincts.

    Vous ne pouvez pas spécifier usages.VERIFY, usages.PREDEPLOY ni usages.POSTDEPLOY, sauf si RENDER et DEPLOY sont spécifiés dans le même environnement d'exécution personnalisé ou dans des environnements d'exécution personnalisés distincts.

  • workerPool

    Configuration du pool de nœuds de calcul à utiliser. Elle prend un chemin d'accès aux ressources identifiant le pool de nœuds de calcul Cloud Build à utiliser pour cette cible. Exemple :

    projects/p123/locations/us-central1/workerPools/wp123.

    Pour utiliser le pool Cloud Build par défaut, omettez cette propriété.

    Une cible donnée peut avoir deux workerPool (un pour RENDER et un pour DEPLOY). Lors de la configuration du pool par défaut, vous pouvez spécifier un autre compte de service et/ou un autre emplacement de stockage.

  • serviceAccount

    Nom du compte de service à utiliser pour cette opération (RENDER ou DEPLOY) pour cette cible.

  • artifactStorage

    Bucket Cloud Storage à utiliser pour cette opération (RENDER ou DEPLOY) pour cette cible, au lieu du bucket par défaut.

  • executionTimeout

    Facultatif. Définit le délai avant expiration, en secondes, des opérations effectuées par Cloud Build pour Cloud Deploy. La valeur par défaut est de 3600 secondes (1 heure).
    Exemple: executionTimeout: "5000s"

Autre syntaxe compatible

La configuration executionConfigs décrite dans ce document est nouvelle. La syntaxe précédente est toujours acceptée:

executionConfigs:
- privatePool:
    workerPool:
    serviceAccount:
    artifactStorage:
  usages:
  - [RENDER | DEPLOY]
- defaultPool:
    serviceAccount:
    artifactStorage:
  usages:
  - [RENDER | DEPLOY]

Lorsque vous configurez un bloc executionConfigs pour un élément multi-target, chaque cible enfant peut hériter de cet environnement d'exécution à partir de ce groupe multicible.

Définitions de l'automatisation

Cette section décrit les champs utilisés pour définir les ressources d'automatisation Cloud Deploy.

Comme pour les cibles, les définitions Automation peuvent être incluses dans la définition de votre pipeline de livraison, ou dans un ou plusieurs fichiers distincts.

Pour en savoir plus sur l'automatisation dans Cloud Deploy, consultez la documentation sur l'automatisation.

Le fichier YAML suivant montre comment configurer une automatisation. Notez que les spécificités d'une règle d'automatisation sont différentes pour chaque règle. Pour savoir comment configurer les types de règles d'automatisation disponibles, consultez le document Utiliser des règles d'automatisation.

apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name: [PIPELINE_NAME]/[PURPOSE]
  labels:
  annotations:
description: [DESCRIPTION]
suspended: true | false
serviceAccount: [SERVICE_ACCOUNT_ID]
selector:
- target:
    id: [TARGET_ID]
    #or
    labels: `[LABEL_KEY]:[LABEL_VALUE]`
rules:
- [RULE_TYPE]:
    name:[RULE_NAME]
  [RULE-SPECIFIC_CONFIG]

Où :

  • [PIPELINE_NAME]

    Est identique à la valeur metadata.name du pipeline de livraison qui utilise cette automatisation. Toutes les automatisations sont exclusives aux pipelines de livraison pour lesquels elles sont créées. Autrement dit, vous ne pouvez pas partager une automatisation sur plusieurs pipelines de livraison.

  • [PURPOSE]

    Nom descriptif de cette automatisation. En général, il s'agit de l'action automatisée. Par exemple, my-app-pipeline/promote.

  • labels et annotations sont des étiquettes ou des annotations que vous souhaitez associer à cette automatisation.

  • [DESCRIPTION]

    Description facultative pour cette automatisation.

  • suspended

    true ou false, qui indique si cette automatisation est active ou suspendue. Si la valeur est true, l'automatisation n'est pas utilisée. Cela peut être utile pour tester une automatisation sans affecter le pipeline de livraison.

  • [SERVICE_ACCOUNT_ID]

    ID du compte de service utilisé pour effectuer l'automatisation. Par exemple, si l'automatisation est promoteRelease, ce compte de service effectue la promotion de la version et nécessite donc les autorisations nécessaires pour promouvoir une version.

    Veuillez indiquer une valeur pour cette propriété. Cloud Deploy n'utilise pas le compte de service par défaut pour les automatisations.

    Ce compte de service doit disposer des autorisations suivantes:

    • Autorisation actAs pour emprunter l'identité du compte de service d'exécution.

    • autorisation d'effectuer l'opération automatisée, par exemple clouddeploy.releases.promote pour promouvoir une version ou clouddeploy.rollouts.advance pour avancer une phase de déploiement.

  • [TARGET_ID]

    ID de la ou des cibles pour lesquelles cette automatisation est utilisée. Bien qu'une automatisation soit liée à un pipeline de livraison, elle n'est exécutée que sur la ou les cibles spécifiées.

  • [LABEL_KEY]:[LABEL_VALUE]

    Paire clé-valeur à mettre en correspondance avec une paire clé-valeur définie sur la cible. Cette opération permet de sélectionner toutes les cibles associées au pipeline de livraison ayant le même libellé et la même valeur.

  • [RULE_TYPE]

    Nom de la règle d'automatisation utilisée pour cette automatisation. Il s'agit de promoteRelease ou advanceRollout. Vous pouvez inclure plusieurs règles dans une automatisation, dont plusieurs des mêmes RULE_TYPE. Par exemple, vous pouvez avoir plusieurs règles promoteRelease dans la même automatisation. En savoir plus

  • [RULE_NAME]

    Nom de la règle. Ce nom doit être unique dans le pipeline de livraison. Veuillez indiquer une valeur pour cette propriété.

  • [RULE-SPECIFIC_CONFIG]

    La configuration est différente pour chaque type d'automatisation compatible. Ces configurations sont présentées dans la section Utiliser des règles d'automatisation.

Étapes suivantes