Extract GitlabSubscriptions::Features class
What does this MR do and why?
In this MR I extracted the "features" related code out of License
class and into a new GitlabSubscriptions::Features
class.
The reason why I nested this class under the existing GitlabSubscriptions
namespace is that:
-
GitlabSubscriptions::
is an existing namespace and each class must be nested to a domain-specific (or feature category) namespace. - Features defined here are those available after purchasing a subscription since for GitLab Core we don't need to check feature availability.
- Customers can purchase either a subscription for SaaS or self-managed but it's still a subscription.
- Today we have
GitlabSubscription
model to indicate that a customer bought a SaaS subscription. This probably might need to be renamed toSaasSubscription
to be clear. -
License
model is also a subscription but for self-managed. In factLicense.current.plan
matches one of the plans from our pricing page.- On Gitlab.com
License.current.plan
isUltimate
which means that SaaS is a special self-managed instance with an Ultimate license (so that all features are available) but where each namespace can have a different plan. - For this reason I think we could eventually move
License
toGitlabSubscriptions::License
andPlan
toGitlabSubscriptions::Plan
since these classes should also be nested into a domain namespace.
- On Gitlab.com
Notes about the concept of "plans"
- The Gitlab
Plan
model is what's assigned to aGitlabSubscription
(purchase of SaaS license) attached to a namespace. This is why you seeultimate_trial
,opensource
etc. But it also hasdefault
plan which is used on self-managed and that's the only plan self-managed uses. For example a namespace on self-managed always has adefault
plan. This was done so that we could allowPlanLimits
model to be used by self-managed admins to manage application limits. - The
License
class manages the installed license in the self-managed instance.- It shouldn't know about all features --> this is why I just extracted them out.
- It has a plan associated to it, which is not the
Plan
model but a simple string[starter, premium, ultimate]
which map the selection in our pricing page. (withstarter
probably to be discontinued). - This
☝ is whyLicense::PREMIUM_PLAN
may still make sense than using*_TIER
as I originally thought. So, I would stick to the term plan for now.
- Plans defined in
Plan
contain special plans that allow us to better manage SaaS subscriptions like*_trial
oropensource
(e.g. giving users onUltimate Trial
Ultimate features but Free plan limits). ButLicense::*_PLAN
s must be a subset ofPlan.all_plans
References
The idea of this refactoring was inspired by conversation we had in !80800 (closed) to try to understand how License/Plan/subscriptions could be better described in code.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Fabio Pitino