I feel like the one of the distinguishing characteristics of a senior engineer is a healthy fear of change to production. I think it’s just that the combination of all of the things I’ve broken over time accumulates to the point where I am skeptical of any and all changes I make. This is why I love unit testing, and the practice of writing code that is testable. While some issues that can break production are still hard to test at a unit test level, at a very a minimum, good test coverage assures that the code itself that I am writing handles all known issues I can think of to throw at it.
A long time ago, I learned the hard way that config is code. I used to think config was safe and code was not safe. But I think the opposite is true. I have found that bad config can break things just as fast or faster than bad code.
That’s why I always prefer to find a way to test my config. At a minimum, load the config using the same code that loads it in production, parse it, poke at it, verify it is doing exactly as you think it is. While it is still possible for that config to break something, at least it helps if that thing that is broken is not the config itself.
Your results may vary, but I prefer to test my config before pushing it to prod.