Follow up: Improve usability of rolling out feature flags env by env

Problem to solve

Follow up from #225453 (closed)

As a user, I want to explicitly turn feature flags off for a specific environment.

JTBD: As a developer, I want to graduate a feature between environments gradually, so I can test it out on staging (smoketest) before it hits production (my end users)

Intended users

User experience goal

It should be easy and clear from the configuration of environments in feature flags that you are configuring the feature flag to be off only for some environments.

Proposal

Acceptance criteria

  • A modal approach towards configuring environments scope
  • The modal features a checkbox tree view to increase/decrease env scope
    • Sub-items become selected by default if a higher hierarchy item has been selected
  • The modal features a search with the placeholder copy: Search or enter a wildcard
  • If a 2nd generation sub-tree has more than 3 sub-items (review env in this case) the rest of the items are not shown and a ... is displayed as the fourth item.
    • This intends for the user to refine their search query to be able to enable a specific subset of review env which are not displayed initially.
  • The modal features no pagination, but endlessly scrolls (though this scenario should almost be non existent as we don't list more than 3 items + ... per sub directory)
  • Once the search is entered the tree view is filtered down but retains its structure
  • If the user enters a wildcard all other search results vanish and a new wildcard option appears and can be activated
  • Once a wildcard is active it is shown separately from any other configured env scopes

Selecting existing subscope

Description Mockup (figma document)
Modal all_review_env__1_
Configured env scope outside the modal scope

Selecting all env scope

Description Mockup (figma document)
Modal all_env__1_
Configured env scope outside the modal scope__1_

Creating a custom scope

Description Mockup (figma document)
Modal Search_review_env
Configured env scope outside the modal scope__2_

Selecting a custom scope with wildcard

Description Mockup (figma document)
Modal Configure_review_wildcard__1_
Configured env scope outside the modal scope__3_

Follow-ups:

Breakdown

  1. frontend 1 for introducing Vuex Store
  2. backend 1 for updating the endpoint response
  3. frontend 1 for parsing using the response from the new endpoint
  4. frontend 1 for updating the overall UI

Note for the backend:

  • the API should make it possible to filter (search-like) and paginate environments
  • it should be considered also if the API for saving the settings needs to change, particularly introducing the syntax for top-level env (e.g. review/*)
  • update, I checked this, we should support the top-level/* syntax – not sure the BE will have to do anything there about this so I will leave the note

Further details

Our env scoping of feature flags is additive by default.

  1. disable a feature in production due to a bug being identified
  2. verify this has (temporarily) resolved the production issue
  3. investigate other use cases (different parameters, etc) in staging, toggling the feature on/off several times.
  4. work on a fix in development, then staging.
  5. deploy to production
  6. re-enable the feature in production

Permissions and Security

Documentation

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

Edited by Angelo Gulina