Google has announced the GA release of Google Cloud Deploy, their managed continuous delivery service for Google Kubernetes Engine. The service provides declarative builds that persist with a given release, support for connecting external workflows, and detailed security and auditing controls.
Within Google Cloud Deploy, delivery pipelines and delivery targets are defined declaratively. Delivery pipelines are the definition of the workflow that delivers the application to each target in a deployment progression. A target is a specific Kubernetes cluster into which to deploy the application coupled with the configuration for the environment. Google Cloud Deploy uses Skaffold to render the Kubernetes manifests. Skaffold supports rendering raw manifests as well as manifests from tools such as Helm, Kustomize, and kpt.
One key feature of Google Cloud Deploy is that builds are declarative and retained with each release. When a new release is promoted, the pipeline and targets are preserved in their current state for that release. The delivery pipeline and target definitions files can still be updated, but it will only affect future releases. As noted in the Google Cloud Deploy documentation: "this preservation prevents recent changes to the delivery pipeline definition from affecting the release in ways the generated manifests might not be able to accommodate."
The delivery pipeline configuration file is the main configuration file for Google Cloud Deploy. By convention, it is in a file called clouddeploy.yaml when combined with the associated targets. It is possible to define target definitions in their own file but it should be noted that target names must be unique within a delivery pipeline.
Release approvals can be done via the Console or set up to work through third-party workflow management systems using Pub/Sub and the Google Cloud Deploy API. To require approval on a target, the requireApproval property should be set to true in the target configuration:
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name:
description:
requireApproval: true
Approval of the rollout can then be done via gcloud by a user with the role roles/clouddeploy.approver:
gcloud deploy rollouts approve rollout-name --delivery-pipeline=pipeline-name
Pub/Sub can be used to automate promotion steps in a release by listening to messages from the topic clouddeploy-operations. Upon receiving a success message, additional workflow steps such as testing can be run as needed. Once those steps are complete, the release can be promoted to the next stage by calling:
gcloud deploy releases promote RELEASE_NAME \
--delivery-pipeline=PIPELINE_NAME \
--region=REGION \
--annotations=KEY=VALUE,...
For auditing purposes, Cloud Audit Logs centrally tracks user-invoked Google Cloud Deploy activities. Access can be controlled through IAM including determining which roles have execution level capabilities.
There are a number of metrics tracked automatically by Google Cloud Deploy. This includes deployment history, deployment success, and deployment frequency. Metrics are measured by delivery pipeline and are for deployments to production targets (the final target in the progression).
More information on the release can be found within the announcement post and on the product page. The first active delivery pipeline per account is free of charge however there is a charge of $15.00 per month for each additional delivery pipeline within an account.