Referência do esquema de configuração

Os arquivo de configuração do Cloud Deploy definem o pipeline de entrega, os destinos em que a implantação é feita e a progressão desses destinos.

O arquivo de configuração do pipeline de entrega pode incluir definições de destino ou elas podem estar em um ou mais arquivos separados. Por convenção, um arquivo que contém as configurações de pipeline de entrega e de destino é chamado de clouddeploy.yaml, e uma configuração de pipeline sem destinos é chamada de delivery-pipeline.yaml. Mas você pode dar o nome que quiser a esses arquivos.

O que vai para onde

O Cloud Deploy usa dois arquivos de configuração principais:

Eles podem ser arquivos separados, ou o pipeline de entrega e os destinos podem ser configurados no mesmo arquivo.

Estrutura de um arquivo de configuração de pipeline de entrega

A configuração a seguir inclui uma definição de destino:

# 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:
#
# or:
customTarget:
  customTargetType:
#
# (End runtimes. See documentation in this article for more details.)
#
executionConfigs:
- usages:
  - [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY]
  workerPool:
  serviceAccount:
  artifactStorage:
  executionTimeout:
---

# Custom target type config
apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name:
  annotations:
  labels:
description:
customActions:
  renderAction:
  deployAction:
  includeSkaffoldModules:
    - configs:
    # either:
    googleCloudStorage:
      source:
      path:
    # or:
    git:
      repo:
      path:
      ref:
---

# 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]

Esse YAML tem três componentes principais:

  • O principal pipeline de entrega e a progressão

    O arquivo de configuração pode incluir qualquer número de definições de canal.

  • As definições de destino

    Para simplificar, apenas um destino é mostrado neste exemplo, mas pode haver qualquer um deles. Além disso, os destinos podem ser definidos em um ou mais arquivos.

  • Definições de tipos de segmentações personalizadas

    Destinos personalizados exigem uma definição de tipo de destino personalizado. Assim como acontece com metas e automações, os tipos de destino personalizados podem ser definidos no mesmo arquivo que o pipeline de entrega ou em um arquivo separado.

  • Definições de Automation

    É possível criar qualquer automação de implantação no mesmo arquivo que o pipeline de entrega e os destinos ou em um ou mais arquivos separados. Para simplificar, apenas uma Automation é mostrada aqui, mas você pode criar quantas quiser.

Esses componentes são definidos no restante deste documento.

Definição e progressão do pipeline

Além dos metadados do pipeline, como name, a definição do pipeline principal inclui uma lista de referências a destinos na ordem de sequência de implantação. Ou seja, o primeiro destino listado é o primeiro destino de implantação. Depois de implantada no destino, a promoção da versão é implantada no próximo destino na lista.

Veja a seguir as propriedades de configuração de um pipeline de entrega, sem incluir as definições de destino.

metadata.name

O campo name usa uma string que precisa ser exclusiva por projeto e local.

metadata.annotations e metadata.labels

A configuração do pipeline de entrega pode incluir anotações e rótulos. As anotações e os rótulos são armazenados com o recurso de pipeline de entrega depois que o pipeline é registrado.

Para mais informações, consulte Como usar rótulos e anotações com o Cloud Deploy.

description

Uma string arbitrária descrevendo esse pipeline de entrega. Essa descrição é mostrada nos detalhes do pipeline de entrega no console do Google Cloud.

suspended

Um booleano, que se true suspender o pipeline de entrega para que ele não possa ser usado para criar, promover, reverter ou reimplantar versões. Além disso, se o pipeline de entrega estiver suspenso, não será possível aprovar ou rejeitar uma implementação criada com base nesse pipeline.

O padrão é false.

serialPipeline

O início da definição de um pipeline de entrega de progressão em série. Esta estrofe é obrigatória.

stages

Uma lista de todos os destinos em que esse pipeline de entrega está configurado para implantação.

A lista precisa estar na ordem em que a sequência de exibição você quer. Por exemplo, se você tiver destinos chamados dev, staging e production, liste-os na mesma ordem, de modo que a primeira implantação seja dev; sua implantação final será em production.

Preencha cada campo stages.targetId com o valor do campo metadata.name na definição de destino correspondente. E em targetId, inclua profiles:

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

targetId

Identifica o destino específico a ser usado neste estágio do pipeline de entrega. O valor é a propriedade metadata.name da definição de destino.

