[Feature flag] Enable :cascading_namespace_settings
Feature
This feature uses the : cascading_namespace_settings
feature flag!
This feature enables the delayed project removal group setting to cascade upward if a subgroup does not have a setting value specified. In the short term, users should not notice a change in behavior. frontend work is in progress to really allow users to utilize the feature.
If users notice any behavior change, it will be that the value of 'delayed project removal' setting could change if an ancestor (parent group, on up the tree) changes the value of the setting. The subgroup can override the cascading setting by simply changing the value and saving.
Owners
- Team: Manage:Access
- Most appropriate slack channel to reach out to:
#g_manage_access
- Best individual to reach out to: @dblessing
- PM: @mushakov
Stakeholders
The Rollout Plan
-
Partial Rollout on GitLab.com with beta groups -
Rollout on GitLab.com for a certain period (How long) -
Percentage Rollout on GitLab.com - XX% If it is possible to perform an incremental rollout, this should be preferred. Proposed increments are: 10%
,50%
,100%
. Proposed minimum time between increments is 15 minutes. -
Rollout Feature for everyone as soon as it's ready
Beta Groups/Projects:
-
gitlab-org/gitlab
project -
gitlab-org
/gitlab-com
groups - ...
Expectations
What are we expecting to happen?
There should be no user-facing behavior change. The only way a user would be able to tell the feature was enabled is the value of the group setting "delayed project removal" may change if an ancestor group changes the default.
What might happen if this goes wrong?
After enablement, @dblessing will immediately test the functionality in a GitLab.com test group to verify intended behavior. If any errors are identified the feature flag will be disabled.
What can we monitor to detect problems with this?
Rollout Timeline
Initial Rollout
Preparation Phase
-
Enable on staging ( /chatops run feature set feature_name true --staging
) -
Test on staging -
Announce on the issue an estimated time this will be enabled on GitLab.com
Global Availability (More Info) (Please Note that Beta,Alpha and General Availability (GA) are handled on a product level and not the feature-flag)
- [-] Coordinate a time to enable the flag with
#production
and#g_delivery
on slack.
This feature flag represents a low-risk change. It is easily backed out by simply setting the flag to false again.
-
Announce on the issue an estimated time this will be enabled on GitLab.com -
Make the feature flag enabled by default i.e. Change default_enabled
totrue
-
Enable on GitLab.com by running chatops command in #production
(/chatops run feature set feature_name true
) -
Announce on the issue that the flag has been enabled -
Cross post chatops slack command to #support_gitlab-com
(more guidance when this is necessary in the dev docs) and in your team channel
Cleanup
This is an important phase, that should be either done in the next Milestone or as soon as possible. For the cleanup phase, please follow our documentation on how to clean up the feature flag.
-
Announce on the issue that the flag has been enabled -
Remove :feature_name
feature flag-
Remove all references to the feature flag from the codebase -
Remove the YAML definitions for the feature from the repository -
Create a Changelog Entry
-
-
Clean up the feature flag from all environments by running this chatops command in #production
channel/chatops run feature delete some_feature
.
Final Step
-
Close this rollout issue for the feature flag after the feature flag is removed from the codebase.
Rollback Steps
-
This feature can be disabled by running the following Chatops command:
/chatops run feature set cascading_namespace_settings false