From 2328ed8c41b874584b41f0a7c274923ebaf718f5 Mon Sep 17 00:00:00 2001
From: EuAndreh <eu@euandre.org>
Date: Wed, 30 Apr 2025 19:31:36 -0300
Subject: src/content/en/slide/: Update to WIP content format of eslaides(1)

---
 src/content/en/slide/2020/10/19/feature-flags.adoc | 371 ++++++++-------------
 1 file changed, 136 insertions(+), 235 deletions(-)

(limited to 'src/content/en/slide/2020/10/19/feature-flags.adoc')

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
-- 
cgit v1.2.3

