Today’s developers (and users) work quickly. We’re accustomed to instant gratification, so much so that meeting user expectations for improvements and updates can begin to feel impossible. Best-in-class development teams are employing continuous delivery and deployment in order to meet the rising expectations, but this can be a strain on your resources if you don’t approach implementation the right way.
In this post, we’ll explore how feature flags and remote config make continuous delivery attainable for teams of all sizes.
What is continuous delivery?
Continuous delivery is a strategy for developing where you build and test quickly and iteratively. This strategy enables more frequent, smaller updates. By making incremental changes each time, there’s a reduced risk for each deployment.
Continuous delivery takes a lot of effort on the backend to enable if you don’t practice it today, but the benefits make it worth your effort. If your team has to manually roll out updates and monitor user response, it becomes challenging to continue developing and optimizing new features. The only way to be successful with continuous delivery is through a repeatable, straightforward deployment process.
How should deployment and release differ?
Continuous delivery is designed to enable deployment at any time and, according to Martin Fowler, continuous deployment requires continuous delivery. Today, it’s no longer a best practice to release features to your user base without deploying those features to a subset of users for testing first.
The same short-cycle delivery process can and should be applied to your strategy for deployment. By implementing both strategies, you’re able to reduce your risk through incremental changes, reduced costs, and frequent updates.
Through staged releases, you can ensure each new feature deployed performs as expected before exposing your entire user base to a risky update. This method of decoupling deployment and release makes it easier to achieve continuous deployment by deploying behind feature flags that only get toggled on when a release is scheduled.
How can feature flags enable decoupled deployment and release?
Feature Flags allow you to switch features on or off for different users or groups of users, so they make it easy to deploy features to a subset of users before releasing them to a wider user base. If something goes wrong during deployment, the feature toggle makes it easy to switch a feature back off. If your new feature is performing as expected, you can continue to deploy it to more users for volume testing before releasing it to your wider user base.
Feature flags enable no-code deployment for application updates, streamlining the process significantly. Rolling out new features with feature flags allows your team to focus their efforts on developing the product for your customers, instead of on repetitive deployment tasks.
We cover this topic even more in depth in Deployment is not a release; a step-by-step example with feature flags.
Why should my team consider using feature flags?
Feature flags enable decoupled deployment and release for teams of all sizes, enabling continuous delivery. This enhances your user experience by enabling rapid update releases, ensuring you can continue meeting your users’ needs. It also improves user experience because it helps identify issues before releasing them to your entire user base.
Last but not least, a feature flag deployment strategy enables automation of the software release process, taking away the need for manual effort. By automating repeatable tasks, it’s possible to free up developer time and improve productivity.
