Usar regras de automação

Este documento descreve as regras de automação, que são ações que podem ser realizadas no pipeline de entrega automaticamente. Por exemplo, é possível configurar seu pipeline de entrega para que a promoção para um destino específico aconteça automaticamente nas circunstâncias certas.

Só é possível usar regras de automação integradas ao Cloud Deploy. As regras de automação disponíveis estão listadas neste documento.

Regras de automação disponíveis

As seguintes regras de automação estão disponíveis no Cloud Deploy:

Regra Descrição
promoteReleaseRule Promove automaticamente uma versão no destino indicado após a conclusão

no destino anterior na progressão.
advanceRolloutRule Avançar automaticamente um lançamento a partir do indicado

fase para a próxima fase.
repairRolloutRule Tente automaticamente o job ou os jobs com falha no lançamento a

número especificado de vezes e reverter se todas as novas tentativas falharem.

Configurar regras de automação

A configuração de cada regra de automação depende da regra específica. Isso descreve as configurações que todas as regras têm em comum, além de como para configurar cada uma das regras disponíveis.

As seções a seguir descrevem a configuração específica de regras de automação individuais. Consulte Automatizar a implantação para saber como configurar a automação.

Configurar uma regra de automação promoteReleaseRule

A regra promoteReleaseRule promove sua versão após um lançamento bem-sucedido no um alvo. Por exemplo, se você tiver três metas, configure essa regra para que quando a versão for implantada com sucesso no primeiro destino, promovido automaticamente para o segundo destino.

Ao configurar uma automação promoteReleaseRule, é possível especificar um destino para promover (destinationTargetId) ou @next. Quando o lançamento terminar com sucesso no destino especificado na definição de Automation, a versão será promovida para o destino especificado em destinationTargetId, sujeito a um intervalo de tempo wait.

Também é possível promover um lançamento para uma fase específica no destino pretendido. Para isso, use a propriedade destinationPhase.

rules:
- promoteReleaseRule:
    name: "[RULE_NAME]"
    wait: [WAIT_TIME]
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

Em que:

  • [RULE_NAME]

    É qualquer nome que você quer dar a essa regra. Esse nome precisa ser exclusivo no recurso de automação.

  • [WAIT_TIME]

    É o tempo, em minutos, que você precisa esperar depois que a versão estiver pronta para ser promovida. Por exemplo, 1m O m é obrigatório.

    O valor padrão é 0, ou seja, nenhum tempo de espera. O máximo é 20160m (ou 14 dias).

  • [TO_TARGET]

    É o targetId do destino para promover.

    Também pode ser @next, que promove o lançamento automaticamente para o próximo depois da especificada na propriedade selector.targets desta configuração de automação. Esse é o padrão se você omitir o valor de destinationTargetId.

  • [TO_PHASE]

    É o nome da fase que você quer promover, por exemplo, canary-25. ou stable. Essa propriedade é opcional. se você omiti-lo, o lançamento promovido para a primeira fase no destino.

Configurar uma regra de automação advanceRolloutRule

O advanceRolloutRule avança o lançamento automaticamente após a conclusão de uma fase para a próxima. Essa regra de automação é útil para implantações canário. Por exemplo, se você tiver uma estratégia de implantação canário configurada em um destino, com fases de 25%, 50% e stable, poderá configurar uma regra de automação que avance a fase automaticamente para stable após o término da fase 50%.

Ao configurar uma automação advanceRolloutRule, você identifica a fase para avançar (o sourcePhase).

rules:
- advanceRolloutRule:
    name: "[RULE_NAME]"
    sourcePhases: ["[START_PHASE]", "[START_PHASE]"...]
    wait: [WAIT_TIME]

Em que:

  • [RULE_NAME]

    É qualquer nome que você quer dar a essa regra. Esse nome precisa ser exclusivo no pipeline de entrega.

  • [WAIT_TIME]

    É a quantidade de tempo, em minutos, de espera para avançar o lançamento após o e o lançamento está pronto. Por exemplo, 1m O m é obrigatório.

    O valor padrão é 0, ou seja, nenhum tempo de espera. O máximo é 20160m (ou 14 dias).

  • ["[START_PHASE]", "[START_PHASE]"...]

    É a fase ou fases em que o lançamento é avançado automaticamente. Ou seja, quando qualquer uma das fases listadas for concluída, o lançamento será automaticamente avançado para a próxima fase.

    Os nomes das fases diferenciam maiúsculas de minúsculas. Além disso, esses nomes de fase são opcionais. Se você omitir sourcePhases, todas as fases do lançamento serão avançadas automaticamente.

