Git as a single source of truth for configuration

Git as a single source of truth for configuration

What is gitops? It’s the practice of using Git as a single source of truth (SSOT) for infrastructure configuration. In this guide, you’ll learn how to use Git to store and manage the configuration of your servers in an easy-to-manage way so you can keep track of changes, simplify deployments, and ensure consistency throughout your infrastructure deployment process. You’ll also learn about the tools and best practices that help make gitops possible by providing a clear audit trail and making deployments quicker and more manageable.

1) Introducing GitOps

GitOps is a methodology and tooling to help organizations establish Git as their single source of truth for production infrastructure. The goal is to provide secure and reliable access control, automated deployment, observability, compliance tracking and audit capabilities, all through simple declarative policies in git repos. GitOps focuses on people over machines (versus DevOps), open source tools over proprietary ones (versus Cloud Native), and trust over control (versus Security). This ultimately results in an environment where everyone can see everything that’s happening, leading to better collaboration across teams.

Git as a single source of truth for configuration


2) Infrastructure as Code (IaC)

Building and provisioning infrastructure is one area where you can use IaC. The reasons are twofold: It’s tedious to type out all that code, but it also means you have fewer ways to inadvertently introduce errors. Git is a version control system (VCS) built on Linus Torvalds’ BitKeeper software. Unlike centralized VCS systems like Subversion or Mercurial, Git works by tracking every change made within its repository since its inception. That makes it particularly good at managing large projects with many contributors over long periods of time—exactly what we need in our IaC toolbox. With tools like chef-solo , Ansible , and SaltStack , we can declaratively specify how an environment should look via a collection of files tracked by our repository—we don’t actually execute those steps until we want to update our target environment with changes from our repository! This method encourages us to be explicit about how we want something configured; there’s no mistaking when things go wrong or when another team member has slightly different expectations than we do.


3) Testing IaC

Infrastructure as code is great, but it only works if your development team uses it. You need to monitor them with everything from pull requests to code reviews. When changes are made manually, it’s hard to track what changed and when; that means figuring out which version caused an outage or other problem could be extremely difficult, making troubleshooting and patching more complicated than necessary. The solution is simple: use open-source continuous integration software (like GitLab) and create tests for every change you make in IaC—for example, if you’re using Jelastic CloudScripting to deploy new stacks, test your changes before you commit them by updating a pre-existing stack (pre-prod) instead of creating a new one.

Testing IaC


4) How Does This Relate to Git?

Git, specifically git repository management tools, is typically used to track changes in code. Git’s powerful branching capabilities and distributed architecture make it easy to manage multiple branches of code. If we apply these same concepts and methods to non-code assets such as infrastructure configuration files and remote job runner scripts, we can create a single source of truth that will enable automation. Imagine having thousands of servers automatically updated with new configurations at 1am every Sunday morning, or every time a commit is pushed to master on your GitHub project. The benefits are numerous: faster deployment times and less human error, to name just two!


5) Branch Management

Branching is great, it allows us to work on multiple features and changes at once, and merge them together later when we’re ready. For example, let’s say you are working on improving your site’s performance. You might want to tweak some CSS styles in addition to making some changes to your servers’ configurations. You can make those CSS tweaks on their own branch (e.g., /css-perf) and push that up to GitHub or GitLab with git push origin /css-perf . Then you can make your server changes without worrying about breaking any CSS changes! Branches are awesome! That said, there is one thing you should be aware of: Branching makes keeping track of history really hard.

Branch Management

Written by

Matthieu Robin Hidora
Matthieu ROBIN

Matthieu Robin is CEO at Hidora, an experienced strategic leader, a former system administrator who had managed and configured more environments manually than anyone on the planet and after understanding that it could be done in several clicks established Hidora SA. He regularly speaks at conferences and helps companies to optimize business processes using DevOps. Follow him on Twitter.

Receive our news

Subscribe to our monthly newsletter to stay informed