1

Feature toggles (or feature flags) enable me to deploy unfinished features without comprehensive manual testing of features toggled off. We can toggle the feature on for certain users, try it out, and then choose to toggle it off or on for all users. This enables more frequent integration as suggested by version control strategies such as Trunk-Based Development, and more frequent deployment of the trunk (master) branch into user's hands.

Sarbanes-Oxley rules require that all features that are in user's hands be fully tested.

So if I have a SOX-compliant system, how do I proceed with using feature toggles without having to do full manual testing of the feature toggled ON? It makes sense to do regression testing with the feature toggled OFF, but the most common need is to integrate and deploy good code but not incur the manual testing cost of the "on" state for a feature toggled off by default.

So any suggestions on ways to have Sox-compliant feature toggles without comprehensive manual testing of the toggled-off feature on every release?

Improve this question

1 Answer 1

Reset to default
1

It depends on how you're managing your feature flags. Ideally, you're using a flagging system that allows you to target specific users or segments of users so that an untested feature isn't inadvertently enabled for all your users. Some feature management systems (like LaunchDarkly) allow you to target users any way you want.

For example, a common workflow (for teams who use feature flags) is to release a new feature under a flag that's only turned on for the product team that's working on that feature. So, even if the feature hasn't been tested, it's guaranteed that only the right users have access to that new feature.

This allows your product team to continue to work on the feature and test it in production (if that's appropriate). Of course, a full set of tests should cover that feature before it's released, but it's nice that product teams have a way to iterate quickly without the hangups of a process that didn't involve feature flags.

Improve this answer
5
  • "So, even if the feature hasn't been tested, it's guaranteed that only the right users have access to that new feature." But if the toggle is changed, the "wrong" users might now have access to untested code, which I believe is a SOX violation. This is the whole point of feature toggles, to toggle who might have access. Thoughts?
    – Patrick Szalapski
    Oct 21, 2019 at 21:34
  • Maybe you are proposing that the feature toggles be untoggleable for ordinary users, and only be toggleable for testers, until the feature has been fully tested?
    – Patrick Szalapski
    Oct 21, 2019 at 21:35
  • "Maybe you are proposing that the feature toggles be untoggleable for ordinary users, and only be toggleable for testers, until the feature has been fully tested?" Yes. I'm only familiar with LaunchDarkly since that's the feature management system I've used, but in LD, you can specify who to target in the flag config. So, when you turn the flag on, it's only going to target the segment of users specified in the config. You'd have to manually change those targeting rules to change that.
    – manalang
    Oct 21, 2019 at 23:45
  • Okay, great. But the question remains that someone can toggle on the feature for some or all real users, and the feature toggled on will not have gone through the same SOX gate that the deployment did with the toggle off Are you saying that whenever a toggle changes for real users, the same SOX controls have to be in place as in a deployment?
    – Patrick Szalapski
    Oct 22, 2019 at 2:44
  • In the case of LaunchDarkly, every change to a flag is audited and can be traced to the user who made the change. Also, changes to different environments (like production) can be locked down with a role/policy. So, for example, you can be permissive about flag changes in staging, but not in prod. It's pretty adaptable to any process you want to comply with.
    – manalang
    Oct 22, 2019 at 4:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.