Continuous Delivery Service provides declarative builds that persist with a given release, support for connecting external workflows, and detailed security and auditing controls, as reported on InfoQ.

Delivery pipelines and delivery targets from Google Cloud Deploy are defined declaratively.

Matt Campbell, an Engineering Director at D2L, further explains in an InfoQ article that 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.

Google Cloud Deploy also provides declarative and retained builds 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 be updated, but it will only affect future releases.

Google Cloud Deploy documentation noted:

“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.

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:

Approval of the rollout can then be done via gcloud by a user with the role roles/clouddeploy.approver:

In fact, Matt Campbell further explains that Pub/Sub can be used to automate promotion steps in a release by listening to messages from the topic cloud deploy-operations. When receiving a success message, additional workflow steps such as testing can be run. Once those steps are complete, the release can be promoted to the next stage by calling:

There are a number of metrics tracked automatically by Google Cloud Deploy, such as 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).

Continuous delivery is a key part of how organizations deliver value to their customers, providing the ability to make small changes to software reliably and at any time, according to the report.

The study, completed by research firm SlashData from data collected from more than 19,000 developers, asked for information on lead time for changes, deployment frequency, time to restore services, and change fail rates.

Two-thirds of respondents indicated it takes at least a week for code to go from committed to successfully run in production. Only about 6%  said they can move code from commit to production in under an hour.

The programming languages that rank highest for speed and stability in software delivery performance are the shell scripting languages (Bash and PowerShell). Go/Golang and JavaScript are the next best choices. Interestingly, Ruby, Python and Java — three of the most popular languages based on Tiobe rankings, were poorest in terms of software delivery performance. According to Tracy Miranda, Continuous Delivery Foundation executive director:

“Having access to new relevant data is critical to assessing and making the right decisions. By building this State of CD Report, we have produced an exclusive dashboard for use by our community that shows the current state of continuous delivery for deployment frequency, lead time for changes, time to restore service, and more.”

Tracy added that they will publish this report annually to track the world’s capacity to deliver software with speed and security.