strategy.standard.verify definido como true ativa a verificação de implantação no destino. Se nenhuma estratégia de implantação for especificada, a estratégia de implantação standard será usada, com a verificação definida como false.

profiles

Usa uma lista de zero ou mais nomes de perfil do Skaffold do skaffold.yaml. O Cloud Deploy usa o perfil com skaffold render ao criar a versão. Os perfis do Skaffold permitem que você varie a configuração entre os destinos ao usar um único arquivo de configuração.

strategy

Inclui propriedades para especificar uma estratégia de implantação. Estas estratégias são aceitas:

  • standard:

    O aplicativo está totalmente implantado no destino especificado.

    Essa é a estratégia de implantação padrão. Se você omitir strategy, o Cloud Deploy usará a estratégia de implantação standard.

  • canary:

    Em uma implantação canário, você implanta uma nova versão do aplicativo progressivamente, substituindo a versão já em execução por incrementos baseados em porcentagem (por exemplo, 25%, depois 50%, depois 75% e então totalmente).

A estratégia de implantação é definida por destino. Por exemplo, é possível ter uma estratégia canário para o destino prod, mas uma estratégia padrão (sem strategy especificado) para as outras metas.

Para mais informações, acesse Usar uma estratégia de implantação.

Configuração strategy

Esta seção mostra os elementos de configuração de strategy para cada ambiente de execução compatível.

Estratégia de implantação padrão

A estratégia padrão inclui apenas os seguintes elementos:

strategy:
  standard:
    verify: true|false

A propriedade verify é opcional. O padrão é false, o que significa que não haverá fase de verificação para os lançamentos resultantes.

É possível omitir o elemento strategy de uma estratégia de implantação padrão.

Estratégia de implantação canário

As seções a seguir descrevem a configuração de uma estratégia de implantação canário para cada ambiente de execução compatível com o Cloud Deploy.

Para destinos do Cloud Run
strategy:
  canary:
    runtimeConfig:
      cloudRun:
        automaticTrafficControl: true | false
    canaryDeployment:
      percentages: [PERCENTAGES]
      verify: true | false
Para destinos do GKE e do GKE Enterprise

O YAML a seguir mostra como configurar uma estratégia de implantação para um destino do GKE ou do GKE Enterprise usando a rede baseada em serviço:

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

O YAML a seguir mostra como configurar uma estratégia de implantação para um destino do GKE ou do GKE Enterprise usando a 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

Observe routeUpdateWaitTime neste exemplo. Isso está incluído porque a API Gateway divide o tráfego usando um recurso HTTPRoute e, às vezes, há um atraso na propagação das alterações feitas no HTTPRoute. Nesses casos, as solicitações podem ser descartadas porque o tráfego está sendo enviado a recursos que estão indisponíveis. Use routeUpdateWaitTime para fazer com que o Cloud Deploy aguarde após aplicar alterações de HTTPRoute, se você observar esse atraso.

O YAML a seguir mostra como configurar uma estratégia de implantação canário personalizada ou automatizada. A configuração específica do ambiente de execução, na seção runtimeConfig, é omitida para o canário personalizado, mas é incluída na configuração canário automatizada e personalizada.

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

Booleano opcional que indica se há compatibilidade ou não com a verificação de implantação para o destino. O padrão é false.

A ativação da verificação da implantação também requer uma estrofe verify em skaffold.yaml. Se você não fornecer essa propriedade, o job de verificação falhará.

deployParameters

Permite especificar pares de chave-valor para transmitir valores a manifestos de destinos com correspondência de rótulo ao usar parâmetros de implantação.

Você também pode incluir isso nos destinos.

Implante os parâmetros definidos em um pipeline de entrega usando rótulos para corresponder aos destinos:

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

Neste exemplo, há dois valores fornecidos para a chave e, para cada valor, há um rótulo. O valor é aplicado ao manifesto para qualquer destino que tenha um rótulo correspondente.

jobs predeploy e postdeploy

Isso permite que você faça referência a ações personalizadas (definidas separadamente, em skaffold.yaml) para serem executadas antes do job de implantação (predeploy) e depois do job de verificação, se presente (postdeploy). Se não houver um job de verificação, o job de pós-implantação será executado após o de implantação.

Os hooks de implantação são configurados em strategy.standard ou strategy.canary da seguinte maneira:

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

Em que ACTION_NAME é o nome configurado em skaffold.yaml para customActions.name.