Como configurar uma regra de automação repairRolloutRule

A regra repairRolloutRule tenta novamente um lançamento com falha um número especificado de vezes. Se esse número de novas tentativas for esgotado, essa regra poderá reverter automaticamente o destino para a última versão com êxito.

Ao configurar uma automação repairRolloutRule, é possível especificar quantas tempos para tentar novamente o lançamento e o tempo de espera entre novas tentativas. Você também pode configurar fases ou jobs específicos, ou ambos, para tentar novamente. Se houver uma nova tentativa falhar, o lançamento falhará. Se alguma nova tentativa for bem-sucedida, a automação será interrompida, e a lançamento seja bem-sucedido.

Também é possível configurar a automação para reverter para a última versão bem-sucedida no destino. As novas tentativas também são opcionais, mas você precisa ter um número de novas tentativas, reversões ou ambos.

rules:
- repairRolloutRule:
    name: "[RULE_NAME]"
    phases: [PHASES_TO_REPAIR]
    jobs: [JOBS_TO_REPAIR]
    repairPhases:
    - retry:
        attempts: [NUMBER_OF_ATTEMPTS]
        wait: [WAIT_TIME]
        backoffMode: [LINEAR | EXPONENTIAL]
    - rollback:
        destinationPhase: [PHASE_NAME]

Em que:

  • [RULE_NAME]

    É qualquer nome que você quer dar a essa regra. Esse nome precisa ser exclusivo no pipeline de entrega.

  • [PHASES_TO_REPAIR]

    É a fase ou as fases de lançamento para tentar novamente. Isso é opcional, e o padrão é todas as fases do lançamento.

  • [JOBS_TO_REPAIR]

    São os jobs a serem repetidos. Isso é opcional, e o padrão são todos os jobs.

  • [NUMBER_OF_ATTEMPTS]

    Opcional. O número de vezes para tentar novamente o lançamento antes de considerá-lo falhou.

  • [WAIT_TIME]

    É o tempo de espera entre as tentativas. Por exemplo, 1m para em um intervalo de um minuto. A unidade de tempo (m, neste caso) é obrigatória.

    Se mode for linear, o intervalo será o mesmo para cada nova tentativa. Se mode for exponential, o intervalo aumenta a cada vez. Consulte mode para mais description.)

  • backoffMode

    LINEAR ou EXPONENTIAL, indicando se é necessário aumentar o tempo entre aposentados. Se for LINEAR, o tempo entre novas tentativas será constante, em WAIT_TIME. Se for EXPONENTIAL, o tempo entre novas tentativas será duplicado a cada em uma nova tentativa sucessiva. O padrão é LINEAR.

    Por exemplo, se WAIT_TIME for 1 minuto e backoffMode for definido como EXPONENTIAL, o tempo entre a falha e a primeira nova tentativa será de 1 minuto, o tempo entre a primeira e a segunda será de 2 minutos, e o tempo entre a segunda e a terceira será de 4 minutos.

  • rollback

    Opcional: reverter ou não o lançamento com falha depois que todas as tentativas de repetição forem esgotadas.

  • [PHASE_NAME]

    É o nome de uma fase específica para a qual você quer reverter. Se você omitir toPhase, a reversão vai usar a fase stable por padrão.

Interromper uma execução de automação repairRolloutRule

Se você executar qualquer um dos comandos a seguir no lançamento, a automatização repairRolloutRule será interrompida:

Exemplo

Confira a seguir um exemplo de configuração de automação com um repairRolloutRule:

apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name: regular-repair/regular
description: repair regular rollouts
suspended: false
serviceAccount: (REDACTED)
selector:
  targets:
  - id: t1
rules:
- repairRolloutRule:
    name: "repair-rollout"
    repairPhases:
    - retry:
        attempts: 3
        wait: 1m
        backoffMode: LINEAR
    - rollback:
        destinationPhase: "stable"

Nessa automação, se um lançamento falhar no destino identificado, ele será refeito até três vezes, com um minuto de espera entre as tentativas. Se todos novas tentativas falharem, uma reversão será iniciada criando um novo lançamento para implantar a versão bem-sucedida mais recente do destino para esse destino.

A seguir