diff options
Diffstat (limited to '')
| -rw-r--r-- | _articles/2020-10-14-feature-flags-differences-between-backend-frontent-and-mobile.md | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/_articles/2020-10-14-feature-flags-differences-between-backend-frontent-and-mobile.md b/_articles/2020-10-14-feature-flags-differences-between-backend-frontent-and-mobile.md index 2fa0104..4cc41e9 100644 --- a/_articles/2020-10-14-feature-flags-differences-between-backend-frontent-and-mobile.md +++ b/_articles/2020-10-14-feature-flags-differences-between-backend-frontent-and-mobile.md @@ -25,15 +25,15 @@ acquired when using them in production. ## Why feature flags Feature flags in general tend to be cited on the context of -[continous deployment][cd]: +[continuous deployment][cd]: -> A: With continous deployment, you deploy to production automatically +> A: With continuous 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 +Even 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. @@ -49,7 +49,7 @@ 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 +is worth the added complexity. This can vary a lot by code base, 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. |