-
Notifications
You must be signed in to change notification settings - Fork 402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs(feature-flags): create concrete documentation #594
docs(feature-flags): create concrete documentation #594
Conversation
…tools-python into feat/logger-reset-state * 'develop' of https://github.com/awslabs/aws-lambda-powertools-python: chore: fix path for PR auto-labelling chore(deps): bump boto3 from 1.17.88 to 1.17.89 (#466)
…tools-python into feat/logger-reset-state * 'develop' of https://github.com/awslabs/aws-lambda-powertools-python: chore: ignore codecov upload chore: reintroduce codecov token
…thon into develop
Codecov Report
@@ Coverage Diff @@
## develop #594 +/- ##
========================================
Coverage 99.95% 99.95%
========================================
Files 113 113
Lines 4535 4535
Branches 245 245
========================================
Hits 4533 4533
Partials 2 2
Continue to review full report at Codecov.
|
…ambda-powertools-python into docs/feature-toggle-examples
docs/utilities/feature_flags.md
Outdated
|
||
**Dynamic feature flags** are typically used for experiments where you'd want to enable a feature for a limited set of customers, for example A/B testing and Canary releases. These are better suited for this utility, as you can create multiple conditions on whether a feature flag should be `True` or `False`. | ||
**Dynamic feature flags** are typically used for experiments where you'd want to enable a feature for a limited set of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i dont think this is accurate. you can achieve the same thing with static flags. The dynamic part just allows you to change them faster without redeploying your service.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even if we can redploy fast (enough), without rules the flags will have the same value in our code execution, it doesn't make them dynamic. I think we can't achieve dyamic behaivour, say A/B testing, by just redeploying static flags.
docs/utilities/feature_flags.md
Outdated
|
||
!!! tip "Read [this article](https://martinfowler.com/articles/feature-toggles.html){target="_blank"} for more details on different types of feature flags and trade-offs" | ||
!!! tip "Read [this article](https://martinfowler.com/articles/feature-toggles.html){target="_blank"} for more details |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would appreciate a link to my original feature flags blog, but no pressure ;)
https://isenberg-ran.medium.com/aws-lambda-feature-toggles-made-simple-580b0c444233
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also a pretty good article https://www.atlassian.com/continuous-delivery/principles/feature-flags
Although Martin Fowler's blog is very comprehensive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CloudBees have their own implementaiton: https://www.cloudbees.com/blog/ultimate-feature-flag-guide
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ha! I have stumbled upon all of the mentioned articles by now 😅, we can make a list
docs/utilities/feature_flags.md
Outdated
} | ||
``` | ||
|
||
In this example the feature flag is **static**, which mean it will be evaluated without any additional context such as |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think global would be the better term. that's what i was going to say at the webinar too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
static is accurate when referencing a programming language. Something that constantly returns the same value regardless of the context.
Thanks Ran, and everyone, we’ll ping you once we have a draft for review.
…On Fri, 6 Aug 2021 at 19:39, Ran Isenberg ***@***.***> wrote:
***@***.**** requested changes on this pull request.
------------------------------
In docs/utilities/feature_flags.md
<#594 (comment)>
:
>
-**Dynamic feature flags** are typically used for experiments where you'd want to enable a feature for a limited set of customers, for example A/B testing and Canary releases. These are better suited for this utility, as you can create multiple conditions on whether a feature flag should be `True` or `False`.
+**Dynamic feature flags** are typically used for experiments where you'd want to enable a feature for a limited set of
i dont think this is accurate. you can achieve the same thing with static
flags. The dynamic part just allows you to change them faster without
redeploying your service.
------------------------------
In docs/utilities/feature_flags.md
<#594 (comment)>
:
>
-!!! tip "Read [this article](https://martinfowler.com/articles/feature-toggles.html){target="_blank"} for more details on different types of feature flags and trade-offs"
+!!! tip "Read [this article](https://martinfowler.com/articles/feature-toggles.html){target="_blank"} for more details
would appreciate a link to my original feature flags blog, but no pressure
;)
https://isenberg-ran.medium.com/aws-lambda-feature-toggles-made-simple-580b0c444233
------------------------------
In docs/utilities/feature_flags.md
<#594 (comment)>
:
>
## Terminology
-Feature flags are used to modify a system behaviour without having to change their code. These flags can be static or dynamic.
+Feature flags are used to modify a system behaviour without having to change their code. These flags can be static or
the static part is usually related to the part where they are not changed
without redeploying the code. The fact that you have a rule engine is a
different story. You can have dynamic toggles that dotn have rules. They
are dynamic becuase they are changed/stored in another place untreated to
the application.
I think "global" would be the better term here
------------------------------
In docs/utilities/feature_flags.md
<#594 (comment)>
:
> +
+ new_feature_active: bool = feature_flags.evaluate(name="new_feature",
+ default=False)
+ ```
+
+=== "features.json"
+
+ ```json
+ {
+ "new_feature": {
+ "default": true
+ }
+ }
+ ```
+
+In this example the feature flag is **static**, which mean it will be evaluated without any additional context such as
i think global would be the better term. that's what i was going to say at
the webinar too
------------------------------
In docs/utilities/feature_flags.md
<#594 (comment)>
:
> + new_feature_active: bool = feature_flags.evaluate(name="new_feature",
+ default=False)
+ ```
+
+=== "features.json"
+
+ ```json
+ {
+ "new_feature": {
+ "default": true
+ }
+ }
+ ```
+
+In this example the feature flag is **static**, which mean it will be evaluated without any additional context such as
+user or location. If you want to have **dynamic** feature flags that only works for specific user group or other contex
i just call these "smart flags", they change values according to session
input
------------------------------
In docs/utilities/feature_flags.md
<#594 (comment)>
:
> + "conditions": [
+ {
+ "action": "EQUALS",
+ "key": "tier",
+ "value": "premium"
+ }
+ ]
+ }
+ }
+ }
+ }
+ ```
+
+### Get all enabled features
+
+In cases where you need to get a list of all the features that are enabled you can use `get_enabled_features` method:
are enabled according to the input context
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#594 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZPQBGQN4KIIKNOBSSYE2DT3QM6JANCNFSM5BVKI4VQ>
.
|
…9d/aws-lambda-powertools-python into docs/feature-toggle-examples * 'docs/feature-toggle-examples' of https://github.com/am29d/aws-lambda-powertools-python: remove todo comments
You can use this flow image @heitorlessa |
The source file would be cool. In figma or which ever tool the cool kids are using today ;) |
=== "CDK" | ||
|
||
```typescript hl_lines="2-7 13-32 34-35 40 47 54" | ||
import * as cdk from '@aws-cdk/core'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@heitorlessa - i know this might seem be silly, but let's do the CDK example in python too.
Hey Michael, could you help converting that CDK to Python while I finish
dinner? ;-)
I’ll get back to finish polishing other parts soon
…On Tue, 10 Aug 2021 at 17:07, Michael Brewer ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In docs/utilities/feature_flags.md
<#594 (comment)>
:
> +
+ new_feature_active: bool = feature_flags.evaluate(name="new_feature",
+ default=False)
+ ```
+
+=== "features.json"
+
+ ```json
+ {
+ "new_feature": {
+ "default": true
+ }
+ }
+ ```
+
+In this example the feature flag is **static**, which mean it will be evaluated without any additional context such as
*static* is accurate when referencing a programming language. Something
that constantly returns the same value regardless of the context.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#594 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZPQBF3SMECDSFPQE6ZJATT4E6CVANCNFSM5BVKI4VQ>
.
|
…tools-python into docs/feature-toggle-examples * 'develop' of https://github.com/awslabs/aws-lambda-powertools-python: chore(deps): bump boto3 from 1.18.15 to 1.18.17 (#597) feat(feature flags): Add not_in action and rename contains to in (#589) chore(deps-dev): bump mkdocs-material from 7.2.2 to 7.2.3 (#596) chore(deps): bump boto3 from 1.18.1 to 1.18.15 (#591) chore(deps): bump codecov/codecov-action from 2.0.1 to 2.0.2 (#558) fix(deps): bump poetry to latest (#592) chore(deps-dev): bump mkdocs-material from 7.2.1 to 7.2.2 (#582)
As discussed with @risenberg-cyberark, the last part of doc review found an accidental bug - Multiple conditions are not being evaluated as an logic AND. I'll finalize docs as-is and start prepping the release mechanics in parallel |
MERGING - Thank you so much everyone @am29d @risenberg-cyberark @michaelbrewer @pcolazurdo. |
I'll keep the CDK sample in Typescript as-is instead of fixing for Python... we can do this later. |
I will take a crack at it, but low priority and not a blocker for release. |
@michaelbrewer i have a working python cdk version, will add it here |
Issue #, if available: aws-powertools/powertools-lambda#23
Description of changes:
Added documentation on feature flags.
Checklist
Breaking change checklist
RFC issue #:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.