É possível configurar jobs predeploy e postdeploy em qualquer estratégia (standard, canary, por exemplo).

Para mais informações sobre como configurar e usar hooks de pré e pós-implantação, consulte Executar hooks antes e depois da implantação.

Definições de destino

O arquivo de definição do pipeline de entrega pode conter definições de destino ou é possível especificar destinos em um arquivo separado. É possível repetir nomes de destino em um projeto, mas eles precisam ser exclusivos em um pipeline de entrega.

É possível reutilizar destinos entre vários pipelines de entrega. No entanto, só é possível referenciar um destino uma vez a partir da progressão de um único pipeline de entrega.

Consulte também: Definições de tipos de segmentações personalizadas

Para destinos do GKE

O YAML a seguir mostra como configurar um destino que é implantado em um cluster do 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

O nome dessa segmentação. Esse nome precisa ser globalmente exclusivo.

metadata.annotations e metadata.labels

A configuração de destino oferece suporte a anotações do Kubernetes e rótulos, mas o Cloud Deploy não as exige.

Anotações e rótulos são armazenados com o recurso de destino. Para mais informações, consulte Como usar rótulos e anotações com o Cloud Deploy.

description

Esse campo usa uma string arbitrária que descreve o uso desse destino.

deployParameters

É possível incluir parâmetros de implantação em qualquer destino, junto com os valores. Esses valores são atribuídos às chaves correspondentes no seu manifesto após a renderização.

A estrofe deployParameters aceita pares de chave-valor, conforme mostrado:

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

Se você definir parâmetros de implantação em multi-target, o valor será atribuído ao manifesto para todos os destinos filhos desses destinos múltiplos.

multiTarget.targetIds: []

Essa propriedade é opcional e é usada para configurar um multi-target a ser usado para implantação paralela.

O valor é uma lista separada por vírgulas de destinos filhos. Destinos filhos são configurados como destinos normais e não incluem essa propriedade multiTarget.

requireApproval

Indica se a promoção para esta meta requer aprovação manual. Pode ser true ou false.

Esta propriedade é opcional. O padrão é false.

Ao configurar a implantação paralela, é possível exigir aprovação somente nos destinos múltiplos, e não nos filhos.

gke

Apenas para clusters do GKE, o caminho do recurso que identifica o cluster em que seu aplicativo será implantado:

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

    O projeto do Google Cloud em que o cluster reside.

  • location

    O local em que o cluster reside. Por exemplo, us-central1 O cluster também pode ser zonal (us-central1-c).

  • cluster_name

    O nome do cluster, como aparece na lista de clusters no console do Google Cloud.

Veja um exemplo:

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

Omita a propriedade gke ao configurar um multi-target. O cluster do GKE é configurado dentro do destino filho correspondente.

Consulte executionConfigs, neste artigo, para descrições das propriedades do ambiente de execução.

internalIp

Se o cluster do GKE especificado usa ou não um endereço IP particular. Esta propriedade é opcional. Por padrão, o Cloud Deploy usa o endereço IP disponível publicamente para o cluster. Se houver um endereço IP particular e você quiser usá-lo, defina-o como true.

Para destinos do Cloud Run

O YAML a seguir mostra como configurar um destino que implanta em um serviço do 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

O nome dessa segmentação. Esse nome precisa ser exclusivo por região.

metadata.annotations e metadata.labels

A configuração de destino aceita anotações e rótulos, mas o Cloud Deploy não os exige.

Anotações e rótulos são armazenados com o recurso de destino. Para mais informações, consulte Como usar rótulos e anotações com o Cloud Deploy.

description

Esse campo usa uma string arbitrária que descreve o uso desse destino.

multiTarget.targetIds: []

Essa propriedade é opcional e é usada para configurar um multi-target a ser usado para implantação paralela.

O valor é uma lista separada por vírgulas de destinos filhos. Destinos filhos são configurados como destinos normais e não incluem essa propriedade multiTarget.

requireApproval

Indica se a promoção para esta meta requer aprovação manual. Pode ser true ou false.

Esta propriedade é opcional. O padrão é false.

Ao configurar a implantação paralela, é possível exigir aprovação somente nos destinos múltiplos, e não nos filhos.

run

Apenas para os serviços do Cloud Run, o local em que o serviço será criado:

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

    O projeto do Google Cloud em que o serviço residirá.

  • location

    O local onde o serviço ficará. Por exemplo, us-central1

