diff options
Diffstat (limited to 'src/content/en/slide/2020/10')
| -rw-r--r-- | src/content/en/slide/2020/10/19/feature-flags.adoc | 371 |
1 files changed, 136 insertions, 235 deletions
diff --git a/src/content/en/slide/2020/10/19/feature-flags.adoc b/src/content/en/slide/2020/10/19/feature-flags.adoc index 3a97621..553cf4c 100644 --- a/src/content/en/slide/2020/10/19/feature-flags.adoc +++ b/src/content/en/slide/2020/10/19/feature-flags.adoc @@ -1,329 +1,230 @@ -= Rollout, feature flag, experiment, operational toggle - -# Rollout, feature flag, experiment, operational toggle -Different use cases for **backend**, **frontend** and **mobile** - --- +# Rollout, feature flag, experiment, operational toggle -"Feature flags" tend to come up when talking about **continuous deployment** - -??? - -I'm using "quotes" because I'm mixing up different meanings of "rollout" +@Different use cases for backend, frontend and mobile --- - -# CI -continuous integration - -# CD -continuous delivery - -# CD -**continuous deployment** - -??? - -Background: build vocabulary, why are feature flags related to CD - -CI solves: manual integration of long-lived branches - -CD solves: automation of deployment process - -CD solves: releases as frequent as possible - -That's where the "GoCD" name comes from +. +. +. +# "Feature flags" tend to come up when talking about continuous deployment --- +. +. +. +. +@CI: continuous integration +. +@CD: continuous delivery +. +@CD: continuous deployment -# Types: +--- +## Types +. +. +. 1. rollout 2. feature flag 3. experiment 4. operational toggle +% {favicon.svg} --- +## Rollout -# rollout -## For *rolling out* a new version of software - -**Short-lived** using **percentages** - -- a [new deployment of k8s][k8s] -- new [APK released to the Play Store][apk] +# For *rolling out* a new version of software -[k8s]: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment -[apk]: https://support.google.com/googleplay/android-developer/answer/6346149?hl=en +Short-lived using percentages -??? - -Relevant as long as the new code is deployed +% FIXME: links +- a new deployment of kubernetes +- new APK released to the Play Store --- +## Feature flag -# feature flag -## For turning a feature *on* or *off* - -**Medium-lived** using **allow list**, **A/B test**, **percentage**, -**app version**, *etc*. - -- `:new-chargeback-flow` -- `:new-debit-card-activation-screen` +# For turning a feature *on* or *off* -??? +Medium-lived using allow list, A/B test, percentage, app version, etc. -Relevant as long as the new code is being developed +- :new-chargeback-flow +- :new-debit-card-activation-screen --- +## Experiment -# experiment -## For analyzing behaviour +# For analysing behaviour -**Medium-lived** using **allow list** and **A/B test** +Medium-lived using allow list and A/B test -- `:debit-withdrawal-test` +- :debit-withdrawal-test --- +## Operational toggle -# operational toggle -## For disabling features in `#crash`-like situations - -**Long-lived** using **percentage** - -- `:bank-barcode-payment` -- `:savings-bank-barcode-query-provider` +# For disabling features in #crash-like situations -??? +Long-lived using percentage -Lives for as long as the code is in production. - -It feels like a system-level circuit breaker. +- :bank-barcode-payment +- :savings-bank-barcode-query-provider --- - -We now know about the types - -## But they have different relevance for **backend**, **frontend** and **mobile** +. +. +@We know know about the types +# But they have different relevance for backend, frontend and mobile --- - -# backend - -1. **rollout**: k8s blue/green, canary and ~`common-rollout`~ `common-xp` -2. **feature flag**: ~`common-rollout`~ `common-xp` and datasets -3. **experiment**: `common-xp` -4. **operational toggle**: ~`common-rollout`~ `common-xp` - -??? - -This is a bit why common-rollout isn't called *common-feature-flag*: it was -initially designed with backend usage of mostly *rollouts* in mind, and just a -bit *feature flags*. - -Avoid using configuration for doing operational toggles: it is less dynamic, so -it defeats the purpose. +## backend +. +. +1. rollout: k8s blue/green, canary and ~common-rollout~ common-xp +2. feature flag: ~common-rollout~ common-xp and datasets +3. experiment: common-xp +4. operational toggle: ~common-rollout~ common-xp --- - -# frontend - -1. **rollout**: CDN and page refreshes -2. **feature flag**: percentages and maybe IPs (no `:customer/id` on the website) -3. **experiment**: via dynamic backend control -4. **operational toggle**: via dynamic backend control +## frontend +. +. +1. rollout: CDN and page refreshes +2. feature flag: percentages and maybe IPs (no :customer/id on the website) +3. experiment: via dynamic backend control +4. operational toggle: via dynamic backend control --- - -# mobile - -1. **rollout**: app stores -2. **feature flag**: via dynamic backend control -3. **experiment**: via dynamic backend control -4. **operational toggle**: via dynamic backend control +## backend +. +. +1. rollout: app stores +2. feature flag: via dynamic backend control +3. experiment: via dynamic backend control +4. operational toggle: via dynamic backend control --- - -Key differentiator is -## How much **control** we have over the **environment** +. +. +@Key differentiator is +# how much *control* we have over the environment --- - -## **backend** - -# Full control -🎉 - -??? - -Can edit, update and even delete rollouts as desired. - -Mix and match at will! +## backend +# full control +% FIXME: emoji +% 🎉 --- - -## **frontend** - -# Partial control - -When choose when to make a new version available - -??? - -We can control when a new version is available, partially when someone will -upgrade it. - -But it is easy to fallback to "reload the page and try again". +## frontend +# partial control +We choose when to make a new version available --- - -## **mobile** - -# Very limited control - +## mobile +# very limited control - app stores can restrict updates (worse for iOS) -- customers still have to download new versions +- customers still have to download new versions --- - # Costs - - more complex code - compatibility with old app versions - nesting is exponential --- - # Benefits - - dynamicity --- - -## Weighting costs × benefits - -The less control we have, the more we value dynamicity +## weighting costs × benefits +# The less control we have, the more we value dynamicity --- - -## Weighting costs × benefits - +## weighting costs × benefits +. +. +. - backend: sometimes worth the cost -- frontend: almost always worth cost -- mobile: **always** worth cost +- frontend: almost always worth the cost +- mobile: *always* worth the cost --- - +. +. +. # Best practices --- - -## Dynamic content > feature flag - -Always true for **mobile**, almost always for **frontend** +# dynamic content > feature flag +Always true for mobile, almost always for frontend --- +# Use :include-list for named groups +Always true for backend, frontend and mobile -## Use `:include-list` for named groups - -Always true for **backend**, **frontend** and **mobile** - -{% raw %} -```clojure [2-3] -{:rules - #{{:type :include-list - :content {:filename "debit-team-members.txt"}}}} -``` -{% endraw %} + {:rules + #{{:types :include-list + :content {:filename "debit-team-members.txt"}}}} --- +# Always use :app-version +Only for mobile -## Always use `:app-version` - -only for **mobile** - -{% raw %} -```clojure [2] -{:rules - #{{:type :app-version - :content {:min-version #{{:platform :android - :code 1000000} - {:platform :ios - :code 2000000}}}}}} -``` -{% endraw %} + {:rules + #{{:types :app-version + :content {:min-version #{{:platform :android + :code 1000000} + {:platform :ios + :code 2000000}}}}}} --- +# Extend ~common-rollout~ common-xp if required -## Extend ~`common-rollout`~ `common-xp` if required - -That's how `:include-list`, `:app-version`, *etc.* were born +That's how :include-list, :app-version, etc. were born --- - -## Beware of many nested feature flags - -True for **backend**, **frontend** and **mobile** - -??? - -Exponential growth of combinations +# Beware of many nested feature flags +True for backend, frontend and mobile --- - -## Don't delete app-facing feature flags - -True for **mobile** - -??? - -This could break old app versions, only do this intentionally - -We don't have (yet) a strategy for dealing with LTS of the app, and we just say: -"we'll support every app version out there". +# Don't delete app-facing feature flags +True for mobile --- - -## Include a feature flag on the whiteboarding phase +. +. +. +# Include a feature flag on the whiteboarding phase --- - -## Include deleting/retiring the feature flag at the end +. +. +. +# Include deleting/retiring the feature flag at the end --- - -## Avoid renaming a feature flag - -Use `:app-version` with `:min-version` instead +# Avoid renaming a feature flag +Use :app-version with :min-version instead --- - +. +. +. # And most importantly... --- - -# ***Always*** rely on a feature flag on the app - -Never do a hot fix, avoid expedited releases at all costs - -??? - -The app is where we have less control, so the feature flag is how we get some of -that control back. - -This doesn't mean you'll need 1 feature flag per PR - -There's not such thing as: -"This is such a small thing, it doesn't need a feature flag" - -You should ask yourself: -"It this crashes the app, am I OK with waiting for the next release train?" +# *Always* rely on a feature flag on the app +Never do a hotfix, avoid expedited releases at all costs --- - -## Thank you! - -References: - -1. "[Feature Toggles (aka Feature Flags)](https://martinfowler.com/articles/feature-toggles.html)", by Pete Hodgson -1. "[Continuous integration vs. continuous delivery vs. continuous deployment](https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment)", by Sten Pittet -1. [Accelerate](https://itrevolution.com/book/accelerate/), by N. Forsgren, J. Humble and G. Kim +## References +. +% FIXME: links +1. "Feature Toggles (aka Feature Flags)", by Pete Hodgson +2. "Continuous integration vs. delivery vs. deployment", by Sten Pittet +3. Accelerate, by N. Forsgren, J. Humble and G. Kim +4. these slides: euandre.org/slide/ +5. prose version of this presentation +6. view source |