Skip to content
GitOps-style Continuous Delivery For Kubernetes Engine With Cloud Build
Branch: master
Clone or download
MrTrustor Hello world app + cloudbuild files
Change-Id: I694e703bda05fdad64c5ecd47ebce71a76cefd3a
Latest commit 5b55cac Dec 13, 2018
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
CONTRIBUTING.md Hello world app + cloudbuild files Jan 9, 2019
Dockerfile
LICENSE Hello world app + cloudbuild files Jan 9, 2019
README.md Hello world app + cloudbuild files Jan 9, 2019
app.py
cloudbuild-delivery.yaml Hello world app + cloudbuild files Jan 9, 2019
cloudbuild-trigger-cd.yaml
cloudbuild.yaml Hello world app + cloudbuild files Jan 9, 2019
kubernetes.yaml.tpl Hello world app + cloudbuild files Jan 9, 2019
test_app.py Hello world app + cloudbuild files Jan 9, 2019

README.md

GitOps-style Continuous Delivery For Kubernetes Engine With Cloud Build

This repository contains the code used in the GitOps-style Continuous Delivery with Cloud Build tutorial.

GitOps is a Continuous Delivery approach first described by Weaveworks that is popular in the Kubernetes community. A key part of GitOps is the idea of "environments-as-code": describing your deployments declaratively by files (for example, Kubernetes manifests) stored in a Git repository.

In this tutorial, you create a CI/CD pipeline that automatically builds a container image from commited code, stores the image in Google Container Registry, updates a Kubernetes manifest in a Git repository and triggers a deployment to Kubernetes Engine using that manifest.

This tutorial uses two Git repositories: one for the application —the app repository— and one for storing the deployment manifests —the env repository. When a change is pushed to the application repository, tests are run, a container image is built and pushed to Container Registry. Once the image is pushed, the deployment manifests are updated to use that new image and they are pushed to the candidate branch of the env repository. This triggers the actual deployment in Kubernetes. Once the deployment is finished, the new manifests are copied over to the production branch of the env repository.

In the end, you have a system where:

  • The candidate branch is a history of the deployment attempts.
  • The production branch is a history of the successful deployments.
  • You have a view of successful and failed deployments in Cloud Build.
  • You can rollback to any previous deployment by re-executing the corresponding job in Cloud Build. A rollback also updates the production branch to truthfully reflect the history of deployments.
You can’t perform that action at this time.