kos/flippy

Feature flipper app for Django

flippy's Issues

Flag debugging - allow inspecting current state

Issue #6 talked about possibilities of easily toggling flags during development, this issue talks about viewing the current state of flags.

During development, a reasonable question to ask is "what flags are currently enabled for me?". This should be easy.

Idea: there's already a place for showing diagnostics like this, it's called Django Debug Toolbar - maybe one could just add a panel there?

Let Flag get state for a given user, not only HTTP request

Currently, the Flag has a get_state_for_request which accepts HTTP request. This is perfect for usage in views or very close to the API layer, but get's troublesome when the feature flag affects some logic deeper in the code.

I'd like to suggest implementing a similar method to one mentioned above, but accepting User instance instead of request. For example: get_state_for_user.

Rollout.flag_obj crashes if a flag gets renamed or removed

Repro:

• Create a flag
• Create a rollout with this flag
• Change the flag's id

Django admin now crashes on rollout list. Handle this gracefully.

Flag debugging capabilities

As a developer working on a Django app, I'd very much enjoy a possibility to quickly preview how a given page works with flag X enabled or disabled.

Say we have page "Recipes" and two different flags that control how this page look like, enable_foo and enable_bar. Without any special assistance from Flippy, in order to preview my page in all 4 combinations, I'd have to:

• open the Recipes page, preview
• log in as superuser, go to django admin, create a rollout for flag enable_foo, log back in as the original user
• open the Recipes page again, preview
• log in as superuser, go to django admin, create a different rollout for enable_bar, log back in
• open the Recipes page again, preview
• log in as superuser, go to django admin, delete the rollout for enable_foo, log back in
• open the Recipes page again, preview

This is an unacceptably long feedback loop for manual testing. (It's very suitable for automated unit testing, though - you'd just write 4 test cases with different set-up, or write one parametrized Pytest fixture for each feature flag)

Implementation idea: allow to temporarily set a flag for the duration of one request using special query string parameters, such as ?flippy_enable_foo=1. This would only take effect if debug mode is enabled in settings (DEBUG=True? FLIPPY_DEBUG_QUERY_PARAMS=True?).

Main trouble with this: ensure this works somehow for TypedFlags which aren't queried with a Request object, if at all possible.

Add safe guard for flag value calculation

Current implementation might cause HTTP 500 in case of buggy implementation of a subject. It'd be good to have a safe which will catch all exceptions, log them, and return default value (False would be sensible value in case problem occurs)

Allow rollouts for filtered subjects

Rationale

Currently each rollout can be configured to target either a subject, or a percentage-based slice of a subject.

There should be a way to further narrow down a subject by something meaningful. Assuming you have a subject "Users", you could derive filtered subjects along the lines of:

• "Users with email ending with..."
• "Users with id equal to..."

A possible implementation is to have a distinction between:

• plain Subjects
• filterable Subjects

where a filterable Subject can be parametrised with a string and the meaning of the string is specific to the particular Subject. This means that "Users with email..." and "Users with id..." would be separate subject classes that only differ by how they interpret the filter string. It would be difficult (UX wise) to provide a good way to do a single rollout for "Users with email ... or id ..."), unless you write a very specific Subject for this case & figure out a language that allows to encode the parameters in a single string.

Combining with percentage based rollouts

Since all Subjects already have a way to slice by percentage (built-in), we need to define how this would interact with filter strings.

A trivial implementation of implementing "roll out to 50% users with email ending with gmail.com" would be to test if the user's flag score is <= 50% and if the email ends with gmail.com. This should be in line with what the user expects as long as the flag score doesn't obviously correlate with the e-mail.