As you scale utilization it becomes increasingly important to have a strategy for how to best "clean up" splits. This should be a consideration from the very first split you create.
When creating new splits
- There are a variety of reasons for placing a change or new feature behind a split. The three main types of splits to consider:
Examples of Release Management splits
- I want to expose a feature to a subset of my traffic that meet a certain criterion (location, age, plan type)
- I want to safely do a progressive or gradual rollout for a potentially high impact feature, expose to 10% at first then gradually increase
Example of Experimental Splits
- I want to learn if the new version of an existing feature, or an entirely new feature, has a positive or negative impact on my business metrics
Example of Operational Control
- If this feature were to have an issue, it could potentially impact revenue or conversions, I want the ability to quickly revert back to the previous steady-state
When to Retire a Split
Now that you have splits in production, what are the indicators you might establish for when to retire a split.
- Splits that have not been modified within the past 30 days = eligible for retirement
- Splits that have received no traffic in the last 7 days = eligible for retirement
- Metrics show that you the split has proven the feature should be rolled out to everyone or removed from code = eligible for retirement
To surface the Splits that fall into the first two criteria, within the Environments tab in your Split dashboard you have the option to filter by;
- Active Splits
- "Killed" Splits
- Splits that have received traffic in the last 7 days
- Splits that have received no traffic in the last 7 days
- Splits that have seen no traffic at all
- Spits that have been modified in the last 7 days
- Splits that have not been modified in the last 30 days
For Consistency
- Before removing a split from code, ensure that everyone in the population is receiving the same intended treatment, essentially rolled out to 100%
Incorporating into your existing process:
- As part of the project within the existing Jira ticket (or the feature tracking tool of your choice) you can create a subtask for retiring the feature flag with a specific due date or time period
- There could also be a subtask within the ticket that states a mandatory split review/kill date
- Schedule a recurring cadence for the team to review and retire eligible splits
- Adopt a process to add a "retire" tag on the split once the rollout or experiment is complete
Comments
0 comments
Please sign in to leave a comment.