Feature Management — Part II
Delivering product features with safeguards — Assurance and Deployments
Deployments
Canary releases, ring deployments, and percentage rollouts are different patterns for safely testing in production by progressively increasing the exposure of any new change.
Canary Deployment
Limited Exposure
Rolling out the change to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody.
Percentage Deployment
Limited Exposure
Small numbers of users are selected randomly to experience the new feature.
Ring Deployment
Gradual Exposure
Starts with small groups of low-risk users and expands through larger, higher-risk populations.
Assurance of Features
In order to assure your features working in production, you need to establish some base rules to compare what is going to be in release.
Monitoring/Baselines
Establish important baselines for your product. Measuring your new features against existing baselines helps to reduce the risk of change.
A/B Testing
Validating new ideas against the old ones. Serve multiple variations of a feature to different user segments.
User Feedback
The ability to release changes to a limited set of users makes it much easier to gather feedback about your product.
Dynamic Configuration Management
Customizing how users experience your application can be a powerful way to improve engagement and increase conversions, sales, and other business objectives.
Scaling to Large Teams
Rolling out feature flags across an entire development organization is not easy until and unless there are standard protocols to be followed.
Once you have standardized the protocols in all the teams, you will be able to enforce feature flags dividing the responsibilities among the different teams.
Permissions and RBACs
The feature management console is the source of truth, and it’s useful for anyone in your organization to be able to see the current, accurate state of the world for your application for any given customer. You can control just who can modify a feature flag using role-based access controls (RBAC).
Collaboration
- Document changes — Maintain a log of flag updates.
- Make updates visible — Communicate flag changes in real-time.
- Integrate — Connect your feature management platform to your other collaboration tools, like issue trackers or code repositories.
Organizing Flags
- Separate concerns — Divide your flags into smaller, related chunks based on functionality, microservice, or application tier or projects.
- Name your flags well — Divide your flags into smaller, related chunks based on functionality, microservice, or application tier or projects.
Adopt a naming convention that makes it clear at first glance what a flag is for, what part of the system it affects, and what it does.
Design
Design for Scale
Consider how information is delivered quickly to where it’s needed and how that information is updated when states change.
Design for Failure
Resilient to momentary interruptions, be able to re-establish a connection to your platform, and resynchronize to the true state of the world, all while the application is running.
Design for Collaboration
Assign an owner or maintainer with permissions and Role-Based Access Controls, keep an audit trail of changes made to each flag.
Maintenance
Appoint a Maintainer.
Responsible for recording the purpose of the flag, ensuring that it has a well-defined rollout plan, and eventually cleaning it up..
Set Expiration Dates
Give feature flags expiration dates at the time of creation. When a flag reaches its expiration date, you can be notified that it’s time to delete that flag.
Flag Removal Branches and Pull Requests
Create a branch and pull request (PR) to remove the flag at the same time the flag is introduced.
Finding Flag References
Use a naming convention that makes feature flag strings stand out. Name feature flags in commit messages.
Hope this helps in managing your product delivery and ease the process of continuous delivery!
Voila!!
Haven’t read Part I? Read here.
