Spelling of feature flags article

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.