Omita a propriedade run ao configurar um [vários destinos]. O local do serviço do Cloud Run é configurado dentro do destino filho correspondente.

Consulte executionConfigs, neste artigo, para descrições das propriedades do ambiente de execução.

Para destinos do GKE Enterprise

A configuração de destino para implantar em um cluster do GKE é semelhante a configurar um destino para um destino do GKE, exceto pelo fato de que a propriedade é anthosCluster.membership, em vez de gke.cluster, o caminho do recurso é diferente e internalIp não é aplicável.

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

    O projeto do Google Cloud em que o cluster do GKE Enterprise reside.

  • /location/global/

    O local em que o cluster está registrado. global, em todos os casos.

  • membership_name

    O nome da assinatura do cluster do GKE Enterprise.

Veja um exemplo:

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

Omita a propriedade anthosCluster ao configurar um [vários destinos]. O cluster do GKE Enterprise é configurado dentro do destino filho correspondente.

Para mais informações sobre como implantar clusters do GKE, consulte Como implantar em clusters de usuários do Anthos.

Para segmentações personalizadas

A configuração de destinos personalizados é semelhante a todos os outros tipos de destino, exceto pelo fato de não incluir uma estrofe gke, run e anthosCluster.

Em vez disso, os destinos personalizados incluem uma estrofe customTarget:

customTarget:
  customTargetType: [CUSTOM_TARGET_TYPE_NAME]

Em que CUSTOM_TARGET_TYPE_NAME é o nome que você usou na definição do tipo de destino personalizado.

Veja um exemplo:

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: sample-env
customTarget:
  customTargetType: basic-custom-target

executionConfigs

Um conjunto de campos para especificar um ambiente de execução não padrão para esse destino.

  • usages

    RENDER ou DEPLOY ou ambos, além de PREDEPLOY, VERIFY ou POSTDEPLOY se a verificação ou os hooks de implantação estiverem ativados no destino. Eles indicam quais das operações realizar para esse destino usando esse ambiente de execução. Para indicar que um ambiente de execução personalizado será usado para pré-implantação do hook, da renderização, da implantação, do hook de pós-implantação e da verificação, configure-o da seguinte maneira:

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

    Se a verificação estiver ativada no estágio do pipeline e você não especificar VERIFY em uma estrofe usages, o Cloud Deploy vai usar o ambiente de execução padrão. Os hooks de pré e pós-implantação funcionam da mesma maneira.

    No entanto, se houver um ambiente de execução personalizado para RENDER e DEPLOY, será necessário especificar um para VERIFY, PREDEPLOY ou POSTDEPLOY se eles estiverem configurados no pipeline de entrega.VERIFY, PREDEPLOY e POSTDEPLOY podem estar no mesmo usages que RENDER ou DEPLOY ou em usages separados.

    Não é possível especificar usages.VERIFY, usages.PREDEPLOY ou usages.POSTDEPLOY, a menos que RENDER e DEPLOY sejam especificados em ambientes de execução personalizados ou separados.

  • workerPool

    Configuração para o pool de workers a ser usado. Isso usa um caminho de recurso que identifica o pool de workers do Cloud Build a ser usado para esse destino. Exemplo:

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

    Para usar o pool padrão do Cloud Build, omita essa propriedade.

    Um determinado destino pode ter dois workerPools (um para RENDER e outro para DEPLOY). Ao configurar o pool padrão, é possível especificar uma conta de serviço alternativa ou um local de armazenamento ou ambos.

  • serviceAccount

    O nome da conta de serviço a ser usada para esta operação (RENDER ou DEPLOY) para o destino.

  • artifactStorage

    O bucket do Cloud Storage a ser usado nesta operação (RENDER ou DEPLOY) para o destino, em vez do bucket padrão.

  • executionTimeout

    Opcional. Define o tempo limite, em segundos, das operações que o Cloud Build realiza para o Cloud Deploy. Por padrão, o tempo é de 3600 segundos (1 hora).
    Exemplo: executionTimeout: "5000s"

Sintaxe alternativa compatível

A configuração executionConfigs descrita neste documento é nova. A sintaxe anterior ainda é compatível:

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

Ao configurar uma estrofe executionConfigs para um multi-target, cada destino filho pode herdar esse ambiente de execução desse destino.

Definições de tipos de segmentações personalizadas

Nesta seção, descrevemos os campos usados para definir tipos de segmentações personalizadas.

