What Is GitOps?

Introduction

Two of the main functions of a software development cycle are development and operations. Developers use version control systems to manage changes to their source code over time. Operations team prepares the infrastructure (servers, storage, load balancers, etc.) and deploys a particular version of a software application to this environment. DevOps is a set of practices that combines software development (Dev) and IT operations (Ops), which increases an organization’s ability to deliver applications and services to customers at high velocity:

Imperative / Declarative Paradigm
Focus on ‘what’ or ‘how’?

There are mainly two paradigms followed for the design and implementation of automation frameworks: Imperative and Declarative.

In imperative paradigm, all steps necessary to achieve the desired result is written down. This could be instructions (imperative scripts) for software installation, configuration, database creation, etc. These instructions are executed during automation to achieve the final expected state of the system. Imperative DevOps are suitable for smaller deployments, but fails to scale in large software deployments and environments.

A declarative paradigm instead of defining exact steps/instructions to be executed, it defines a desired final state. A typical declarative specification will only say how many machines are required, which applications are to be deployed, etc. It will not define the individual steps to achieve the goal. There is some intermediary magic code which is taking care of all necessary operations to achieve the desired end state. Users can focus on what is required, rather than how to achieve it, which saves a lot of time and effort.

Modern software development has trended away from imperative patterns and towards declarative software patterns. Declarative software follows a declaration of an expected state instead of a sequence of commands.

Git — Version Control
Collaborative software development using pull requests.

Git is one of the most widely used open source distributed version control systems in the world today. It enables Pull Request (PR) and code review workflows. Pull requests provide visibility and measurability in to code changes. This in turn allows review of code changes, collaboration and integration of approval workflows in to DevOps processes.

Traditional Ops
Manual provisioning and deployments!

In a traditional setup, development teams develop and deliver new code, QA team tests the new version and then the operation’s team deploys it. System admins are usually responsible for the infrastructure setup and deployment of software. Most of these processes are difficult and manual, requiring specialist knowledge and experience. In traditional ops, system administrators will be setting up and configuring the servers manually, by connecting to the machines directly or remotely. This normally includes provisioning of the hardware and other manual configurations, each time changes are to be applied. These kind of deployments are error prone, takes longer time and are less frequent.

Some administrators also used partial automation through deployment scripts. They made custom made imperative scripts and configurations to create and manage the infrastructure. Imperative software follows a sequence of steps to achieve a desired state. These scripts could be error prone or break at any time or lost without proper version controls.

DevOps
Automated build and deployment (CICD)

Due to the inherent limitations and issues with traditional ops and the rise of new cloud computing environments, organizations started to invent newer and better ways to optimize their development and IT operations. Major objectives were to increase frequency of deployments, improve reliability, stability and performance of computing environments. This lead to a new industry standard and practice (culture) to automate the build and deployment processes, called DevOps.

DevOps model requires high level of automation across development and deployments. CICD (Continuous Integration and Continuous Deployment), a new concept of deploying software, allows the automation of code integration, build, test and deployment to production as soon as new changes have been verified as good. A number of tools, like Ansible, Chef, Puppet, etc. enable DevOps automation. These tools convert developer created instructions (imperative scripts) into provisioning and deployment steps and finally achieving the desired state.

GitOps
Declarative paradigm to configure systems.

GitOps is based off a Git-based source code management system. GitOps is the practice of using Git Pull Requests (PR) to verify and automatically deploy system infrastructure modifications. It is code-based infrastructure and operational procedures that rely on Git as a source control system. It’s an evolution of Infrastructure as Code (IaC) and a DevOps best practice that leverages Git as the single source of truth, and control mechanism for creating, updating, and deleting system architecture.

Pull requests change the state of the Git repository. When approved and merged, pull requests will automatically sync the production environment to the new state of the repository. This live syncing pull request workflow is the core of GitOps. ie GitOps ensures that a system’s cloud infrastructure is immediately reproducible based on the state of a Git repository.

How Do GitOps work?

• Store desired configuration of the system in source control (Git)
• Make changes to configuration and create a pull request
• Review changes and approve
• Operator software observes the changes and makes changes to the current state of the system to the new desired state

GitOps requires declarative specifications to describe and observe systems which will become the basis for continuous integration and deployment. IaC (Infrastructure as Code) too encourages and promotes declarative system administration tools over custom imperative solutions. Desired state of the system will be stored in Git, such that entire audit trail (commits, committer information, commit IDs, time stamps, etc) of changes are readily available and fully traceable. This means that both application and the infrastructure are versioned artifacts and can be audited using gold standards of software development and delivery.

Git with Kubernetes

GitOps combines Git with Kubernetes’ convergence properties and serves as an operating model for developing and delivering Kubernetes-based infrastructure and applications. For example, we can describe everything in the Kubernetes model as a declaration. The Kubernetes API server accepts a declaration as an input, and then continually tries to drive (or converge) the cluster to the desired state described in the declaration. With GitOps, the use of software agents can alert on any divergence between Git with what’s running in a cluster, and if there’s a difference, Kubernetes reconcilers automatically update or rollback the cluster depending on the case.

Benefits of GitOps

• Increased Productivity
• Enhanced Developer Experience
• Improved Stability
• Higher Reliability
• Consistency and Standardization
• Better Security
• Easier compliance and auditing

Summary

It is all about collaborative software development using Git and Pull Requests. GitOps is an operating model for building secure, cloud native, continuous delivery pipelines. In GitOps, the entire system is described declaratively, desired system state is versioned in Git, approved changes can be applied automatically to the system, software agents ensure correctness and alert on divergence.