4 ms·

> users in Brazil get to see certain products, a special import-tax panel, etc, but no-one else does That's authorization. Feature flags were invented to enab

> users in Brazil get to see certain products, a special import-tax panel, etc, but no-one else does That's authorization. Feature flags were invented to enable continuous integration and trunk-based development. Ultimately, they're an alternative to feature branches. If you wouldn't create a git branch for it, you shouldn't create a feature flag for it.

brightball 4y ago
Exactly. Additionally, you roll out feature flags incrementally and hand control of them to your product team to use to gather user feedback. Beta users, alpha users, individual users or companies. It’s on a case by case basis as feedback is gathered to refine the feature before it goes to general availability. Another option that is getting popular is to randomly grant access to a certain percentage of users over a series of days to track the rollout and watch for errors/user complaints. Often, you end up capturing statistics for usage on wrapped features as well. These are all very different than authorization.
8note 4y ago
This is not mutually exclusive is the thing. Commonly, you will put a feature behind a feature flag, and roll it out locale by locale, or never. You build a new feature that only works for a certain place, and you turn it on via a feature flag, and then you expand it to new places, also using a feature flag I guess the question is when do you grant authorization? Before or after the feature has launched in a region?
jacknews 4y ago
This is just a different use of the same concept, as I and the article said. A feature flag grants or denies access to a feature in exactly the same way as authorization - you could have 'feature' attributes in an ABAC system for example, and in fact I'm sure many systems use exactly this to provide feature tiers. It's just that feature flags are generally used for a different purpose, ie targeted roll-out of new functionality, ie different policy concerns. So, different uses, different policies, but the same abstraction/concept.
creamyhorror 4y ago
I recently wrote a small generalised feature to enable us to turn on flags for specific locales, specific user groups, or specific individual users, all specified in JSON strings stored in a DB (and which the backend caches). Some flags add a function or widget, while other flags add restrictions or change cronjob behaviour. Is this an authorisation or a feature flag system, or neither?
- jdlshore 4y ago
  Sounds like it could be a component of the back end for either one. A complete feature flag system would also need a business-friendly front-end that product managers could use to roll out features and track how many people were using each one. Possibly an A/B testing component as well. And a way of alerting when a flag has been 100% active for X days so it could be removed from the code. Etc. A complete authorization system would need a front-end focused on understanding who had which capabilities, assigning capabilities to users and categories of users, and probably some sort of capability grouping and inheritance mechanism. Possibly an impersonation ability for the support team. Etc.

brightball 4y ago

Exactly. Additionally, you roll out feature flags incrementally and hand control of them to your product team to use to gather user feedback. Beta users, alpha users, individual users or companies. It’s on a case by case basis as feedback is gathered to refine the feature before it goes to general availability. Another option that is getting popular is to randomly grant access to a certain percentage of users over a series of days to track the rollout and watch for errors/user complaints. Often, you end up capturing statistics for usage on wrapped features as well. These are all very different than authorization.

8note 4y ago

This is not mutually exclusive is the thing. Commonly, you will put a feature behind a feature flag, and roll it out locale by locale, or never. You build a new feature that only works for a certain place, and you turn it on via a feature flag, and then you expand it to new places, also using a feature flag I guess the question is when do you grant authorization? Before or after the feature has launched in a region?

jacknews 4y ago

This is just a different use of the same concept, as I and the article said. A feature flag grants or denies access to a feature in exactly the same way as authorization - you could have 'feature' attributes in an ABAC system for example, and in fact I'm sure many systems use exactly this to provide feature tiers. It's just that feature flags are generally used for a different purpose, ie targeted roll-out of new functionality, ie different policy concerns. So, different uses, different policies, but the same abstraction/concept.

creamyhorror 4y ago

I recently wrote a small generalised feature to enable us to turn on flags for specific locales, specific user groups, or specific individual users, all specified in JSON strings stored in a DB (and which the backend caches). Some flags add a function or widget, while other flags add restrictions or change cronjob behaviour. Is this an authorisation or a feature flag system, or neither?

jdlshore 4y ago
Sounds like it could be a component of the back end for either one. A complete feature flag system would also need a business-friendly front-end that product managers could use to roll out features and track how many people were using each one. Possibly an A/B testing component as well. And a way of alerting when a flag has been 100% active for X days so it could be removed from the code. Etc. A complete authorization system would need a front-end focused on understanding who had which capabilities, assigning capabilities to users and categories of users, and probably some sort of capability grouping and inheritance mechanism. Possibly an impersonation ability for the support team. Etc.