Assim como nas automações e metas padrão, as definições de CustomTargetType podem ser incluídas com a definição do pipeline de entrega ou em um ou mais arquivos separados.

O YAML a seguir mostra como configurar um tipo de destino personalizado:

apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name: [CUSTOM_TARGET_TYPE_NAME]
  annotations:
  labels:
description:
customActions:
  renderAction: [RENDER_ACTION_NAME]
  deployAction: [DEPLOY_ACTION_NAME]
  includeSkaffoldModules:
    - configs:
    # either:
    googleCloudStorage:
      source:
      path:
    # or:
    git:
      repo:
      path:
      ref:

Em que:

  • [CUSTOM_TARGET_TYPE_NAME]

    É um nome arbitrário que você atribui a essa definição de tipo de destino personalizado. Esse nome é referenciado na definição de destino para qualquer destino que use o tipo de destino personalizado que você está definindo.

  • [RENDER_ACTION_NAME]

    É o nome da ação de renderização personalizada. Esse valor é o customAction.name definido em skaffold.yaml.

  • [DEPLOY_ACTION_NAME]

    É o nome da ação de implantação personalizada. Esse valor é o customAction.name definido em skaffold.yaml.

  • Para includeSkaffoldModules, consulte Usar configurações remotas do Skaffold.

Definições de Automation

Nesta seção, descrevemos os campos usados para definir os recursos de automação do Cloud Deploy.

Assim como nos destinos, as definições de Automation podem ser incluídas com a definição do pipeline de entrega ou em um ou mais arquivos separados.

Para mais informações sobre automação no Cloud Deploy, consulte a documentação sobre automação.

O YAML a seguir mostra como configurar uma automação. As especificidades de uma regra de automação são diferentes por regra. A configuração dos tipos de regra de automação disponíveis está no documento Como usar regras de automação.

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]

Em que:

  • [PIPELINE_NAME]

    É igual ao valor metadata.name no pipeline de entrega que usa essa automação. Todas as automações são exclusivas dos pipelines de entrega para os quais são criadas. Ou seja, não é possível compartilhar uma automação em mais de um pipeline de entrega.

  • [PURPOSE]

    É qualquer nome descritivo para essa automação. Normalmente, essa é a ação automatizada. Por exemplo, my-app-pipeline/promote

  • labels e annotations são os rótulos ou anotações que você quer associar a essa automação.

  • [DESCRIPTION]

    É uma descrição opcional para essa automação.

  • suspended

    true ou false, indicando se essa automação está ativa ou suspensa. Se definido como true, a automação não será usada. Isso pode ser útil para testar uma automação sem afetar o pipeline de entrega.

  • [SERVICE_ACCOUNT_ID]

    É o ID da conta de serviço usada para executar a automação. Por exemplo, se a automação for promoteRelease, essa conta de serviço realizará a promoção de lançamento e, portanto, exigirá as permissões necessárias para promover uma versão.

    É necessário um valor para esta propriedade. O Cloud Deploy não usa a conta de serviço padrão para automações.

    Essa conta de serviço precisa ter as seguintes permissões:

    • Permissão actAs para representar a conta de serviço de execução.

    • permissão para executar a operação que está sendo automatizada, por exemplo, clouddeploy.releases.promote para promover uma versão ou clouddeploy.rollouts.advance para avançar uma fase de lançamento.

  • [TARGET_ID]

    É o ID das segmentações em que essa automação é usada. Embora uma automação esteja vinculada a um pipeline de entrega, ela só é executada nos destinos especificados.

  • [LABEL_KEY]:[LABEL_VALUE]

    É um par de chave-valor que corresponde a um par de chave-valor definido no destino. Essa opção seleciona todos os destinos associados ao pipeline de entrega que tenham o mesmo rótulo e valor.

  • [RULE_TYPE]

    É o nome da regra de automação usada para essa automação. Ele é promoteRelease ou advanceRollout. Você pode incluir mais de uma regra em uma automação, inclusive mais de uma regra do mesmo RULE_TYPE. Por exemplo, é possível ter mais de uma regra promoteRelease na mesma automação. Saiba mais

  • [RULE_NAME]

    Um nome para a regra. Esse nome precisa ser exclusivo no pipeline de entrega. É necessário um valor para esta propriedade.

  • [RULE-SPECIFIC_CONFIG]

    A configuração é diferente para cada tipo de automação compatível. Essas configurações são mostradas em Como usar regras de automação.

A seguir