GitOps Explained with Emoji
The history of software development could be written as constant acceleration. From the steady waterfall model of releasing new versions once a year, to agile making small features weekly, to modern cloud architecture pushing out code changes as often as you or I might take a coffee break.
How have we achieved this acceleration? Through the evolution of tools that make code deployment safer, easier and more observable.
GitOps is not a revolution, but rather a system to support more frequent releases that drive modern software development. It’s a standardized workflow for deploying, configuring, monitoring, updating and managing infrastructure as code. Most importantly, GitOps enables you to move faster safely.
‘Move Fast and Break Things’ Has its Limits
In the heady days of agile’s first introduction, speed was everything. Release every week, and who cares if you introduce bugs? Users would find them, you’d fix them and the evolving product would look more and more like the ideal product for users every day.
These ideals work when building a digital marketing agency or a goofy storefront that sells pencil toppers. But “who cares about a few bugs” doesn’t fly when you’re running an online bank concerned with compliance. Further, it’s one thing to introduce bugs by changing the product in ways that users don’t love. It’s quite another to break production and take the site down.
As we’ve encouraged developers to embrace DevOps and empower small teams to release microservices, it’s easier than ever to experiment with operations and make changes that break things.
The answer might seem like “slow down and be more careful,” but the actual answer is even more speed.
The Kernel of GitOps
The central idea of GitOps is that operational changes happen as soon as a commit 📄 is made to a repository 🏦. If daily releases increase the chance that a change will break the build, it would seem that per-commit releases would make that much worse. However, if you release changes multiple times a day 📄, you increase the feedback 🤔😀 that developers 👩🏾💻 receive. GitOps actually makes it safer to experiment, because issues appear while you still have time to fix them.
GitOps empowers your developers to do the work of IT and operations, making changes to operational configuration to better host services.
Git Makes it Possible
The main rule of GitOps is that a repository (probably a git repository, but the concept is tech-agnostic) must be the single source of truth for your service’s application code and the configuration for the containers that will run your application. Need to revise your app’s error ⚠️ handling? Make a commit. Need to increase the memory 💾 allocation? Another commit 📄. How about standing up new servers in response to heavy loads? You guessed it, a commit 📄.
When things are running smoothly, GitOps means that every developer has a sense of ownership over their application. By delivering a service from start to finish, they gain a deeper understanding and better ability to support the application in production.
We Can Always Go Back
How is it possible to empower every single developer to make changes in prod? A single source of truth in a Git repository means there is always a way to go back. GitOps requires the system’s desired state to be stored in version control, so anyone can view the entire audit trail of changes.
This requirement means that debugging a recent breakage is easier, since there’s a clear record of changes. Even better, traveling back to a known good state is a lot simpler when there’s a clear record of changes. Ideally, the past is no more distant than a quick Git reset.
Again, this is enabled by having a Git repository 🏦 as a source of truth for all operation changes. While GitOps does rely on creating commits for everything, it promises to help enterprises stay competitive and achieve greater velocity safely and securely — and be controlled by the developer.