Automate your deployments

Last reviewed 2023-07-17 UTC

This document in the Google Cloud Architecture Framework provides best practices for automating your builds, tests, and deployments.

Automation helps you standardize your builds, tests, and deployments by eliminating human-induced errors for repeated processes like code updates. This section describes how to use various checks and guards as you automate. A standardized machine-controlled process helps ensure that your deployments are applied safely. It also provides a mechanism to restore previous deployments as needed without significantly affecting your user's experience.

Store your code in central code repositories

Store your code in central code repositories that include a version control system with tagging and the ability to roll back code changes. Version control lets you organize files and control access, updates, and deletion across teams and organizations.

For different stages of development, version and label the repositories as needed. For example, labels could be test, dev, and prod.

In Google Cloud, you can store your code in Cloud Source Repositories, and version and integrate them with other Google Cloud products. If you are building containerized applications, use Artifact Registry, a managed registry for containers.

For more details about version control, see Version control. For details about implementing trunk-based development with your repositories, see Trunk-based development.

Use continuous integration and continuous deployment (CI/CD)

Automate your deployments using a continuous integration and continuous deployment (CI/CD) approach. A CI/CD approach is a combination of pipelines that you configure and processes that your development team follows.

A CI/CD approach increases deployment velocity by making your software development team more productive. This approach lets developers make smaller and more frequent changes that are thoroughly tested while reducing the time needed to deploy those changes.

As part of your CI/CD approach, automate all the steps that are part of building, testing, and deploying your code. For example:

  • Whenever new code is committed to the repository, have the commit automatically invoke the build and test pipeline.
  • Automate integration testing.
  • Automate your deployment so that changes deploy after your build meets specific testing criteria.

In Google Cloud, you can use Cloud Build and Cloud Deploy for your CI/CD pipelines.

Use Cloud Build to help define dependencies and versions that you can use for packaging and building an application package. Version your build configuration to make sure all your builds are consistent, and to make sure you can roll back to a previous configuration if necessary.

Use Cloud Deploy to deploy your applications to specific environments on Google Cloud, and to manage your deployment pipelines.

For more details about implementing CI/CD, read Continuous integration and Deployment automation.

Provision and manage your infrastructure using infrastructure as code

Infrastructure as code is the use of a descriptive model to manage infrastructure, such as VMs, and configurations, such as firewall rules. Infrastructure as code lets you do the following:

  • Create your cloud resources automatically, including the deployment or test environments for your CI/CD pipeline.
  • Treat infrastructure changes like you treat application changes. For example, ensure changes to the configuration are reviewed, tested, and can be audited.
  • Have a single version of the truth for your cloud infrastructure.
  • Replicate your cloud environment as needed.
  • Roll back to a previous configuration if necessary.

This concept of infrastructure as code also applies to projects in Google Cloud. You can use this approach to define resources such as Shared VPC connectivity or Identity and Access Management (IAM) access in your projects. For an example of this approach, see the Google Cloud Project Factory Terraform Module.

Third-party tools, like Terraform, help you to automatically create your infrastructure on Google Cloud. For more information, see Managing infrastructure as code with Terraform, Cloud Build, and GitOps.

Consider using Google Cloud features, such as project liens, Cloud Storage retention policies, and Cloud Storage bucket locks, to protect critical resources from being accidentally or maliciously deleted.

Incorporate testing throughout the software delivery lifecycle

Testing is critical to successfully launching your software. Continuous testing helps teams create high-quality software faster and enhance software stability.

Testing types:

  • Unit tests. Unit tests are fast and help you perform rapid deployments. Treat unit tests as part of the codebase and include them as part of the build process.
  • Integration tests. Integration tests are important, especially for workloads that are designed for scale and dependent on more than one service. These tests can become complex when you test for integration with interconnected services.
  • System tests. System tests are time consuming and complex, but they help you identify edge cases and fix issues before deployment.
  • Other tests. There are other tests you should run, including static testing, load testing, security testing, policy validation testing, and others. Run these tests before deploying your application in production.

