1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
|
---
title: "Feature flags: differences between backend, frontend and mobile"
date: 2020-10-12
layout: post
lang: en
ref: feature-flags-differences-between-backend-frontent-and-mobile
category: presentation
published: false
---
*This article is derived from a [presentation][presentation] on the same
subject.*
When talking about [feature flags][feature-flags-article], I find that their
costs and benefits are often well exposed and addressed. However the weight of those
costs and benefits apply differently on backend, frontend or mobile, and those
differences aren't covered.
I'll try to make this distinction clear, with some final best practices I've
acquired when using them in production.
[presentation]: {% link _slides/2020-10-09-rollout-feature-flag-experiment-operational-toggle.slides %}
[feature-flags-article]: https://martinfowler.com/articles/feature-toggles.html
## Why feature flags
Feature flags in general tend to be cited on the context of
[continous deployment][cd]:
> A: With continous deployment, you deploy to production automatically
> B: But how do I handle deployment failures, partial features, *etc.*?
> A: With techniques like canary, monitoring and alarms, feature flags, *etc.*
Even though adopting continous deployment doesn't force you to use feature
flags, it creates a demand for it. The inverse is also true: using feature flags
on the code points you more obviously to continuous deployment.
But you should consider feature flags solely by taking into account this
distilled trade-off analysis:
> Am I willing to pay with code complexity to get dynamicity?
It is true that you can make the management of feature flags as
straightforward as possible, but having no feature flags is simpler than having
any. What you get in return is the ability to parameterize the behaviour of the
application in runtime, without doing any code changes.
Sometimes this added complexity may tilt the balance towards not using a feature
flag, and sometimes the flexibility of changing behaviour on runtime absolutely
is worth the added complexity. This can vary a lot by codebase, feature, but
fundamentally by environment: its much cheaper to deploy a new version of a
service than to release a new version of an app.
[cd]: https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment
## Rollout
## Feature flag
## Experiment
## Operational toggle
## Best practices
### Prefer dynamic content
Even though feature flags give you more dynamicity, they're still somewhat
manual: you have to create one for a specific feature and change it by hand.
If you find yourself manually updating a feature flags every other day, or
tweaking the percentages frequently, consider making it fully dynamic. Try
using a dataset that is generated automatically, or computing the content on the
fly.
Say you have a configuration screen with a list of options and sub-options, and
you're trying to find how to better structure this list. Instead of using a
feature flag for switching between 3 and 5 options, make it fully dynamic. This
way you'll be able to perform other tests that you didn't plan, and get more
flexibility out of it.
### Use :include-list for named groups
### Always use :app-version
Don't delete app-facing feature flags
### Beware of many nested feature flags
### Include a feature flag on the whiteboarding phase
### Include deleting/retiring the feature flag at the end
### Always rely on a feature flag on the app
There is no such thing as
[apple]: http://www.paulgraham.com/apple.html
|
