Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Figure out how we use feature flags in GOV.UK Frontend #4086

Open
1 of 4 tasks
owenatgov opened this issue Aug 14, 2023 · 4 comments
Open
1 of 4 tasks

Figure out how we use feature flags in GOV.UK Frontend #4086

owenatgov opened this issue Aug 14, 2023 · 4 comments
Assignees
@owenatgov
Labels
tech debt

Comments

@owenatgov
Copy link
Contributor

owenatgov commented Aug 14, 2023 •
edited
Loading

What

Investigate and formalise techniques and feature flags in GOV.UK Frontend.

Why

So that we can release and test features early and get feedback from users without having to bundle them in a single large release, which can be challenging to users.

Who needs to work on this

Developers

Who needs to review this

Developers

Notes

Problems to solve

  • Making it easier to turn feature flags "off" and "on" in the review app
  • How we handle features behind feature flags on the website
  • The process for adding something to the catalogue eg: a new component whilst we are supporting something behind a feature flag
  • Our policy for changes behind a feature flag eg: can we release breaking changes in minor versions behind a feature flag?
  • Conventions for naming feature flags
  • Use of build time (SCSS, .env) vs runtime (CSS, config options) feature flags

Prior usage

We have previously used feature flags for the following features:

Tasks
Beta Give feedback
  1. Create internal documentation on how to use feature flags design-system-team-docs#47
    documentation
    owenatgov
  2. Create user-facing documentation on our use of feature flags govuk-design-system#3386
    guidance
  3. Provide interface for turning feature flags on and off in the review app #4579
    feature request tooling
  4. Investigate ways to represent active feature flags on the design system govuk-design-system#3403
    🔍 investigation
@owenatgov
Copy link
Contributor Author

This will be coming up again soon with the typography work as we are broadly planning on releasing this behind a feature flag alphagov/govuk-design-system#2289

@colinrotherham
Copy link
Contributor

colinrotherham commented Aug 14, 2023 •
edited
Loading

For the review app in particular, we've used query strings in the past like ?legacy=true

They've been hard to persist across every page but perhaps a cookie could help?

Feature flags cookie

Using Express.js review app middleware, we could stamp feature flags into a cookie for easy recall:

https://govuk-frontend-review.herokuapp.com/?feature[name1]=true
https://govuk-frontend-review.herokuapp.com/?feature[name2]=true

Using bodyAttributes we could write to <body> tag ready for JSON.parse() in JavaScript

<body data-feature='{ "name1": true, "name2": true }'>

Or equally for CSS rules to hide behind the feature flag:

[data-feature*='"name1": true'] & {
  @include govuk-font($size: 16);
}

Feature flags JSON

For the Design System website, we deploy static HTML so can't change it at runtime

But we currently export the following JSON fixtures from GOV.UK Frontend for each component:

fixtures.json
macro-options.json

Could we add a new top-level features.json fixture or add per-component feature-only guidance?

We could configure or override these as Metalsmith .env() entries:
https://github.com/alphagov/govuk-design-system/blob/main/lib/metalsmith.js#L87-L100

Which makes them available to Nunjucks via calls such as env("NODE_ENV")
https://github.com/alphagov/govuk-design-system/blob/main/views/layouts/_generic.njk#L9

@querkmachine querkmachine mentioned this issue Sep 4, 2023
Closed
@owenatgov
Copy link
Contributor Author

There was some chat about this work in a DS/Kit tech leads catchup a few weeks ago. The main thoughts and ideas from this:

  • The Kit team use feature flags regularly and organise them into the following categories:
    • Experiments - early previews of work that is likely to be in a future release
    • Extended deprecation - A "reverse" feature flag that lets users use old features for an extended period of time, allowing them to move off of them incrementally
    • Feature flags - everything else, typically internal features
  • There's a hidden maintenance risk to using feature flags with more frequency. If we were operating with 2 feature flags at once, we would have 4 potential states to test against. This increases exponentially with each flag we add.
  • An idea to implement this on the design system website is to extend the component previews to detect feature flags and allow users to toggle them on or off.
  • We could leverage recent work done as part of Run a design sprint to scope WCAG 2.2 guidance needs govuk-design-system#3023 and Update and restructure documentation in Frontend and Design System sites for v4 and v5 govuk-design-system#2186 to figure out how to represent necessary changes in guidance between feature flag states.

@owenatgov owenatgov mentioned this issue Nov 13, 2023
Closed
3 tasks
@owenatgov
Copy link
Contributor Author

I struggled to find rationale on experimental features or feature flags or examples of feature flags in use in other open source UI frameworks except for Bootstrap:

  • They use sass variables to enable turning features on or off at the build phase. See example for css grid layout use in their docs on migrating to 5.1.0.
  • They state that features are experimental in their documentation. See example from their scrollspy options docs. I struggled to find details on how experimental features are defined or what the procedure is to move something out of being experimental.

The conclusions I draw from this light research is that this is fairly fertile ground in terms of how we define and manage experimental features. I'm going to press on with prototyping what a feature flag policy might look like.

This was referenced Dec 5, 2023
Merged
Closed
@owenatgov owenatgov mentioned this issue Dec 19, 2023
Open
3 tasks
@owenatgov owenatgov mentioned this issue Apr 8, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@owenatgov owenatgov

Labels
tech debt
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@colinrotherham @owenatgov