The DevOps revolution has provided us with quite a few trends and buzzwords to experiment with. One of the most popular is GitOps, that term introduced by Weaveworks, echoing through practically every hall in the latest San Diego KubeCon, and its recaps.
Over the past year or two, I’ve seen GitOps described as a strategy, a paradigm, a set of practices, a workflow, and even as a science. I’ve heard that GitOps is for developers dealing with Kubernetes cluster management, or serverless, or the CI/CD pipeline, to name a few. So what is GitOps? Are all of the answers correct? Let’s take a minute to see how the term evolved, how GitOps can help developers, and where it fits into the DevOps lifecycle.
The term GitOps was coined, or at least successfully branded into our collective DevOps toolchain consciousness, by the good folks at Weaveworks, and introduced as Operations by Pull Request, a set of best practices combined with tools that they built to help developers operate Kubernetes via Git.
Common GitOps pipeline, from the weaveworks blog: https://www.weave.works/blog/kubernetes-anti-patterns-let-s-do-gitops-not-ciops
Later, Weaveworks summarized their definition of GitOps as a combination of:
#1 An operating model for Kubernetes and cloud native, that provides a set of best practices to join up deployment, management, and monitoring for containerized clusters and applications.
#2 A path towards a developer experience for managing applications; where end-to-end CICD pipelines and git workflows are applied to both operations, and development.
As software development organizations adopt DevOps practices to keep up with today’s tight release schedules, we’ve all become familiar with shift left practices, and most of us have added automated tools into the early stages of our CI/CD pipelines. It should come as no surprise that as quality and security testing are being shifted left into the capable hands of developers, deployment is also getting its shift left moment, via GitOps. With or without Kubernetes environments, developers can now easily use Git and pull requests to manage infrastructure provisioning and software deployment.
Everett Toews describes the GitOps pipeline as a general technique, in environments that don’t necessarily include Kubernetes as “reconciling a desired step in Git with a runtime environment”.
Developers use the same Git workflows that they’ve always used for development — submit a pull request, review, and merge. What follows in a GitOps scenario is an automatic action once the commit is merged. Toews explains that the “action takes place in a reconciliation system, which is triggered by a push or pull event. That reconciliation system then applies the desired state from Git to a runtime environment”.
From: Everett Toews blog
What makes GitOps more than a passing trend is that it provides software development organizations with capabilities that they never had before, and that the distributed systems and microservices used in organizations today demand. Some of the main benefits that developers and ops teams gain are:
GitOps provides development teams with the monitoring, logging, tracing, and visualization that they need, so that they know when anything breaks, and where. One of the advantages of shift left is the ability to address problems before they become big issues that delay delivery.
#2 Versioning Control and Change Management
Since all deployments are versioned, teams can easily streamline operations, and audit and swiftly roll back when problems arise.
#3 Easy adoption
Developers are already using Git. They are not required to learn how to use a new tool, or adjust to a new environment or practice when they start writing Git requests deployment.
Development teams can make tens or even hundreds of updates to apps running in live production, saving valuable time once spent rolling out upgrades.
Using Git means that every action can be traced back to a commit, enabling DevOps teams to easily find the root cause of any issue that arises.
GitOps is a relatively new practice, and some of the top solutions in the industry have begun to support it. A few examples are GitHub Actions, GitLab CI, or Jenkins X. As GitOps practices and tools continue to evolve, we’ll be seeing more and more solutions that converge GitOps with the CI/CD pipeline, to the point that code deployment may become a serverless function.
Our advice: if you haven’t started considering it yet, ask your developers to test a few GitOps tools, and see what best suits your environment, teams, and processes. Git as a single source of truth might be just what your deployment processes are missing.