The feature toggle magic

I’ve understood the benefits of continuous deployment for a long time, but I couldn’t figure out how it could work in real life. Having very short release cycles with everything being pushed straight to production with automated verification and feature toggling seemed magical and a little bit like an industrial myth to me. Most of the organisations I worked for, despite claiming to be fully agile, didn’t operate as described in the role models I saw on the internet. It takes a lot of courage to push changes directly to customers and experiment directly on the production code. I never had the guts or enough influence to implement such changes in the projects I worked on. I leaned towards small pull requests and minor code changes, but I still didn’t know how to translate this approach to the higher level, including product management. Even in my startup world, where I controlled the entire stack, I created a development branch that was released to master only occasionally. Fortunately, after years of limited agile, I experienced something much closer to the ideal state than ever before. I believe that this breakthrough was made primarily because of my usage and understanding of feature toggles.

Having only one main branch and frequently pushing to it, even though the features that we work on are not ready, is the most productive way of working I have ever experienced.

Without automated tests, both unit and integration, it wouldn’t be possible to have a high-quality product while shipping half-baked solutions directly to the main codebase. Still, once we have the safety net, I feel very confident while clicking the merge button on our master branch.

Recently, I’ve been working on moving our data layer repositories to coroutines. Because this is a significant structural change without feature toggles, I would end up with a vast, long-lived branch that I would have to push for a long review at the end. Still, because I could hide this behaviour and have those two working next to each other without pushing production users into this path, it is perfectly safe to merge my incomplete solution to the master branch constantly. It would be possible to expose a small percentage of users, such as 1%, to the solution and observe if any issues arise. However, this approach, akin to AB testing, represents the next level, and I’m still becoming comfortable with the more straightforward method.

So once you have feature toggles in place, it opens up a vast pool of possibilities. Starting from short-lived branches and pushing half-baked solutions directly to the main codebase dramatically reduces conflicts. Also, you can use it to run experiments that will allow you to see the impact of the change. AB testing looks very promising to me, but since I have minimal experience with it, I won’t try to elaborate on the topic. In the context of Lean Startup and Agile development, it seems like a must-have, but I’m still looking for an opportunity to test my assumptions.

Having feature toggles brings some overhead, such as managing them, cleaning up, and maintaining the infrastructure. However, from my personal experience, it is one of the best investments that could be made at the beginning of the project. Shortening development cycles, deploying frequently, and verifying hypotheses promptly appear to be effective strategies for advancing in the uncertain environment I am privileged to work in and explore.