Skip to content

[security_configuration_redesign] Feature Flag Rollout

Summary

This issue is to rollout the redesigned Secure Configuration Page on production, that is currently behind the security_configuration_redesign feature flag.

Toggling this feature-flag will enable Phase 1 of the according Epic

Within the same MR the docs also need to be adjusted:

Link to Docs: https://docs.gitlab.com/ee/user/application_security/configuration/

  • warning needs to be removed since this feature is now available for all
  • Add a sentence that there will be different experiences according to the User's licence.

It triggers the display between the current Secure Configuration Page and the redesigned one.

Owners

  • Team: Secure Analyzer Frontend Team
  • Most appropriate slack channel to reach out to: #s_secure-analyzer-frontend
  • Best individual to reach out to: @jannik_lehmann, @markrian
  • PM: @nmccorrison

Stakeholders

The Rollout Plan

  • Partial Rollout on GitLab.com with testing project(s)
  • Rollout on GitLab.com for a certain period (How long)
  • Percentage Rollout on GitLab.com
  • Rollout Feature for everyone as soon as it's ready

Testing Groups/Projects/Users

Expectations

What are we expecting to happen?

What might happen if this goes wrong?

What can we monitor to detect problems with this?

Rollout Steps

Rollout on non-production environments

  • Ensure that the feature MRs have been deployed to non-production environments.
    • /chatops run auto_deploy status <merge-commit-of-your-feature>
  • Enable the feature globally on non-production environments.
    • [-] /chatops run feature set security_configuration_redesign true --dev
    • /chatops run feature set security_configuration_redesign true --staging
  • Verify that the feature works as expected. Posting the QA result in this issue is preferable.

Preparation before production rollout

  • Ensure that the feature MRs have been deployed to both production and canary.
    • /chatops run auto_deploy status <merge-commit-of-your-feature>
  • Check if the feature flag change needs to be accompanied with a change management issue. Cross link the issue here if it does.
  • Ensure that you or a representative in development can be available for at least 2 hours after feature flag updates in production. If a different developer will be covering, or an exception is needed, please inform the oncall SRE by using the @sre-oncall Slack alias.
  • Ensure that documentation has been updated (More info). !64303 (merged)
  • Announce on this issue an estimated time this will be enabled on GitLab.com.
  • If the feature flag in code has an actor, enable it on GitLab.com for testing groups/projects.
    • /chatops run feature set --<actor-type>=<actor> security_configuration_redesign true
  • Verify that the feature works as expected. Posting the QA result in this issue is preferable.

Global rollout on production

  • Incrementally roll out the feature.
    • If the feature flag in code has an actor, perform actor-based rollout.
      • [-] /chatops run feature set security_configuration_redesign <rollout-percentage> --actors
    • If the feature flag in code does NOT have an actor, perform time-based rollout (random rollout).
      • [-] /chatops run feature set security_configuration_redesign <rollout-percentage>
    • Enable the feature globally on production environment.
      • /chatops run feature set security_configuration_redesign true
  • Announce on this issue that the feature has been globally 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
  • Wait for at least one day for the verification term.

Flag Removal / Release the feature

The removal phase is tracked in #333112 (closed).

Rollback Steps

  • This feature can be disabled by running the following Chatops command:
/chatops run feature set security_configuration_redesign false
Edited by Mark Florian