Como 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 de forma automática. Por exemplo, você pode 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 para o destino indicado após o sucesso

no destino anterior na progressão.
timedPromoteReleaseRule Promover automaticamente de um destino para o próximo

com base em uma programação cron.
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

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. Esta seção descreve a configuração que todas as regras têm em comum, além de como configurar cada uma das regras disponíveis.

Cada regra de automação é configurada como parte da configuração do recurso de automação. Isso pode estar dentro do mesmo arquivo da configuração do pipeline de entrega relevante (normalmente chamado de clouddeploy.yaml) ou em qualquer arquivo. Saiba mais sobre como configurar automações.

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 em um destino. Por exemplo, se você tiver três destinos, poderá configurar essa regra para que, quando a versão for implantada no primeiro destino, ela seja promoverida automaticamente para o segundo.

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 uma versão para uma fase específica no destino pretendido usando a propriedade destinationPhase. A estrofe rules mostrada aqui fica dentro da definição de automação.

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 a versão automaticamente para o próximo destino depois do especificado na propriedade selector.targets nesta configuração de automação. Esse é o padrão se você omitir o valor de destinationTargetId.

  • [TO_PHASE]

    É o nome da fase para a qual você quer promover, por exemplo, canary-25 ou stable. Essa propriedade é opcional. Se você a omitir, a versão será promovida para a primeira fase no destino.

Configurar uma regra de automação timedPromoteReleaseRule

A regra timedPromoteReleaseRule permite programar quando promover uma versão do destino ou dos destinos selecionados para o próximo destino na progressão ou para um destino especificado. Ao configurar uma automação timedPromoteReleaseRule, especifique quando promover a versão com base em uma programação cron.

rules:
- timedPromoteReleaseRule:
    name: "[RULE_NAME]"
    schedule: "[CRON]"
    timeZone: "[TIME_ZONE]"
    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 pipeline de entrega.

  • [CRON]

    É a programação cron que especifica quando promover a versão. Use essa programação para especificar a data e a hora em que você quer promover o lançamento.

    Essa programação usa a sintaxe padrão cron:

    * * * * *

    Nesta programação...

    • A primeira posição é o minuto (0-59).
    • A segunda posição é a hora (0-23).
    • A terceira posição é o dia do mês (1-31).
    • A quarta posição é o mês (1-12).
    • A quinta posição é o dia da semana (0-6, domingo a sábado)

    Por exemplo, se a regra de promoção por tempo limitado incluir a seguinte programação: 0 9 * * 1, a versão será promovida toda segunda-feira às 9h.

    Também é possível usar recursos de programação cron padrão, como:

    • Um intervalo (0-5)
    • Uma lista (1,3,5)
    • Uma função de etapa (por exemplo, */3 no campo "horas" é ativada a cada três horas)

  • [TIME_ZONE]

    É o fuso horário que você quer usar para programar a promoção, no formato IANA.

  • [TO_TARGET]

    É o targetId do destino a ser promovido ou @next para promover a versão automaticamente para o próximo destino depois do destino especificado no selector.targets property nesta configuração de automação. Isso é opcional. O padrão é @next.

  • [TO_PHASE]

    É o nome da fase para a qual você quer promover a fase, por exemplo, canary-25 ou stable. Essa propriedade é opcional. Se você a omitir, a versão será promovida 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 de (o sourcePhase). A estrofe rules mostrada aqui fica dentro da definição de automação.

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]

    É o tempo, em minutos, de espera para avançar o lançamento depois que ele estiver pronto. Por exemplo, 1m O m é obrigatório.

    O valor padrão é 0, ou seja, não há 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 no lançamento serão avançadas automaticamente.

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 vezes repetir a implantação e o tempo de espera entre as tentativas. Também é possível configurar fases ou jobs específicos, ou ambos, para tentar novamente. Se cada tentativa de nova tentativa falhar, o lançamento falhará. Se uma nova tentativa tiver sucesso, a automação será interrompida e o lançamento será concluído.

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 algumas novas tentativas ou uma reversão ou ambos.

A estrofe rules mostrada aqui fica dentro da definição de automação.

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]

    É o job ou os jobs que vão ser tentados novamente. Isso é opcional, e o padrão é todos os jobs.

  • [NUMBER_OF_ATTEMPTS]

    Opcional: o número de vezes que o lançamento será repetido antes de ser considerado falha.

  • [WAIT_TIME]

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

    Se mode for linear, esse intervalo será o mesmo para cada nova tentativa. Se mode for exponential, o intervalo aumentará a cada vez. Consulte mode para mais detalhes.

  • backoffMode

    LINEAR ou EXPONENTIAL, indicando se o tempo entre as retiradas vai aumentar ou não. Se LINEAR, o tempo entre as novas tentativas é constante, em WAIT_TIME. Se EXPONENTIAL, o tempo entre as tentativas dobra a cada tentativa. 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 tentativa será de 1 minuto, o tempo entre a primeira e a segunda tentativa será de 2 minutos e o tempo entre a segunda e a terceira tentativa 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 fazer 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 todas as tentativas de repetição falharem, uma reversão será iniciada criando uma nova implantação para implantar a versão mais recente com êxito da meta.

A seguir