launchpad development|
⇤ ← Revision 1 as of 2011-02-15 06:50:55
Size: 351
Comment: stub documentation page
|
Size: 2847
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| FeatureFlags allow Launchpad's configuration to be changed while it's running, and for particular features or behaviours to be exposed to only a subset of users or requests. | = Feature Flags = '''FeatureFlags allow Launchpad's configuration to be changed while it's running, and for particular features or behaviours to be exposed to only a subset of users or requests.''' |
| Line 3: | Line 4: |
| See also: | == Scenarios == * Dark launches (aka embargoes: land code first, turn it on later) * Closed betas * Scram switches (omg daily builds are killing us, make it stop) * Soft/slow launch (let just a few users use it and see what happens) * Site-wide notification * Show an 'alpha', 'beta' or 'new!' badge next to a UI control, then later turn it off without a new rollout * Show developer-oriented UI only to developers (eg the query count) * Control page timeouts (or other resource limits) either per page id, or per user group * Set resource limits (eg address space cap) for jobs. == Concepts == A '''feature flag''' has a string name, and has a dynamically-determined value within a particular context such as a web or api request. The value in that context depends on determining which '''scopes''' are relevant to the context, and what '''rules''' exist for that flag and scopes. The rules are totally ordered and the highest-prority rule determines the relevant value. == Operations == A change to a flag in production counts as a production change: it is made by a LOSA on request from a squad lead, or other relevant manager. Ask in {{{#launchpad-ops}}} or {{{#launchpad-dev}}}. == Web interface == * https://launchpad.net/+feature-rules shows the currently active rules. This is visible to ~launchpad (developers etc) and writable by losas * https://launchpad.net/+feature-info describes the available features and scopes. == Debugging == A html comment at the bottom of rendered pages describes which features were looked up, and which scopes were consulted to make that decision. This doesn't include features that could be active but aren't relevant to the page, or scopes that may be active but aren't relevant to deciding the value of the features. == Performance == Feature flags are designed and intended to be fast enough that they can be used as much as is useful within reason. The result of a flag and of a scope is checked at most once per request. == Naming conventions == == Checking a feature flag == * Python code: {{{features.getFeatureFlag(name) => value}}} * TAL code: {{{<div tal:condition="features/name">hello world!"</div>}}} == Adding a new feature flag == == Adding a new scope controller == == See also == |
| Line 6: | Line 52: |
| * [[LEP/FeatureFlags]] | * [[LEP/FeatureFlags]] describing the original implementation concept |
| Line 8: | Line 54: |
| * [[http://people.canonical.com/~mwh/canonicalapi/lp.services.features.flags.FeatureController.html||apidocs]] |
Feature Flags
FeatureFlags allow Launchpad's configuration to be changed while it's running, and for particular features or behaviours to be exposed to only a subset of users or requests.
Scenarios
- Dark launches (aka embargoes: land code first, turn it on later)
- Closed betas
- Scram switches (omg daily builds are killing us, make it stop)
- Soft/slow launch (let just a few users use it and see what happens)
- Site-wide notification
- Show an 'alpha', 'beta' or 'new!' badge next to a UI control, then later turn it off without a new rollout
- Show developer-oriented UI only to developers (eg the query count)
- Control page timeouts (or other resource limits) either per page id, or per user group
- Set resource limits (eg address space cap) for jobs.
Concepts
A feature flag has a string name, and has a dynamically-determined value within a particular context such as a web or api request. The value in that context depends on determining which scopes are relevant to the context, and what rules exist for that flag and scopes. The rules are totally ordered and the highest-prority rule determines the relevant value.
Operations
A change to a flag in production counts as a production change: it is made by a LOSA on request from a squad lead, or other relevant manager. Ask in #launchpad-ops or #launchpad-dev.
Web interface
https://launchpad.net/+feature-rules shows the currently active rules. This is visible to ~launchpad (developers etc) and writable by losas
https://launchpad.net/+feature-info describes the available features and scopes.
Debugging
A html comment at the bottom of rendered pages describes which features were looked up, and which scopes were consulted to make that decision. This doesn't include features that could be active but aren't relevant to the page, or scopes that may be active but aren't relevant to deciding the value of the features.
Performance
Feature flags are designed and intended to be fast enough that they can be used as much as is useful within reason. The result of a flag and of a scope is checked at most once per request.
Naming conventions
Checking a feature flag
Python code: features.getFeatureFlag(name) => value
TAL code: <div tal:condition="features/name">hello world!"</div>
Adding a new feature flag
Adding a new scope controller
See also
LEP/FeatureFlags describing the original implementation concept
http://people.canonical.com/~mwh/canonicalapi/lp.services.features.flags.FeatureController.html
