<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=472014) </details> <!--IssueSummary end--> <!-- Title suggestion: [Feature flag] Cleanup allow_protected_branches_for_group --> ## Summary This issue is to cleanup the `allow_protected_branches_for_group` feature flag, after the feature flag has been enabled by default for an appropriate amount of time in production. <!-- Short description of what the feature is about and link to relevant other issues. Ensure to note if the feature will be removed completely or will be productized--> https://gitlab.com/groups/gitlab-org/-/epics/8679+ Enables group level protected branches feature ## Owners - Team: ~"group::source code" - Most appropriate slack channel to reach out to: `#g_create_source-code-be` - Best individual to reach out to: @jwoodwardgl @j.seto - PM: @mcbabin ## Stakeholders <!-- Are there any other stages or teams involved that need to be kept in the loop? - Name of a PM - The Support Team - The Delivery Team --> ## Expectations ### What might happen if this goes wrong? <!-- Any MRs that need to be rolled back? Communication that needs to happen? What are some things you can think of that could go wrong - data loss or broken pages? --> We find buts in the implementation ### (Optional) Release the feature with the feature flag **WARNING:** This approach has the downside that it makes it difficult for us to [clean up](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) the flag. For example, on-premise users could disable the feature on their GitLab instance. But when you remove the flag at some point, they suddenly see the feature as enabled and they can't roll it back to the previous behavior. To avoid this potential breaking change, use this approach only for urgent matters. <details><summary>See instructions if you're sure about enabling the feature globally through the feature flag definition</summary> If you're still unsure whether the feature is [deemed stable](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release) but want to release it in the current milestone, you can change the default state of the feature flag to be enabled. To do so, follow these steps: - [ ] Create a merge request with the following changes. Ask for review and merge it. - [ ] If feature was enabled for various actors, ensure the feature has been enabled globally on production `/chatops run feature get allow_protected_branches_for_group`. If the feature has not been globally enabled then enable the feature globally using: `/chatops run feature set allow_protected_branches_for_group true` - [ ] Set the `default_enabled` attribute in [the feature flag definition](https://docs.gitlab.com/ee/development/feature_flags/#feature-flag-definition-and-validation) to `true`. - [ ] Decide [which changelog entry](https://docs.gitlab.com/ee/development/feature_flags/#changelog) is needed. - [ ] Ensure that the default-enabling MR has been included in the release package. If the merge request was deployed before [the monthly release was tagged](https://about.gitlab.com/handbook/engineering/releases/#self-managed-releases-1), the feature can be officially announced in a release blog post: `/chatops run release check <merge-request-url> <milestone>` - [ ] Consider cleaning up the feature flag from all environments by running these chatops command in `#production` channel. Otherwise these settings may override the default enabled: `/chatops run feature delete allow_protected_branches_for_group --dev --pre --staging --staging-ref --production` - [ ] Close [the feature issue][main-issue] to indicate the feature will be released in the current milestone. - [ ] Set the next milestone to this rollout issue for scheduling [the flag removal](#release-the-feature). - [ ] (Optional) You can [create a separate issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20Flag%20Cleanup) for scheduling the steps below to [Release the feature](#release-the-feature). - [ ] Set the title to "[Feature flag] Cleanup `allow_protected_branches_for_group`". - [ ] Execute the `/copy_metadata <this-rollout-issue-link>` quick action to copy the labels from this rollout issue. - [ ] Link this rollout issue as a related issue. - [ ] Close this rollout issue. </details> ### Cleaning up the feature flag <!-- The checklist here is to help stakeholders keep track of the feature flag status --> - [ ] Specify in the issue description if this feature will be removed completely or will be productized as part of the Feature Flag cleanup - [ ] Create a merge request to remove `allow_protected_branches_for_group` feature flag. Ask for review and merge it. - [ ] Remove all references to the feature flag from the codebase. - [ ] Remove the YAML definitions for the feature from the repository. - [ ] Create [a changelog entry](https://docs.gitlab.com/ee/development/feature_flags/#changelog). - [ ] Ensure that the cleanup MR has been deployed to both production and canary. If the merge request was deployed before [the code cutoff](https://about.gitlab.com/handbook/engineering/releases/#self-managed-releases-1), the feature can be officially announced in a release blog post. - [ ] `/chatops run auto_deploy status <merge-commit-of-cleanup-mr>` - [ ] Close [the feature issue](https://gitlab.com/groups/gitlab-org/-/epics/8679) to indicate the feature will be released in the current milestone. - [ ] If not already done, clean up the feature flag from all environments by running these chatops command in `#production` channel: `/chatops run feature delete allow_protected_branches_for_group --dev --pre --staging --staging-ref --production` - [ ] Close this rollout issue.