If you are here, then you’ve surely heard about GitOps. Your colleagues rave on about it, perhaps folks in your office whisper it about, or you sat on the bus next to some chap who does ‘use’ GitOps.

Have a read of GitOps Processes and Integration with flux which was recently written by my colleague Sean Rigby which has great coverage of a high-level overview of the topic.

Otherwise, let’s recap the features and dive deeper into components and implementation.

The key features of GitOps implemetnation

Strong release consistency and standardisation across environments — You are guaranteed to have your GitHub sourced definition running by design.

Strong Audit Trail — PR approved, Git history tracked, great visibility too.

Stronger Reliability and Stability — the result of the standardised release process and consistent deployment architecture

Improved Developer Experience — Build every commit, any branch, you decide. Configure your Triggers as you see fit

Forced Application Quality Ownership — in line with Agile Practices. You build, you Ship.

Improved Productivity as a result — more releases, small incremental deliverables at your approval

The technology pre-requisites of the #GitOps release model are Google Kubernetes Engine, Cloud Build, and good ol’ GitHub. There are likely to be implementations of the same with the other cloud providers too.

So you like what you hear. Good, we still have you then. Let’s get you some of that goodness. Let’s recap the epic features and benefits of such a CI/CD approach

The Realised benefits of the GitOps CI/CD pipeline(s)

The simplified and automated release pipeline

Abstracted the opinionated release process from the developer, and the release team

Reduce the self-managed tool maintenance and dependencies

Use generic best-practice patterns to carry out releases

Reduce ClickOps — it’s a real thing. (You click, click, click some more, then some release happens. Then you verify it Did happen)

— it’s a real thing. (You click, click, click some more, then some release happens. Then you verify it Did happen) Enforce the desired remote state of the repository to live

This is the “Get #GitOps done on GCP” guide with “3 easy steps”. I will cover the Component details, as well as deep dive into How-To in the latter section

There are 3 Fundamental Components to #GitOps, used to build up what is a CI/CD model, which comprises of the following:

Continuous Deployment Tool — I use Weaveworks Flux — to pull Release-Env Deployment Repository and apply [all] changes compared to the present state. There are alternatives like ArgoCD of course The Continuous Integration Component — comprises of a Code Repository (GitHub) which contains all the application source code as truth, Integrated with CloudBuild, and appropriate triggers. The CI/CD Release Strategy, The GitOps Logic, to perform releases for aforementioned CI builds, for CD component to pickup automatically

The 3 “Easy” Steps to getting GitOps CI/CD Model

1 — Configure The Continuous Deployment

I use Weaveworks flux — This step Configure & Deploy Flux on GKE. The detailed how-to is already blogged by Sean Rigby

Apply the whole list of Yaml Manifests, the very Deployment, Account, Memcached Deployment & Service and The secret will feature the github <manifests-deployment-repository>:branch to pull and kubectl apply -f . manifests from.

2 — Integrate Source Repository with CloudBuild

The following cloud repositories are supported with CloudBuild integration: GitHub, BitBucket and Cloud Repositories (Google’s own offering)

The Process is relatively simple. Follow it through and select the application repository which needs to be connected.

Next, you need to configure that bit with a trigger to “Do Stuff” on Merge/Commit. This is where you configure your Trigger.

I have configured my trigger to use cloudbuild.yaml for a particular branch: master events.

You can configure your Trigger to Cloudbuild Dockerfile and automatically build when you introduce changes for example. The reason we specify the cloudbuild.yaml instead — as the name suggests — this allows us to define more scope for the CloudBuild to do.

This is it. Each time you introduce a change to the master branch, CloudBuild will perform a run, executing steps within that cloudbuild.yaml definition. What is inside the file you say? Well, that gem is for the next section of #GitOps.

3 — CI/CD Release Strategy — The GitOps logic

The foundation here is that this GitOps logic will operate as just yet another cloudbuild.yaml featured build step for the application.

It will run as a separate image hosting that “logic script of GitOps” of operations that we wish to perform. What are those operations, how do we access yet another <deployment-repository> despite building from the <application-repository> All Good questions. This is what we need to incorporate into the gitops image.

Decrypt SSH Key Secret for the Flux(CD component) operated GitHub <deployment-repository>

SSH Key Secret for the Flux(CD component) operated GitHub Update the Deployment Application Build Hash for the development branch of the <deployment-repository>

Application Build Hash for the branch of the Optional Bonus: Create Merge Pull Requests for the same Application Build Hash for Staging/Production branches of the <deployment-repository>

Additional Release strategy to consider: Trigger for Development Branch(es). Food for thought. Many ways to skin this cat. Let me know your thoughts in the comments section below.

Meanwhile, let’s get a visual on this: