Complete GitOps vs DevOps Guide
Death, taxes, and new trends in software development are pretty much the only things you can count on in life these days. As the term “DevOps” turns 13 years old (originally credited to Patrick Debois in 2009), it is already being overtaken in developer circles by the latest hot new term: GitOps (coined in 2017 by WeaveWorks). Today we’ll start off with some definitions, compare what is GitOps vs DevOps, and then you too will know which is which.
When it comes to software delivery best practices, the debate rages on for the most optimal way to handle delivery. When it comes to your organization, there are a lot of factors to weigh in considering how you approach delivery. As with most organizations, you will likely conclude that you want a combination of the two approaches to achieve your desired outcomes.
What Is DevOps?
Anytime you ask this question, expect a plethora of answers, all mostly correct. Above all else, it is a collaboration between development and operations teams to achieve greater velocity, higher quality, and sustainability during software development. These goals are achieved by a combination of tools, operational practices, and cultural practices.
In practice, DevOps is an umbrella process over Continuous Integration and Continuous Delivery, primarily focused on the end goal of accelerating the software development life cycle. For any organization, this includes many DevOps tools to cover specific areas, such as testing, infrastructure management, packaging, artifact management, software deployments, and more.
For practical purposes of this article, DevOps paves the path from version control all the way to production, providing a repeatable and sustainable framework for getting software into the hands of end users.
What Is GitOps?
GitOps is the philosophy that deployments, changes, and more should be as simple as making a commit to Git. GitOps takes an approach centered around development teams and their version control system of choice. The process starts with merge requests, followed by code reviews, and then auto deployment of code to the relevant environment.
GitOps Principles
As GitOps is the newer of the pair, we will expand a bit more on the principles; for more, we also have a deep-dive into the question What is GitOps? If you are looking to improve, check out GitOps Best Practices.
The Entire System Is Described Declaratively
Everything required to run the application is described in configuration files, and/or config as code. This includes all supporting infrastructure configurations, such as load balancers, database configurations, and anything required to stand the system up.
The State of the System Lives in Version Control
The state of the system in version control is the final word on how the system runs in production. Changes made to production outside the process of pull requests, merges, etc. must be reverted to match the source of truth.
Automatically Apply Approved Changes
In a pure implementation, all changes merged to the main branch appear immediately in the downstream environment, without gating/approvals.
Drift Consolidation
In contrast to push-based models, the GitOps operator automatically reconciles differences between the source control system and the target environment.
Why GitOps?
GitOps emerged as a new approach to deployments, to move from Continuous Delivery to true Continuous Deployment (see our explanation for those nuances here).
Need for Speed
GitOps addresses the growing need for innovation and delivery velocity. Where DevOps standardized delivery cycles and brought much needed consistency to the intersection of development and operations, GitOps supercharged that relationship by giving developers the power to enact code changes immediately, and by changing how developers consume IT services while delivering application services to end users.
Democratizing Services
In the traditional model, IT services such as DNS, load balancers, compute, and storage were heavily siloed and took weeks to months to provision. DevOps sped up the process from months to weeks, and sometimes weeks to days. Mature organizations practicing DevOps often had high levels of infrastructure automation, with some increasingly making use of an on-demand IaC model.
A fundamental shift provided by GitOps was to default to creating deployed infrastructure by way of infrastructure as code tools, such as Terraform—all downstream of commits to the version control system. In GitOps, managing modern cloud infrastructure is at the fingertips of developers, not the traditional gatekeepers.
GitOps vs DevOps
What Is the Difference Between GitOps and DevOps?
Beyond the internet debate of posing the two against each other, in reality, the two work as colleagues more often than not. At a high level there’s a few key differences.
All GitOps is DevOps, but not all DevOps is GitOps: While GitOps is focused on delivery, the scope of DevOps is much broader as it concerns itself with a larger set of problems, including CI, visibility, and governance.
GitOps is more prescriptive: While DevOps embraces many roads to the same outcomes, GitOps makes several specific prescriptions around how services are built and deployed.
Integrating GitOps With DevOps: Friends Not Foes
Is GitOps part of DevOps? How are GitOps and DevOps related? While some may consider GitOps a replacement for the delivery component of DevOps, it is very much a natural extension of DevOps methodologies. Moreover, great GitOps relies on a broader DevOps culture and ecosystem to thrive. Rapid iteration and rapid production deployments only work in a broader system with a strong testing regimen, high visibility into metrics & telemetry, and well-designed systems to mitigate production issues.
Adopting GitOps
DevOps may help lead the way before GitOps, where those most successful at adopting GitOps solutions will already have mature DevOps practices in place. The journey to adopt GitOps processes will vary by organization, but typically, the applications most well suited to onboard will leverage the following characteristics.
Entire application is described in code: Everything required to deploy is described and in version control. This includes load balancers, databases, and everything required to stand up from scratch. No additional parameters should be required during the GitOps workflow.
Modern/cloud-native applications: With the Git-based approach, the underlying infrastructure must be able to support declarative provisioning. Kubernetes-based infrastructure comes to mind first, but other non-Kubernetes systems are increasingly exposing their services in a declarative fashion.
Automated test coverage: Applications that are automatically deployed cannot wait for manual processes. Running tests should already be fully automated in your CI/CD processes.
DevOps With GitOps
With a solid understanding of GitOps under our belts, we can now look at how it works within actively employed DevOps techniques to optimize delivery. With GitOps enhancing delivery, there are a few key considerations for a DevOps team to fully employ DevOps best practices.
Plan a proper strategy for monitoring and rollback. With releases rapidly heading to production, mitigating the blast radius of bad changes becomes crucial. A typical GitOps workflow is fairly lean on purpose, and this is why many organizations still opt for a pipeline-based approach when deploying to production. Check out Harness Continuous Verification for how we uniquely solve this problem.
DevOps has a love-hate relationship with proper governance and auditing, though modern tooling has improved dramatically since the days of plain-text passwords in logs. GitOps has this problem as well, where everything is recorded, but digging up a months old change in Git logs is a developer’s job, not that of an auditor.
GitOps is a high-powered machine, and implementing anything that powerful at scale has inevitable toil. From provisioning operators, to Git repository sprawl, to Kubernetes cluster management, DevOps teams have their work cut out for them.
GitOps vs DevOps: What Should You Do?
Non-Technical Objectives
As with every technical problem, there are many paths to the correct answer. Before asking any technical questions, understand the needs of your organization. Few organizations won’t benefit from the incredible delivery speed of GitOps, but you should always mind the other drivers around your business.
For GitOps to truly work, you need to already have a fully automated quality regimen in place. Deploying at will does not mix well with insufficient quality processes.
For those in regulated industries, scaling GitOps in a way that meets compliance needs while maintaining velocity takes time to implement effectively. Every action is recorded in Git history, but aggregating, searching, and using the existing audit trail requires domain-specific knowledge.
Technical Drivers
GitOps thrives in a strong existing DevOps ecosystem. As with everything, walk before you run. Consider if your processes are mature enough to support DevOps, and understand that it’s not an all or nothing proposition.
When the microservices approach to application development became popular, many organizations moved quickly, and found they had an abundance of technical maturity and foundational issues that remained unsolved despite being on top of the newest technical trend. With GitOps, the same truth exists, in that it will not solve all your underlying technical problems. If your CI/CD, system architecture, pull request process, etc. are broken today, they will continue to be broken after GitOps adoption.
How Can Harness Help You?
We hope that you’ve come out of this blog with a better understanding of the finer points of GitOps and DevOps, along with how they fit within the broader software development lifecycle. At Harness, we support both approaches, and we understand there’s no one size fits all solution.
Moreover, we’re working to provide developers with the full platform of solutions needed to support the high-powered engine of GitOps. It starts with CI to optimize test and build cycles, continues with integrated security into your pipelines, and finishes post-release with feature flags and monitoring feedback baked in. We’re here to support all your DevOps ambitions, so book your demo today!