Feature rollouts
Last updated
Was this helpful?
Last updated
Was this helpful?
You release features gradually to de-risk rollouts. It's better that only a few beta accounts encounter bugs rather than the entire user base.
Ideally, you first test internally and then roll out a limited release to beta customers. Once you've caught the major bugs or points of confusion, you release the feature to general availability.
This is how to use Bucket to safely roll out new features.
To roll out a feature in Bucket, you can use release stages or manually set access rules.
Access rules on Bucket are designed to simplify the rollout process in B2B companies.
The default access criteria are:
Company segments
Companies
Users
These criteria let you add segments, companies, or users without additional configuration.
If you'd like to specify a rollout percentage or create advanced access rules using company attributes, user attributes, feature access, or other contexts, you can add additional access rules with the "+ Add Rule" button.
Release stages let you easily signal features' rollout progress to your team and, optionally, set access rules for each stage of the rollout process.
Release stages are designed to support the common use case of taking a feature from development to internal testing to a beta testing phase, then finally released to everyone.
New apps come with 4 default release stages: In development, Internal, Beta, and General availability.
Release stages come with a set of default access rules.
The Beta stage doesn't include any default access rules. This makes it simple to select the relevant beta customers for each feature.
Access rules can be easily configured under the App Settings. You can update the rules to include No one, Everyone, or only specific segments, companies, or users.
You are also able to select a roll-out percentage for any chosen segments.
You can use release stages purely to signal a feature's rollout progress to the rest of the team without setting any default access rules.
Simply remove the default access rules and set the access rules to "Some" with no specified segments, companies, or users for your desired environments. This will give you empty access rules that can be manually defined for each feature.
When you create a new feature, it is placed in the "In development" stage by default. This release stage signals that a feature is currently being built.
The "Internal" stage signals a feature is ready for internal QA testing.
After internal QA testing is complete, a feature can be moved to the "Beta" stage. This stage signals that a feature is ready to be tested by a limited segment of users.
After rolling out a feature to your beta users and making any fixes, you can move to the "General availability" stage. This stage signals that a feature is now live to your general user base.
