In working with customers, one of the most common reasons I see that engineering teams choose to use feature flags is to be able to leverage a new system to separate the concept of feature release from code deployment. This separation provides a level of convenience and confidence to be able to deploy code into production without needing to expose new features to customers. In addition, it allows them to instantly control the release of their features without needing to go through a long CI/CD process.
With great power comes great responsibility
As teams implement feature flags, they see significant speed gains. But I also hear feedback that this speed makes it more difficult to remain compliant with internal and external policies governing customer experience changes. For teams in regulated industries like banking or health, who must remain compliant with SOX, SOC 2, etc., this makes feature flag adoption slower or stops it in its tracks.
As I spoke to more of our customers about this pain point, I found that many of them wanted to treat their Split rollout plans similarly to the version control methods that they use in their code repo and, specifically, that engineers wanted to review changes to feature flag rollout plans following the same process as a pull request on new code.
Change control with Approval Flows
Following our late-2019 release of enhanced audit logs, we’re excited to announce that we’ve added Approval Flows. Engineers using feature flags can now submit any changes that could affect their customers’ experience for approval. We believe Approval Flows will:
- Allow engineering teams to remain compliant with company policies and audits (e.g. SOC2 and SOX)
- Make it easy to adopt feature flags via engineering workflows teams are already familiar with
- Prevent risky changes from making it to production by enforcing review on specific changes
- Make it simple for both app dev and dev ops teams to see all the details of a change, including who made it, when, and why before it is deployed to production
Customize your approval workflow
With Approval Flows, every change to a feature flag can be submitted for approval. Since any change to a split (a feature flag) or segment (a set of users) will change production, this is as important to control as your normal build and deploy process.
When submitting a request, a developer can choose as many other team members or groups to review the change. Groups make it easy to get approval from any teams or managers who might stand between your code and your users.
Once an Approval Flow is activated, every selected approver will get an email notification to let them know their review has been requested. They will be prompted to log into Split to approve or reject the change and finalize the submission. If approved, the split or segment changes will go live, exposing new users to your latest and greatest feature.
As team members review changes, your audit log records will automatically be updated with all the change details, including everyone who touched the change, from the submitter to the approver(s). Engineers will also be able see the current status of changes to understand if changes are pending, approved, rejected, or withdrawn.
This is just our first step in making sure engineering teams can stay compliant while still leveraging the full power of feature flags. Make sure to subscribe to our releases to stay up to date on the enhancements we’ll be making in the next few months!
Have more ideas about how you want to use Approval Flows on your team (e.g. a multi-tier approval process)? Reach out to firstname.lastname@example.org to get in contact with our team.
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
A/B testing, otherwise known as split testing, is the process of testing two different versions of a web page, feature, user flow, or other resource in order to optimize for a metric or set of metrics (often conversion rate). Multivariate tests are run with a higher number of variables and…
The increased usage of feature flags and canary releases (also “canary deployments”) in software development has had a tremendous impact on the overall release process for software companies globally. These canaries and feature flags allow you to test your features in production , convert your monolith to microservices, perform A/B…
The ability to immediately propagate changes to SDKs is important to many customers, so we decided to invest in a real-time streaming architecture.