Moving DevOps Adoption from Ultimate to a Registration Feature
Overview
DevOps Adoption Reports has seen very slow adoption, and available only for GitLab Ultimate. We are considering downtiering some of the feature aspects to increase user adoption.
With GitLab Registration Features GitLab Free customers with a self-managed EE instance can receive paid features by registering with GitLab and sending us activity data via Service Ping.
What this looks like today
GitLab Ultimate users see:
- DevOps Adoption Overview
- DevOps Adoption Trend over time chart.
- DevOps Adoption by subgroups
- DevOps Adoption by categories tabs.
Proposal
Exposing the DevOps Adoption features to the Registration Features Program
users.
Expectations on GitLab team members
Please help SoftServe with any questions they may have, code reviews, approvals, and merges. Thanks!
Success Criteria
-
When the registration features sub-setting is On
, the feature set is provisioned in the instance -
When Service Ping is Off
=> No change toOff
behavior since release of &6144 (closed)- The sub-setting is set to
Off
- The sub-setting is disabled for selection
- The instance no longer receives the paid feature set
- The sub-setting is set to
-
This change should not change the instrumentation of this feature -
Updates docs: Add the feature to the list in this section and link to the docs for it. The regular documentation for the feature will still reflect that is it 'Premium'
Instructions
Note: Note - these instructions have been updated based on Update instructions on how to move paid feature... (#423232 - closed).
See the following MR for reference on adding features to the Registration Features program:
-
Implementation:
-
Move the feature symbol in GitlabSubscriptions::Features
from its corresponding tier in the<TIER>_FEATURES
constant to<TIER>_FEATURES_WITH_USAGE_PING
. If the feature is global, then don't remove it from theGLOBAL_FEATURES
constant. -
Test the feature manually using the following validation steps. If the feature isn't disabled/enabled properly, it might be coupled with the rest of the codebase in an unusual way. See !118760 (diffs) for an example, where a GitLab Geo feature relies on additional conditional checks. Ask the group owning the feature if you're not sure about the details. -
Add specs if you add new logic
-
-
Add the feature to the Registration Features docs
-
-
Validation steps:
- Testing previous behavior:
- Make sure you're on a Premium/Ultimate plan GitLab GDK instance
-
Try to use the feature - it should be enabled and working -
Include the steps to use the feature for the reviewer below: - Step 1.
- ...
- When registration features are enabled:
- Make sure you're on a free plan GitLab GDK instance (for example, remove current license or stub #current to return
nil
) - Make sure you have the registration features checkbox enabled (Admin -> Settings -> Metrics and profiling -> Usage statistics -> Enable Registration Features)
-
Try to use the feature - it should be enabled and working -
Include the steps to use the feature for the reviewer below: - Step 1.
- ...
- Make sure you're on a free plan GitLab GDK instance (for example, remove current license or stub #current to return
- When registration features are disabled:
- Make sure you're on a free plan GitLab GDK instance
- Make sure you have the registration features checkbox disabled (Admin -> Settings -> Metrics and profiling -> Usage statistics -> Enable Registration Features)
-
Try to use the feature - it should be disabled and not usable -
Include the steps to use the feature for the reviewer below: - Step 1.
- ...
- Make sure that the new text appears on the docs page:
- run
gdk restart gitlab-docs
- go to
<local_gitlab_docs_host>/ee/user/admin_area/settings/usage_statistics.html#registration-features-program
and make sure the new section is on the page and the link works
- run
- Testing previous behavior: