‘YAML sprawl’ is a side-effect of delivering software at scale using GitOps.
It describes when a project grows in scale or complexity and causes significant time spent updating YAML files to maintain or deploy.
YAML sprawl in practice
Let’s say your software progresses through 3 environments to reach your customers: Dev, QA, and Production.
When using GitOps, each environment tends to have its own manifest files. To progress software to the next environment, you edit declarative YAML files in that environment’s directory so it knows what release it should have.
For example, if you’ve finished in Dev and want to move your changes to QA, you’d change YAML files in QA’s directory. To move a change to Production, you’d update YAML files in the Production directory.
Imagine you offer a popular multi-tenancy application to hundreds or thousands of customers. What if you develop complex software using a microservices architecture? How many files do you need to update in either scenario? How will you keep track of everything?
That’s when you hit YAML sprawl.
Why YAML sprawl is a problem
Like much in software development, everything is easy when a project is small. It’s scaling that causes most problems.
As you scale in GitOps, the number of repositories, environments, and customers increases, and so does the number of files to change. This means you must keep track of more YAML files and update them regularly.
Because each extra change with scale is relatively small - say a field or 2 at a time - it’s easy to consider the impact as ‘just a few more changes’. That means the downsides of YAML sprawl can easily creep up on you.
Firstly, making such routine changes takes up a lot of time, someone could spend on more useful or interesting tasks instead. Manual changes are also, of course, prone to human error.
Other alternatives, like scripting, may be an improvement but also aren’t free from the curse of human error either. When dealing with many repositories and YAML files, it’s easy to overlook something important.
Solutions for YAML sprawl
A dedicated Continuous Delivery tool can help you counter the risks associated with YAML sprawl by ensuring consistency across all destinations.
Octopus can help combat YAML sprawl because it’s environment-aware and lets you use one deployment process for all targets and customers. See our website to learn how.
Conclusion
YAML sprawl doesn’t mean GitOps is bad. As with any other software delivery strategy, you must know the risks and trade-offs. YAML sprawl is simply a risk of GitOps.
Tools can help you combat YAML sprawl; you should consider them as soon as you start to feel its pains.
Help us continuously improve
Please let us know if you have any feedback about this page.
