mirror of
https://github.com/fleetdm/fleet
synced 2026-04-21 21:47:20 +00:00
66 lines
5.6 KiB
Markdown
66 lines
5.6 KiB
Markdown
# The GitOps Idea
|
|
|
|
GitOps is a term coined by software technology practitioners and analysts as a way of describing a set of tools and working principles. Applying them results in powerful automation workflows that offer a way to keep version-controlled configuration files in sync for declaring the state of an entity, like:
|
|
|
|
- A software code base
|
|
- A data center full of cloud servers
|
|
- A web application
|
|
|
|
or really any technology construct that can be modified with commands, an advanced programming interface ([API](https://en.wikipedia.org/wiki/API)) or [configuration-as-code](https://www.computer.org/publications/tech-news/trends/configuration-as-code-guide).
|
|
|
|
Though GitOps is obviously associated with git, it goes beyond simply using git alone. It's also not a stand-alone product for sale. GitOps is an idea.
|
|
|
|
## GitOps components
|
|
|
|
### Git
|
|
|
|
[Git](https://git-scm.com/) is an open-source, text-based, distributed version control system for managing changes to a set of files, referred to as a repository, or "repo". Git is packaged and delivered as a command-line interface ([CLI](https://en.wikipedia.org/wiki/Command-line_interface)) binary and was originally created by [Linus Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds) around 2005 to help him track contributions to the Linux project.
|
|
|
|
Files can be added to a repo and modified non-destructively by one or many contributors. Each change (referred to as a "commit") in each file can be viewed by moving backwards or forwards through the commit history timeline. Any version of a file's history can be promoted as the correct one. Work on files is often collaborative via a system of approvals.
|
|
|
|
The result? A repository that represents a "source of truth", logically composed of all up-to-date commits.
|
|
|
|
### Continuous delivery and integration (CI/CD)
|
|
|
|
CI/CD has a less-than-catchy name tag, but it's a relatively simple idea:
|
|
|
|
Assuming there is a logical, frictionless way for a group of contributors to work on a set of files together without overwriting or messing up the contributions (e.g., git, but really any version-control system), the contributors, theoretically, should be able to work faster, commit more often, and continuously.
|
|
|
|
Small, iterative changes that are tested in real-time and shipped quickly to production are preferred over years-long refactoring projects that don't go out into the world until they are perfect. The impact this way of thinking and the practice can have on a team, a product, an organization, and on work itself should not be underestimated.
|
|
|
|
### Automation
|
|
|
|
By using git combined with CI/CD concepts and making use of git repository management solution automation capabilities (e.g., [GitHub Actions](https://github.com/features/actions) or [GitLab CI/CD](https://about.gitlab.com/solutions/continuous-integration/)) to merge changes, check for approvals, run validation/tests, and ultimately push known-good changes to a target production system, GitOps was born!
|
|
|
|
## GitOps benefits
|
|
|
|
A discussion of GitOps benefits is somewhat elusive outside the context of a specific use case, but there is no question that its widespread adoption is proof of its value. Here are some of the most important general benefits:
|
|
|
|
### Principle of least privilege
|
|
|
|
Creating guardrails around a git repository is a critical necessity. Git repository management solutions allow all contributors to add value and enable the designation of "codeowners" who can block commits before they cause problems.
|
|
|
|
### Collaboration and auditing
|
|
|
|
Because changes that are submitted to the repository can be seen by other contributors, GitOps enables opportunities for collaboration not available outside of a system like git. Git repository management solutions have inline comments. For every change, git records what was changed, when, and by whom. It's purpose-built for discovery and rolling back to a previous repository state if needed.
|
|
|
|
### Testing and validation
|
|
|
|
The sky is the limit when it comes to what can happen on a git repository management solution automation runner like GitHub Actions or GitLab CI/CD. Any script, any code, any binary can run in the cloud on almost any computing platform: pre-deployment checks, code linting, security compliance, and organizational standards checks. The ability to execute on a CI/CD runner is the behind-the-scenes magic of GitOps.
|
|
|
|
### Confidence and resilience
|
|
|
|
Powerful auditing and declarative control over any system should result in a reduction of the hours needed to fix problems and outages. Because code in a system like GitOps is easier to maintain than it is to maintain and monitor the state of a graphical user interface ([GUI](https://en.wikipedia.org/wiki/Graphical_user_interface)), GitOps can also lower the effort of long-term maintenance for a target system.
|
|
|
|
## GitOps is ready when you are
|
|
|
|
You don't need specific reasons or products to apply GitOps thinking to your work today. GitOps is a set of practices and ideas that can be creatively applied in almost any context or technology domain.
|
|
|
|
To get a feel for how GitOps fits with device management, Allen Houchins has written an excellent article about his journey to GitOps adoption as head of IT for Fleet: [What I have learned from managing devices with GitOps](https://fleetdm.com/guides/what-i-have-learned-from-managing-devices-with-gitops).
|
|
|
|
<meta name="articleTitle" value="The GitOps idea">
|
|
<meta name="authorFullName" value="Brock Walters">
|
|
<meta name="authorGitHubUsername" value="nonpunctual">
|
|
<meta name="category" value="articles">
|
|
<meta name="publishedOn" value="2026-02-04">
|
|
<meta name="description" value="An introduction to GitOps, explaining how version control and automation are used to manage systems reliably.">
|