This document is an overview of deploy automation.

You can configure Cloud Deploy to automatically perform release-relatedand rollout-related tasks for a given delivery pipeline. These tasks includerelease promotionandphase advancement.

Learn more about the resources used forrelease automation in Cloud Deploy.

Learn more about how to set up the rules thatdefine how these automations work.

Actions you can automate

In Cloud Deploy, you can automate the following release androllout activities:

• Promote a release automatically

  You can configure Cloud Deploy to promote your releaseautomatically, upon a successful rollout to a target. For example, if youhave three targets,dev,staging, andprod, you can configure anautomation such that the release is promoted toprod, without further humaninteraction, upon a successful deployment intostaging. You can also specifya delay time.

• Promote a release on a schedule

  You can configure Cloud Deploy to promote your release accordingto a cron schedule.

• Advance a rollout

  You can configure Cloud Deploy to advance a rollout from onephase to the next,after a successful rollout to the previous target. Phase advancement isavailable only in targets that use acanary deployment strategy.

• Repair a rollout

  You can configure Cloud Deploy to automatically retry a failedrollout. This includes retrying the rollout a specified number of times, andautomatically rolling back if that number of retries fail.

SeeAutomation rules for more information onthese actions, and how to configure them.

How does automation work?

Each automation is tied to the delivery pipeline for which it's used. You can'tshare an automation across multiple delivery pipelines.

The following is the general process for configuration and execution of anautomation:

1. Youconfigure an Automation

   This automation is associated with one delivery pipeline.

2. You register that automation usinggcloud deploy apply.

   This creates theAutomation resource.

3. You invoke the delivery pipeline associated with this automation bycreating a release.

4. The rollout succeeds for at least one target, or fails.

   If the rollout succeeds, and the automation ispromoteReleaseRule:

   1. Execution waits for the rollout to succeed into the source target.The source target is theselector.targets configured for the automation,not in theAutomationRule.

   2. If there is await time configured, execution waits for that time also.

   3. The release is automatically promoted to the next target in the pipelineprogression, or to a specific target,if indicated.

   If the rollout succeeds, and the automation isadvanceRolloutRule and thetarget uses a canary deployment strategy:

   1. Execution waits for the identifiedsource phase,if there is one.

      ThesourcePhase property is optional, and if no source phases arespecified, each phase in the rollout is advanced automatically. Theautomatic phase advancement happens when the source phase isIN_PROGRESS, subject towait time.

   2. If there is await time configured, execution waits for that time also.

      When you're automating a canary deployment, you use this wait time tospecify the duration of each canary phase.

   3. The rollout is automatically advanced from that source phase to the nextphase in the rollout.

   4. If there's an additional source phase, it's treated the same, including thesame wait time, if applicable.

   If the rollout fails, and there's an automation with arepairRollout rule:

   1. The rollout is retried, after the configuredwait time, if any.

      If specific phases or jobs are configured in thisrepairRollout rule,only those phases or jobs are retried. The default, if no jobs or nophases are specified, is to retry all phases and jobs in the rollout.

      Because retries are optional, if your automation isn't configured toretry, then this step doesn't happen.

   2. If the first retry fails, execution waits for the configuredwait time,then tries again.

   3. Retries are repeated until Cloud Deploy has exhausted theretryattempts.

      If each attempt fails, and theattempts are exhausted, the rolloutfails.

      During retries, the rolloutstateisIN_PROGRESS until either the rollout succeeds or fails following thefinal retry attempt. The phasestate isIN_PROGRESS during retries, butFAILED after each rolloutfailure.

   4. If all retries fail (or none are configured), a new rollout is created torollback to the most recent successful release on the target.

• Automation

  AnAutomation is a child resource of a delivery pipeline, and it includesthe following information:

  • A pointer to the target or targets for which the automation is used
  • The rule or rules that govern what the automation does and how it does it

  Configuration for the Automation resource is described in the documentAbout the automation resource.

  When you rungcloud deploy apply against a file that includes an automationconfiguration (kind: Automation), Cloud Deploy creates anautomation resource,which associates a delivery pipeline and a target or targets with one or moreautomation rules.

• Automation run

  TheAutomationRun is an instance of an automation. It's a pointer to itscorresponding Automation resource, plus information about the rollout thatspawned it, and other metadata.

  The automation run is created when an automation is triggered.

Learn more about automation resources.

Automation rules

An automation rule defines an action that can be taken on your delivery pipelineautomatically, as well as details about how the automation is to be performed.

Learn more about automation rules.

Identity and Access Management roles and permissions required

In addition to the permissions you need to run any Cloud Deploydelivery pipeline, and to perform the tasks to be automated (like advancinga rollout), there are several permissions that are needed in order to performcertain operations on theAutomation andAutomationRun resources:

• clouddeploy.automations.create
• clouddeploy.automations.delete
• clouddeploy.automations.get
• clouddeploy.automations.list
• clouddeploy.automations.update
• clouddeploy.automationRuns.cancel
• clouddeploy.automationRuns.get
• clouddeploy.automationRuns.list

In addition to these permissions, each automation rule might require furtherpermissions to perform the automated operation. SeeConfigure automation rulesfor the specific permissions needed per automation rule.

SeeIAM roles and permissionsFor more information, including which Cloud Deployroles include these permissions.

Create an automation

You can create an automation, including using any of theavailable automation rules,by configuring an automation, then creating the automation resource usinggcloud deploy apply

See the following section (Configuring automation), andConfiguring automation rules.

Configuring automation

See theConfiguration file schemafor details on how to configure theAutomation resource.

Automation rule configuration

In addition to this automation configuration, you specifyautomation rules. Configuration is differentfor each of the available rules.

SeeUsing automation rules for descriptions of eachof the available rules.

Suspend an automation

You can suspend an existing resource without deleting it. This can be usefulfor testing an automation without affecting the delivery pipeline. When yoususpend an automation, the automation isn't run, butplatform logs are still generated.

1. In theAutomation configuration,Update thesuspended property totrue.

2. Rungcloud deploy apply against that configuration file.

3. Platform logs are still generated when theautomation is instantiated, even if it's suspended. You can use this to test anddebug the automation without affecting the delivery pipeline.

What's next

• Try thequickstart: Automate release creation and rollout advancement.

• Learn more about Cloud Deployautomation rules.

• Learn more about Cloud Deployautomation resources.

• See theconfiguration file schema documentationfor details on the automation configuration files.