diff options
author | EuAndreh <eu@euandre.org> | 2020-11-03 15:35:49 -0300 |
---|---|---|
committer | EuAndreh <eu@euandre.org> | 2020-11-03 15:35:49 -0300 |
commit | 72e76d56ce5092b2d3bd3068c97f474647df93bf (patch) | |
tree | 484847db0e91cc492347eaee47e6402cf8f0880d /_articles | |
parent | Move other Nix files to nix/ (diff) | |
download | euandre.org-72e76d56ce5092b2d3bd3068c97f474647df93bf.tar.gz euandre.org-72e76d56ce5092b2d3bd3068c97f474647df93bf.tar.xz |
Feature flag article: start rewriting to make it more user friendly
Diffstat (limited to '')
-rw-r--r-- | _articles/2020-10-19-feature-flags-differences-between-backend-frontend-and-mobile.md | 83 |
1 files changed, 69 insertions, 14 deletions
diff --git a/_articles/2020-10-19-feature-flags-differences-between-backend-frontend-and-mobile.md b/_articles/2020-10-19-feature-flags-differences-between-backend-frontend-and-mobile.md index 74d4e15..49b8dd3 100644 --- a/_articles/2020-10-19-feature-flags-differences-between-backend-frontend-and-mobile.md +++ b/_articles/2020-10-19-feature-flags-differences-between-backend-frontend-and-mobile.md @@ -1,6 +1,7 @@ --- title: "Feature flags: differences between backend, frontend and mobile" date: 2020-10-19 +updated_at: 2020-11-03 layout: post lang: en ref: feature-flags-differences-between-backend-frontend-and-mobile @@ -10,13 +11,20 @@ category: presentation *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. +When discussing about feature flags, I find that their +costs and benefits are often well exposed and addressed. Online articles like +"[Feature Toggle (aka Feature Flags)][feature-flags-article]" do a great job of +explaining them in detail, giving great general guidance of how to apply +techniques to adopt it. -I'll try to make this distinction clear, with some final best practices I've -acquired when using them in production. +However the weight of those costs and benefits apply differently on backend, +frontend or mobile, and those differences aren't covered. In fact, many of them +stop making sense, or the decision of adopting a feature flag or not may change +depending on the environment. + +In this article I try to make the distinction between environments and how + feature flags apply to them, with some final best practices I've acquired when + using them in production. [presentation]: {% link _slides/2020-10-19-rollout-feature-flag-experiment-operational-toggle.slides %} [feature-flags-article]: https://martinfowler.com/articles/feature-toggles.html @@ -32,12 +40,40 @@ Feature flags in general tend to be cited on the context of > A: With techniques like canary, monitoring and alarms, feature flags, *etc.* -Even though adopting continuous deployment doesn't force you to use feature +Though adopting continuous 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: +on the code points you more obviously to continuous deployment. Take the +following code sample for example, that we will reference later on the article: + +```javascript +function processTransaction() { + validate(); + persist(); + // TODO: add call to notifyListeners() +} +``` + +While being developed, being tested for suitability or something similar, +`notifyListeners()` may not be included in the code at once. So instead of +keeping it on a separate, long-lived branch, a feature flag can decide when the +new, partially implemented function will be called: + +```javascript +function processTransaction() { + validate(); + persist(); + if (featureIsEnabled("activate-notify-listeners")) { + notifyListeners(); + } +} +``` + +This allows your code to include `notifyListeners()`, and decide when to call it +at runtime. For the price of extra things around the code, you get more +dynamicity. + +So the fundamental question to ask yourself when considering adding a feature +flag should be: > Am I willing to pay with code complexity to get dynamicity? @@ -52,6 +88,9 @@ absolutely worth the added complexity. This can vary a lot by code base, feature fundamentally by environment: its much cheaper to deploy a new version of a service than to release a new version of an app. +So the question of which environment is being targeted is key when reasoning +about costs and benefits of feature flags. + [cd]: https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment ## Control over the environment @@ -114,14 +153,30 @@ having a dynamic control on the code itself, but rollbacks are cheap enough that people usually do a normal deployment and just give some extra attention to the metrics dashboard. -On the **frontend**, CDN propagation delays and people not refreshing their web -pages are rollouts by themselves. You could do this by geographical region or -something similar, if desired. +Any time you see a blue/green deployment, there is a rollout happening: most +likely a load balancer is starting to direct traffic to the new server, until +reaching 100% of the traffic. Effectively, that is a rollout. + +On the **frontend**, you can selectively pick which user's will be able to +download the new version of a page. You could use geographical region, IP, +cookie or something similar to make this decision. + +CDN propagation delays and people not refreshing their web +pages are also rollouts by themselves, since old and new versions of the +software will coexist. On **mobile**, the Play Store allows you to perform fine-grained [staged rollouts][staged-rollouts], and the App Store allows you to perform limited [phased releases][phased-releases]. +Both for Android and iOS, the user plays the role of making the download. + +In summary: since you control the servers on the backend, you can do rollouts at +will, and those are often found automated away in base infrastructure. On the +frontend and on mobile, there are ways to make new versions available, but users +may not download them immediately, and many different versions of the software +end up coexisting. + [k8s]: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment [staged-rollouts]: https://support.google.com/googleplay/android-developer/answer/6346149?hl=en [phased-releases]: https://help.apple.com/app-store-connect/#/dev3d65fcee1 |