When teams introduce new changes or new features in the platform and they want to:
When teams introduce new changes or new features in the platform and they want to control the population affected by the change or exposed to the new feature. Here are some cases when this occurs:
Early Beta | Gradual Rollout | Full Rollout | All Environments | Clean Up |
---|---|---|---|---|
Beta test in Production with individual users, courses, or percentage of population (both internal and external). Implement with CourseWaffleFlag or WaffleFlag as described above. Prepare to remove the flag after full rollout. Track this with a JIRA ticket. | Add courses in the Beta via CourseWaffleFlag or add percentage of users in the population via WaffleFlag. | Turn the feature on for everyone on the site (e.g., courses.edx.org). CourseWaffleFlag could be used to turn the feature off for a course that chooses to opt-out. But this delays completion of the feature, so use sparingly. | Other environments (e.g. edge.edx.org) may lag (or be ahead). Turn the feature on for environments that aren't yet using the flag and monitor any unexpected impact. | The feature has been rolled out to all edX environments. Remove the toggle from all code and configurations. If there is a strong reason to enable the Open edX community to have the same rollout capabilities, consider delaying clean-up until after the next Open edX release. |
When teams introduce new changes or new features that are not expected to be adopted by all open edX instances, either immediately or for a while. This case may co-exist with Case #1 or Case #2 above. So use the guidelines from the above cases to decide which Waffle technology to use.
WaffleFlag
and CourseWaffleFlag
, use the override_waffle_flag
decorator implemented in this testutils.py file.WaffleFlag: An edx-platform class that supports caching and name-spacing. Use this for all waffle flags outside a course. (See Waffle Utils.)
Waffle Utils: A set of Waffle related utilities, including CourseWaffleFlag and WaffleFlag.