feature flag article+slides: Timestamp them with 2020/10/14

1 files changed, 0 insertions, 327 deletions

diff --git a/_slides/2020-10-09-rollout-feature-flag-experiment-operational-toggle.slides b/_slides/2020-10-09-rollout-feature-flag-experiment-operational-toggle.slides
deleted file mode 100644
index 775f567..0000000
--- a/_slides/2020-10-09-rollout-feature-flag-experiment-operational-toggle.slides
+++ /dev/null
@@ -1,327 +0,0 @@
----
-title: Rollout, feature flag, experiment, operational toggle
-date: 2020-10-09
-layout: slides
-lang: en
-ref: rollout-feature-flag-experiment-operational-toggle
-published: false
----
-
-# Rollout, feature flag, experiment, operational toggle
-Different use cases for **backend**, **frontend** and **mobile**
-
----
-
-"Feature flags" tend to come up when talking about **continuous deployment**
-
-???
-
-I'm using "quotes" because I'm mixing up different meanings of "rollout"
-
----
-
-# 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
-
----
-
-# Types:
-1. rollout
-2. feature flag
-3. experiment
-4. operational toggle
-
----
-
-# 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]
-
-[k8s]: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment
-[apk]: https://support.google.com/googleplay/android-developer/answer/6346149?hl=en
-
-???
-
-Relevant as long as the new code is deployed
-
----
-
-# 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`
-
-???
-
-Relevant as long as the new code is being developed
-
----
-
-# experiment
-## For analyzing behaviour
-
-**Medium-lived** using **allow list** and **A/B test**
-
-- `:debit-withdrawal-test`
-
----
-
-# operational toggle
-## For disabling features in `#crash`-like situations
-
-**Long-lived** using **percentage**
-
-- `:bank-barcode-payment`
-- `:savings-bank-barcode-query-provider`
-
-???
-
-Lives for as long as the code is in production.
-
-It feels like a system-level circuit breaker.
-
----
-
-We now know about the types
-
-## But they have different relevance for **backend**, **frontend** and **mobile**
-
----
-
-# backend
-
-1. **rollout**: k8s blue/green, canary and `common-rollout`
-2. **feature flag**: `common-rollout` and datasets
-3. **experiment**: `common-xp`
-4. **operational toggle**: `common-rollout`
-
-???
-
-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.
-
----
-
-# 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
-
----
-
-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!
-
----
-
-## **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".
-
----
-
-## **mobile**
-
-# Very limited control
-
-- app stores can restrict updates (worse for iOS)
-- customers still have to download new versions
-
----
-
-# Costs
-
-- more complex code
-- compatibility with old app versions
-- nesting is exponential
-
----
-
-# Benefits
-
-- dynamicity
-
----
-
-# Best practices
-
----
-
-## 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**
-
-{% raw %}
-```clojure [2-3]
-{:rules
- #{{:type    :include-list
-    :content {:filename "debit-team-members.txt"}}}}
-```
-{% endraw %}
-
----
-
-## 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 %}
-
----
-
-## Extend `common-rollout` if required
-
-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
-
----
-
-## 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".
-
----
-
-## Include a feature flag on the whiteboarding phase
-
----
-
-## Include deleting/retiring the feature flag at the end
-
----
-
-## 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?"
-
----
-
-## Thank you!
-
-References:
-
-1. these slides: [euandre.org/slides.html]({% link slides.md %})
-2. [prose version of this presentation]({% link _articles/2020-10-12-feature-flags-differences-between-backend-frontent-and-mobile.md %})
-3. ["Feature Toggles (aka Feature Flags)"](https://martinfowler.com/articles/feature-toggles.html),
- by Pete Hodgson
-4. [Continuous integration vs. continuous delivery vs. continuous deployment](https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment),
- by Sten Pittet
-5. [Accelerate](https://itrevolution.com/book/accelerate/),
- by N. Forsgren, J. Humble and G. Kim