zydronium/manage.get.gov
1
0
Fork 0
mirror of https://github.com/cisagov/manage.get.gov.git synced 2025-07-03 09:43:33 +02:00
Code Issues Projects Releases Packages Wiki Activity

updated title and added newline

Browse source
This commit is contained in:
Alysia Broddrick 2024-06-28 08:33:40 -07:00
parent 689e42da1b
commit 04fb04279b
No known key found for this signature in database
GPG key ID: 03917052CD0F06B7
1 changed files with 2 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

3
docs/architecture/decisions/0026-django-waffle-library.md
View file

@ -1,4 +1,4 @@
# 24. Production Release Cadence # 26. Django Waffle library for Feature Flags
Date: 2024-07-06 Date: 2024-07-06
@ -20,6 +20,7 @@ This brought us to finding solutions that could fix one or both of these problem
The environment allows developers to set a true or false value to the given variable, allowing implementation over multiple sprints when new features are encapsulated with this variable. The feature shows when the variable is on (true); otherwise, it remains hidden. Environment variables are also innate to Django, making them free to use; on top of that, we already use them for other things in our code. The environment allows developers to set a true or false value to the given variable, allowing implementation over multiple sprints when new features are encapsulated with this variable. The feature shows when the variable is on (true); otherwise, it remains hidden. Environment variables are also innate to Django, making them free to use; on top of that, we already use them for other things in our code.
The downside is that you would need to go to cloud.gov or use the cf CLI to see the current settings on a sandbox. This is very technical, meaning only developers would really be able to see what features were set, and we would be the only ones able to adjust them. It would also be easy to accidentally have the feature on or off without noticing. This also would not solve the problem of turning features on and off quickly for a given user group. The downside is that you would need to go to cloud.gov or use the cf CLI to see the current settings on a sandbox. This is very technical, meaning only developers would really be able to see what features were set, and we would be the only ones able to adjust them. It would also be easy to accidentally have the feature on or off without noticing. This also would not solve the problem of turning features on and off quickly for a given user group.
**Option 2:** Feature branches **Option 2:** Feature branches
Like environment variables, using feature branches would be free and allow us to iterate on developing big features over multiple sprints. We would make a feature branch that developers working on that feature would push and pull from to iterate on. This quickly brings us to the downsides of this approach. Like environment variables, using feature branches would be free and allow us to iterate on developing big features over multiple sprints. We would make a feature branch that developers working on that feature would push and pull from to iterate on. This quickly brings us to the downsides of this approach.