{"id":796,"date":"2026-01-30T09:55:30","date_gmt":"2026-01-30T09:55:30","guid":{"rendered":"https:\/\/productive.io\/engineering\/?p=796"},"modified":"2026-01-30T09:55:30","modified_gmt":"2026-01-30T09:55:30","slug":"decoupling-deployment-from-release-with-feature-toggles","status":"publish","type":"post","link":"https:\/\/productive.io\/engineering\/decoupling-deployment-from-release-with-feature-toggles\/","title":{"rendered":"Decoupling Deployment From Release With Feature Toggles"},"content":{"rendered":"

Frontend<\/a><\/p> –

{{minutes}} min read<\/p>

Decoupling Deployment From Release With Feature Toggles<\/h1> \"\" <\/a>

Davor Tvori\u0107<\/p><\/a> Frontend Engineer at Productive. Excited about anything related to computer science. I spend most of my personal time reading and playing video games.

January 30, 2026<\/p> <\/a> <\/a> <\/a> \"\"

Deploying new features is a nerve-racking task, but it must be done.<\/strong><\/p>

Here\u2019s an issue we\u2019ve all faced or will inevitably face in our careers. Allow me to set the scene\u2026

You\u2019ve finished your work on some features, fixed some bugs, etc. You\u2019re feeling good because some features were a bit more complicated. You decide it\u2019s high time to let your users experience these changes. You bundle up all your teams\u2019 changes and deploy them to the production server. A couple of hours later, disaster strikes!\u00a0There\u2019s a critical bug on a feature you\u2019ve worked on. Now, you have to revert to the old version of the application or deploy a new one, but without your changes.

As these situations can have a huge impact, reacting quickly is key. Unfortunately, developers usually learn how to handle this situation once it happens, so it only prolongs the agony.

Deploying and releasing at the same time isn\u2019t such an uncommon practice because, at the beginning of a project, you want your users to see the changes immediately. Many projects continue using this process, but as the project grows, it makes sense to decouple the deployment of the code and the release process (activating changes to users).

Even if this hasn\u2019t happened to you yet, we can all agree that it\u2019s a very stressful situation, and establishing a process for handling this is something you want to do ahead of time.\u00a0

But\u00a0how much<\/strong>\u00a0ahead of time are we talking about here?<\/p> \"\"

Feature toggles (aka feature flags)<\/strong><\/h2>

There are many ways to handle these types of outages, and it\u2019s important to establish a rollback procedure. In addition to that, we also use something called\u00a0feature toggles<\/strong>. It\u2019s not something unique to us, but it\u2019s a pretty sweet thing to have in your toolbox. For those unfamiliar with feature toggles, it\u2019s a mechanism that allows you to turn a feature on or off for a user\u00a0without needing to deploy the whole application<\/strong>. It\u2019s really simple, but it\u2019s huge!

Although it\u2019s called a \u201cfeature toggle\u201d, it doesn\u2019t necessarily mean that you have to use them for features only. You can use them basically for anything. Whether it\u2019s A\/B testing, refactoring a part of the screen, or navigating a user to a different page entirely! I\u2019m sure you can think of a couple of more examples that would be useful to you.<\/p> \"\"

This also allows us to oversee which users can access a certain change. This is helpful when trying to collect feedback or just observing how users interact with something you\u2019ve developed. Once you\u2019ve established your feature toggle system, you don\u2019t need to put in continuous work to keep it going. It\u2019s also a great way to manage the lifecycle of the change by progressively rolling it out to your canary, beta, and all users!\u00a0<\/p> \"\"

You gain a lot more control over who sees what, and the best part\u00a0is that turning\u00a0toggles on or off can be done by anyone! Someone like a product manager or customer support person could decide to turn a toggle on because it\u2019s just something that the customer needs. After a feature has been fully developed, the toggle can be globally released to all customers, and everyone can enjoy the stable version.

The number of annoyed users will decrease, and valuable feedback on changes will increase.\u00a0

It\u2019s also worth mentioning that you can base your whole QA process on the toggles. We can test a change by turning a toggle on, gathering feedback, and then turning the toggle off. When you have such fine-grained control, testing on production isn\u2019t a big deal! We also use these toggles in other environments, so you can isolate a change to a specific set of users on any server.

It\u2019s a win-win for everyone!<\/p>

Okay, but what about development?<\/strong><\/h2>

The main question that\u2019s probably going around in your head is how the feature toggles affect the development of a feature.

Feature toggles do complicate things a bit when writing code, but if you spend some time on planning, it can be done elegantly in most cases. You must be careful to add every change behind the toggle so nothing leaks when the toggle isn\u2019t turned on. Other people working on the feature must also be aware of using the toggle since it probably will span through multiple files and can sometimes be forgotten.<\/p> \"\"

Sometimes, it\u2019s not that complicated, but you gain a lot.\u00a0As I\u2019ve already mentioned, it can be used for basically anything, and complexity may increase, but it really is worth it:<\/p> \"\"

The added complexity isn\u2019t such a big drawback. You\u2019re getting a lot more out of feature toggles, and if that means that developers have to be a bit more careful when writing and reviewing code, so be it. It\u2019s much less stressful for a developer when they know a feature can be turned off if it\u2019s causing problems. This doesn\u2019t mean we approve of sloppy code, but sometimes, these things happen.

To conclude, feature toggles (once established) don\u2019t affect the development process as much, but they\u00a0offer a lot in return.<\/p>

Alleviating the downsides<\/strong><\/h2>

The first one does introduce technical debt, but if we create a task for deleting a toggle after it\u2019s been globally released, we can be sure that it will be deleted as soon as possible. The person who created the toggle is responsible for deleting it, which is a great way to handle this efficiently. In any case, deleting a toggle usually takes significantly less time than developing it!

As for the other issue, there are two ways to handle this. We can do either of these two:<\/p>