To incorporate testing:

  • Perform all types of testing continuously throughout the software delivery lifecycle.
  • Automate these tests and include them in the CI/CD pipeline. Make your pipeline fail if any of the tests fail.
  • Update and add new tests continuously to improve and maintain the operational health of your deployment.

For your testing environments:

  • Use separate Google Cloud projects for each test environment you have. For each application, use a separate project environment. This separation provides a clear demarcation between production environment resources and the resources of your lower environments. This separation helps ensure that any changes in one environment don't accidentally affect other environments.
  • Automate the creation of test environments. One way to do this automation is using infrastructure as code.
  • Use a synthetic production environment to test changes. This environment provides a production-like environment to test your application and perform various types of tests on your workloads, including end-to-end testing and performance testing.

For more information about implementing continuous testing, see Test automation.

Launch deployments gradually

Choose your deployment strategy based on important parameters, like minimum disruption to end users, rolling updates, rollback strategies, and A/B testing strategies. For each workload, evaluate these requirements and pick a deployment strategy from proven techniques, such as rolling updates, blue/green deployments, and canary deployments.

Only let CI/CD processes make and push changes in your production environment.

Consider using an immutable infrastructure. An immutable infrastructure is an infrastructure that isn't changed or updated. When you need to deploy new code or change any other configuration in your environment, you replace the entire environment (a collection of VMs, or Pods for example) with the new environment. Blue/green deployments are an example of immutable infrastructure.

We recommend that you do canary testing and observe your system for any errors as you deploy changes. This type of observation is easier if you have a robust monitoring and alerting system. To do A/B testing or canary testing, you can use Google Cloud's managed instance groups.. Then you can perform a slow rollout, or a restoration if necessary.

Consider using Cloud Deploy to automate deployments and manage your deployment pipeline. You can also use many third-party tools, like Spinnaker and Tekton, on Google Cloud for both automated deployments and for creating deployment pipelines.

Restore previous releases seamlessly

Define your restoration strategy as part of your deployment strategy. Ensure that you can roll back a deployment, or an infrastructure configuration, to a previous version of the source code. Restoring a previous stable deployment is an important step in incident management for both reliability and security incidents.

Also ensure that you can restore the environment to the state it was in before the deployment process started. This can include:

  • The ability to revert any code changes in your application.
  • The ability to revert any configuration changes made to the environment.
  • Using immutable infrastructure and ensuring that deployments don't change the environment. These practices make reverting configuration changes easier.

Monitor your CI/CD pipelines

To keep your automated build, test, and deploy process running smoothly, monitor your CI/CD pipelines. Set alerts that indicate when anything in any pipeline fails. Each step of your pipeline should write suitable log statements so that your team can perform root cause analysis if a pipeline fails.

In Google Cloud, all the CI/CD services are integrated with Google Cloud Observability. For example:

For details about monitoring and logging, see Set up monitoring, alerting, and logging.

Deploy applications securely

Review the Deploy applications securely section from the security, compliance and privacy category of the Architecture Framework.

Establish management guidelines for version releases

To help your engineers avoid making mistakes, and to enable high-velocity software delivery, ensure that your management guidelines for releasing new software versions are clearly documented.

Release engineers oversee how software is built and delivered. The system of release engineering is guided by four practices:

  • Self-service mode. Establish guidelines to help software engineers avoid common mistakes. These guidelines are generally codified in automated processes.

  • Frequent releases. High velocity helps troubleshooting and makes fixing issues easier. Frequent releases rely on automated unit tests.

  • Hermetic builds. Ensure consistency with your build tools. Version the build compilers you use to build versions now versus one month ago.

  • Policy enforcement. All changes need code review, ideally including a set of guidelines and policy to enforce security. Policy enforcement improves code review, troubleshooting, and testing a new release.

What's next