Skip to content

Overview DevOps CI/CD

GCP provides the componentes required for a continuous integration pipeline.

Cloud Source Repo

The Cloud Source Repositories service provides private Git repositories hosted on Google Cloud.
These repositories let you develop and deploy anapp or service in a space that provides collaboration and version control for your code.

Cloud Build

Cloud Build executes your builds on Google Cloud infrastructure. It can import source code from Cloud Storage.
It executes your build as a series of build steps, where each build step is run in a Docker container.

A build step can do anything that can be done from a container, irrespective of the environment. There are standard steps, or you can define your own steps.

Cloud Build Trigger

A Cloud Build trigger automatically starts a build whenever you make any changes to your source code.
You can configure the trigger to build your codeon any changes to the source repository or only changes that match certain criteria.

Cloud Deploy

Cloud Deploy is a managed service that automates delivery of your applications to a series of target environments in a defined promotion sequence.

Container Registry

Container Registry is a single place for your team to manage Docker images or deployment packages, perform vulnerability analysis and decide who can.

Buildpacks - Cloud Run

If you use Cloud Run with source-based workflow, Buildpacks is used to build to container image for you.

Buildpacks :

  • provide a hands-off experience and turn your source code into a container image on autopilot.
  • are used as the build system for App Engine, Cloud Run and Cloud Function.
  • support Go, Node.js, Python, Java, and .NET Core.

CLI examples.

Managing Versions

https://cloud.google.com/architecture/application-deployment-and-testing-strategies

Deployment Strategies

Allow you to deploy new version with no downtime.

The typical configuration is to have multiple instances of a service behind a load balancer. A rolling update will then update one instance at a time.

  • If you are using instance groups, rolling updates are a built-in feature. You just define the rolling update strategy when you perform the update.
  • For Kubernetes, rolling updates are there by default. We just need to specify the replacement Docker image.
  • Finally, for App Engine, rolling updates are completely automated.

When you don't want multiple versions of a service to run simultaneously.

  • The blue deployment is the current version.
  • Create an entirely new environment (the green).
  • Once the green deployment is tested, migrate client requests to it.
  • In Compute Engine, you can use DNS to migrate requests from one LB to another.
  • In Kubernetes, configure a service to route to the new pods using labels.
  • In App Engine, use Traffic Splitting feature.
  • It failures occur, switch it back.

Can be used prior to a rolling update to reduce the risk.

  • The current version continues to run.
  • Deploy an instance of the new version and give it a portion of requests.
  • In Compute Engine, you can create a new instance group and add it as an additionnal backend in your LB.
  • In Kubernetes, create a new pods with the same labels as the existing pods, service will automatically route a portion of requests to it.
  • In App Engine, use Traffic Splitting feature.
  • Monitor for errors.

A/B testing is best used to measure the effectiveness of functionality in an application.
In A/B testing, you control your target audience for the new features.