What is GitOps and what should you know about it?

What is GitOps?

GitOps is an operational framework that applies DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD tools to infrastructure automation.
The idea of GitOps is to have a Git repository that always contains declarative descriptions of the current desired infrastructure for their projects on your servers. In addition, an automated process is defined to bring the servers into compliance with the described state and their configurations in the repository.
If you want to deploy a new application or update an existing one, all you need to do is update the infrastructure repository. Everything else is done by an automated process.
GitOps is like a synchronization of your server configuration for each project managed by git.

Modern applications are developed with speed and scale in mind. Organizations with a mature DevOps culture can deploy code to production hundreds of times per day. DevOps teams can do this through best development practices like version control, code reviews, and CI/CD pipelines that automate testing and deployments. That’s GitOps.

By updating to the application repository, a “pipeline” is executed which starts several automated steps:

• Tests of the system which execute the program code.
• Checks for a static analysis of the code (e.g. the style or the complexity of the code).
• A Docker build so that each container becomes an executable instance with the latest code of the application.
• A publication of the containers in a “Docker Registry” (so that the Kubernetes cluster can pull the new containers onto the servers).
• A “git commit” + “git push” to the repository of the configuration of the infrastructure with the new “Docker Tag” which corresponds to the version of the application.

After that, “ArgoCD” detects new versions of the containers that are ready and can be updated on the Kubernetes cluster.

Why GitOps?

More security

With the GitOps concept we achieve more security because we do not need SSH credentials or anything else to perform a deployment.
An application like Flux or ArgoCD installed on the server only needs access to the repository with the configuration of the environment. Through this access, current configurations can be updated on the Kubernetes cluster by a “pull” of the Git repository.

Git as a single source of truth

Because not only the application but also the declarative configuration of the infrastructure lives in Git, every change is traceable, every version can be restored, and provides full transparency to the entire team (who “committed” what changes at what time).

Infrastructure as Code
Declarative description of the system and the infrastructure (no instructions but facts ready for direct execution)

In many outdated systems, the know-how about the servers is either kept by the formerly so-called “system administrators” or there are long documentations about the dependencies and instructions for the servers (such documentations are not always up to date and therefore bring little added value). With GitOps this old concept becomes obsolete. With the new concept we want to keep the know-how as transparent as possible, therefore instead of instructions, declarative and executable definitions of the whole system are written in the form of the code (often in .yaml or .tf format).
If this description would not be correct, the system would not work, because the code is tested and executed at every change.

Pull Requests + Review for Changes to the Infrastructure

Because the infrastructure is now managed in Git just like any software project, the same proven concepts for quality assurance and control are applied.
When there is a request for a change to the infrastructure, a “Pull Request” is created which is first subject to a “Code Review” before the changes can be applied to the system.

Is GitOps a replacement for DevOps?

No. GitOps is a concept and DevOps is a culture. GitOps assumes and supports DevOps culture. GitOps is a technique for implementing Continuous Delivery, Continuous Deployment and Infrastructure as Code. Although DevOps and GitOps share principles such as automation and self-managed infrastructure, it doesn’t really make sense to compare them. However, these common principles certainly make it easier to adopt a GitOps workflow if you are already actively using DevOps techniques

Software versioning

With software versioning, we can uniquely identify the different phases of our software that we have delivered. When we talk about a particular versioning, we use this number or text as a reference to our software at a particular time.

Release Notes

Release notes or a changelog can be used to maintain a list of changes and their
description can be maintained. In this way we give ourselves and the users of a particular system a way to quickly and easily see what progress and changes have been made.

Versioning
For versioning we use so called “Semantic Versioning”.

MAJOR versioning when you make incompatible API changes,
MINOR versioning when you add functionality in a backward compatible way, and
PATCH version, when you make backward-compatible bug fixes.
Additional pre-release and build metadata designations are available as extensions to the MAJOR.MINOR.PATCH format.

(Ex. v1.0.1+3 — version: 1.0.1 with build number 3)

Source: https://semver.org/

How is a new version determined?

When using GitHubFlow — https://guides.github.com/introduction/flow/
there is a “master / main” branch to which all “feature” branches are merged.
If a new version is to be built and released at a certain point in time, a “git tag” is used with the version. Then the pipeline recognizes this tag and performs the necessary steps for the release.

Author: Robert Pupel