In an ideal world you would be able to test everything you needed to locally, or at least on some sort of staging environment. With a complicated enough system, or bugs that are triggered by certain patterns of data, this can be hard. Just committing something you hope will fix the problem and releasing it is usually a recipe for disaster. If you haven’t got it right you could be making the problem worse. So how safely can you put some code into production to get more debugging information or try out a potential fix?

If it’s a new feature that’s not released to customers yet hiding it behind some sort of feature flagging system works well. For fixes for existing functionality this is harder. It should still be possible to use feature flags though you might have to duplicate some code paths temporarily so you can make sure that you don’t accidentally break something. As long as it is temporary this is fine.

The faster you can deploy to production the quicker you can iterate and figure out what’s actually going on. It’s still going to take more time than if you could debug the problem locally so you should only be doing this in cases where that’s not possible. Make sure and do the work to unwind the debugging changes before calling everything done so you don’t have two code paths to test in the future.