Many working in tech suffer from “Buzzword fatigue”. Especially any buzzword with the phrase Ops in it: DevOps, DevSecOps, AIOps, MLOps, DataOps, and now we add GitOps.
So, what is GitOps and what has it done to deserve valuable, dedicated brain cells for another buzzword?
There is an argument to be made that GitOps is one of the more important of the -Ops buzzwords. While many others are often too vague or redundant, GitOps is fairly concrete. In short: GitOps is the process of getting your Operations into Git. It’s that simple, but let’s break it down more.
Git is the world’s most popular Source Control Management software, used by developers the world over. Code (or any kind of file technically) is checked into a centralized location called a repository. Developers copy (or checkout in git terms) the code from this centralized repository to their local machines and work on it, make changes and push it back up and collaborate. Git helps manage conflicts, version, revert and do a whole slew of other things that are vital to collaborating on a complex code project. It is a crucial, everyday tool for a developer.
GitOps is an operational framework that seeks to bring the advantages of git together with what are now becoming more standard tools and concepts to the DevOps and Automation world: Infrastructure as Code, Merge Requests/Pull Requests, and Continuous Integration and Delivery/Deployment. These core components are all tied together to create GitOps. It is not a specific tool, technology, or platform to use, but a rather simple concept: Treat your operations environment as code.
Infrastructure as Code
Infrastructure as Code(IAC) is exactly what it says on the tin: Infrastructure environments that are defined in code. IAC tools are essentially programming languages that operations teams can write in that create infrastructure. Oftentimes these IAC tools are declarative, in which you describe what you’d like the environment to look like. This is opposed to imperative code in which you describe steps to make an environment look how you want. For example, in imperative language, you say “First pour in espresso, then steamed milk, then milk foam”. With declarative language, you say “make me a latte” and it knows how to make it. Also, you say please and tip well because you’re a nice person with good taste in operational frameworks.
Merge/Pull Requests
Merge and Pull requests are an extension of git functionality. Git as a tool does not have a native centralized repository. It is by nature, distributed, with developers each having their own full-blown copy of the git repository. This, obviously, won’t cut it for organizations where a more centralized solution is needed. This is where git hosting services come in. Github, Gitlab (who coined the GitOps term) are both common git repository hosting services. These central repositories allow developers to collaborate on projects using git. Additionally, these hosting services extend the functionality of git with many features.
One of the most important collaborative features that these hosting services provide is the Pull Request or Merge Request. When a developer works on code, they will typically do so in a branch: a separate version of the project. This lets a developer work on changes doing whatever they’d like without worrying about the integrity of the project. Once a developer has completed the changes they were working on in their branch, a developer needs to merge them back into the main branch, where the main copy of the code is. The main branch is typically the version of the code that is considered to be the primary version.
So (finally) we come to Pull/Merge Requests. A pull/merge request is a request to merge code into the main branch. This request prevents a developer from just pushing their code out to the world. The request allows code to be reviewed by others on the team before is it made into law by being merged into the main branch.
Continuous Integration and Delivery/Deployment(CI/CD)
CI/CD is what happens after code is committed to a repository. Code is it’s raw state is rarely usable. Something almost always must happen for code to be useful: it has to be built into executables, it has to be tested, it has to be deployed somewhere. CI/CD is the concept of capturing all these steps and doing them automatically when code is committed. CI/CD can be complicated or simple, but the point is to remove manual steps as much as possible.
So What?
So, with all these tools and concepts in hand, you begin to codify your operations, put them in a remote repository and deploy them continuously. Great, what does that get you?
- Automation: Less human intervention saves valuable time and effort.
- Reproducible: No more needing to remember the right buttons to click or commands to type in, they’re right there in the repo.
- Self-Documenting: Having operations environments in code lessens (not eliminates) the need for documentation as it is all written down in code. It’s easier to figure out what servers you have if they’re all defined somewhere.