GitOps is the practice of using Git as the single source of truth (SSOT) for infrastructure configuration. In this guide, we explore how to use Git to store and manage your server configuration in a simple way, so you can track changes, simplify deployments and ensure consistency throughout your infrastructure. You'll also discover the tools and best practices that make GitOps possible, providing a clear audit trail and making deployments faster and easier to manage.
Introduction to GitOps
GitOps is a methodology and set of tools that help organizations make Git their single source of truth for production infrastructure. The goal is to provide secure and reliable access control, automated deployment, observability, compliance tracking and auditing capabilities, all through simple declarative policies stored in Git repositories.
GitOps favours people over machines (unlike traditional DevOps), open-source tools over proprietary solutions (unlike conventional Cloud Native), and trust over control (unlike rigid security approaches). The end result is an environment where everyone can see what's happening, enabling better collaboration between teams.
This approach is at the heart of what we offer at Hidora through our DevOps consulting services. Setting up a solid GitOps workflow is one of the first improvement levers we recommend to our clients.
Infrastructure as Code (IaC)
Infrastructure construction and provisioning are areas where Infrastructure as Code (IaC) truly shines. The reasons are twofold: manually typing all the configuration is tedious, and it increases the risk of introducing inadvertent errors.
Git is a version control system (VCS) built on Linus Torvalds' BitKeeper software. Unlike centralized VCS systems such as Subversion or Mercurial, Git works by tracking every change made in its repository since its creation. This makes it particularly effective for managing large projects with many contributors over long periods, exactly what we need in our IaC toolkit.
With tools like chef-solo, Ansible and SaltStack, you can declaratively specify the appearance of an environment via a collection of files tracked by your repository. The actual execution only happens when you want to update your target environment with the changes from your repository. This method encourages you to be explicit about how you want things configured. There's no misunderstanding when things go wrong or when another team member has slightly different expectations.
Testing Infrastructure as Code
Infrastructure as Code is great, but it only works if your development team actually uses it. You need monitoring mechanisms in place, whether through pull requests or code reviews.
When changes are made manually, it's difficult to know what changed and when. This makes it extremely challenging to determine which version is causing a failure, making troubleshooting and patching more complicated than necessary.
The solution is straightforward: use open-source continuous integration software (such as GitLab) and create tests for every IaC change. For example, if you're using Jelastic CloudScripting to deploy new stacks, test your changes before committing them by updating a pre-existing (pre-prod) stack instead of creating a new one. This lets you validate your modifications in a controlled environment before applying them to production.
What does this have to do with Git?
Git, specifically the git repository management tools, is typically used to track code changes. Git's powerful branching capabilities and distributed architecture make it easy to manage multiple branches of code.
If you apply these same concepts and methods to non-code resources, such as infrastructure configuration files and remote task execution scripts, you can create a single source of truth that enables automation.
Imagine thousands of servers being automatically updated with new configurations at 1 AM every Sunday, or every time a commit is pushed to master on your GitHub project. The benefits are numerous: faster deployment times and fewer human errors, to name just two.
This is exactly the kind of automation we set up for our clients at Hidora, as part of our managed services. Every environment is versioned, every change is traceable.
Branch management
Branching is a major asset. It allows you to work on multiple features and changes simultaneously, then merge them when you're ready.
Here's a concrete example. You're working on improving your site's performance. You want to modify some CSS styles in addition to making changes to your server configuration. You can make these CSS changes on their own branch (for example, /css-perf) and push it to GitHub or GitLab with git push origin /css-perf. You can then make your server changes without worrying about breaking the CSS modifications.
Branches are fantastic. However, there's one important point to keep in mind: branches can make tracking history very difficult. That's why a good branching strategy (like GitFlow or trunk-based development) is essential for maintaining clarity in your configuration history.
Best practices for adopting GitOps
To get the most out of GitOps, here are some recommendations based on our experience:
- Version everything. Not just application code, but also server configurations, deployment scripts, security policies and infrastructure definitions.
- Automate deployments. Use CI/CD pipelines that trigger automatically on every validated change to the main branch.
- Protect the main branch. Require code reviews and automated tests before any merge to master or main.
- Document changes. Every commit should explain why a change was made, not just what changed.
- Audit regularly. Periodically verify that the actual state of your infrastructure matches what's described in Git.
GitOps is not a destination, it's a journey. Every organization can adopt it progressively, starting with the most critical elements of their infrastructure. The key is to start and iterate.
