Short - Gitops, releases

Gitops

In this first series of shorts I want to address gitops and why I love it. Gitops for me is the missing link into automating deployments. Let me try to explain the difference between CD and Gitops. CD is a push mechanism where the artifact is forced onto the delivery point and gitops pulls the artifact into that point. By changing that perspective you have to define what needs to be deployed instead of just pushing the result/artifact onto the cluster. This creates a state for the cluster to be in just as kubernetes does. In this way you don’t have to deep dive into your cluster to see what is running. You can easily check a git repository and know what is running if it is in sync of course ;)

There are a couple of benefits that comes with this tactic * Recreate a whole cluster from scratch without redoing all the CD pipelines * More secure setup because the gitops operator pulls from inside the cluster (no external secrets) * A better way of solving your configs (more on this later)

Releases

It’s not an accident that I picked these 2 topics. They are related in a lot of ways, and I feel that using gitops makes thinking about releases and creating a good pipeline for it a lot easier, but first…

What is a release? Most people would just say a tagged commit on my codebase. While this might feel true for maybe a binary or documentation it is however not true for an app running on kubernetes. When is something a release?

A release is a change in how an application behaves.

Note that this will broaden the perspective of a release. By now most developers working on apps inside of kubernetes have adopted the 12factor app principles. The config principle of that states that you should inject the configuration through environment variables. If the config would chance than that could have impact on the behaviour of your code. So you should treat changing your config as a release. The trouble with this statement is that a config chance is usually not a code chance. Normally a config chance is part of a CD step or a manual step. The config step then affects the deployment yaml because an environment variable injection requires the container to restart.

Gitops solves this problem by giving your deployment and config the same home. Which in turn leads to the place of your actual release. A place where you should manage your versions. Not the codebase but a gitops repository like argocd suggests, and I recommend.

I hope you enjoyed this first article of shorts. More will come in the future!