Introduction
In 2025, more and more great companies are exploring options for implementing a feature toggle system, with the goal of initiating this process within the year. Specifically, they are interested in a service that can facilitate the integration of canary releases into their development cycle.
These companies typically release updates to production on a fixed schedule (such as every Friday) and are looking for ways to expedite the deployment process and improve their ability to implement fixes quickly.
This article will discuss best practice of how feature flags can be used to facilitate canary releases and expedite the deployment process.
What Slows Down the Deployment Process and Value Delivery in Modern Software Development?
In 2025, CI/CD is a must-have for every software development team. Integration and deployment automation are no longer the main bottlenecks in performance. Today, the primary bottleneck is the fear of deployment risks:
- Issues and bugs in production may lead to unhappy customers or even revenue loss.
- Multiple teams may need to be involved in evening deployments.
- The frustration of fixing, reviewing code, retesting, and redeploying repeatedly.
- Staging environments cannot fully simulate production conditions.
- Complaints from customers, internal teams, family, and friends.
To reduce deployment risks, teams often take actions that hurt company performance:
- Reject urgent but critical feature requests from the product or business team.
- Refuse to merge code three days before the delivery date.
- Maintain long-lived feature branches, increasing the risk of future code merges.
- And so on.
Some teams introduce Canary Deployments to mitigate risks, but the problems mentioned above still persist—and, in some cases, worsen:
- Customers may have already started using new features, so rolling back all features can cause significant confusion.
- To roll back only the faulty feature, the team must modify the code, review it, retest, and redeploy. This process itself may introduce new bugs.
- Managing multiple package versions for a single deployment adds complexity and overhead.
How to Expedite the Deployment Process with Feature Flags
Using a feature flag with an "if/else" statement, "annotation," or "wrapper" allows you to control whether a feature is enabled or disabled for specific users or groups. This is a simple and effective way to manage feature releases, helping to expedite the deployment process:
- Minimize the impact of bugs or issues on customers.
- No need for the team to be on standby late in the evening or on weekends.
- Accommodate urgent but important feature requests.
- Merge code just 1 hour before deployment time.
- Deploy on schedule, release the feature whenever you want.
- No code changes or redeployment are required to roll back the feature.
How Feature Flags Expedite Deployment
Here's a simple example to illustrate how feature flags accelerate the deployment process. Imagine you're planning a Friday night deployment that includes four new features:
Step 1: Use Feature Flags to Control New Features
Before the features are ready for release, use four feature flags to control them. Keep the feature flags turned off to disable the new features for all users.
With feature flags, developers can confidently accommodate urgent features in the deployment because, if any issues arise, they can roll back the feature immediately by turning off the feature flag without code changes and redeployment.
Step 2: Deploy the New Version on Friday Night
Deploy the new version of the application on Friday night. Customers won't see the new features since they are disabled by default through feature flags.
There’s no need for multiple teams to be on standby late in the evening or on weekends, because the new features remain disabled.
Step 3: Enable Features When Business Needs Them
On Monday morning, the responsible teams can enable features based on business needs. For example:
- The team responsible for Feature 1 turns on the feature flag to enable the feature for the QA team to test in production.
- If no bugs are found, the team starts rolling out the feature to familiar customers who can tolerate potential issues.
- If any bugs are detected, the responsible team can roll back the feature immediately without involving the development or DevOps teams using a user-friendly UI.
This means you can deploy on schedule and release the feature whenever you want, allowing features to be introduced at the right pace for the business.
Step 4: Gradual Rollout Until Full Release
If no issues are found, the team continues rolling out the feature progressively until all users have access to the new functionality.
This approach minimizes the impact of bugs or issues on customers while ensuring a smooth and controlled release.
Don't Use Feature Flags Incorrectly
Please use feature flags for the following purposes:
- Controlling new feature releases to reduce deployment risks.
- Experimental features for testing and feedback.
- A/B testing multiple versions of the same feature.
- Managing database or infrastructure migrations.
Avoid the following scenarios:
- Once a feature is fully released, you should remove the feature flag to keep the codebase clean. For example, the team can remove stale feature flags once a month.
- Avoid nesting feature flags under another feature flag. Feature flags are meant to control feature releases, not code logic.
- Don't use feature flags to merge unfinished features. Instead, break down large tasks into smaller stories and use feature flags to control those smaller features. This approach helps avoid long-lived feature branches with feature flags.
Advanced Feature Flag Usage
Check out the following articles to learn more about advanced feature flag usage: