Add a feature flag that rolls out "Auto DevOps on by default" so that we can do a percentage of projects rollout of Auto DevOps being enabled by default.
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
@bikebilly Would it be possible for us to throttle this rollout somehow? i.e. certain # of projects, certain # of orgs. It's impossible to know the impact of flipping this bit site-wide all at once.
@edjdev thanks for jumping in, we need discussion about that to ensure we will not get burned.
This is an admin setting, and once turned on all the projects that have the default to "use instance default" will get the change. I don't see a simple way to enable just a few projects at a time, unless we want to do some sort of incremental feature flag that inhibits the default behavior. Maybe @ayufan can help with the engineering side of the story.
Consider that we also want to automatically stop auto devops pipelines after a couple of failures to avoid wasting resources for projects that are not compatible with our template.
Looking at this from a different angle, once all the projects will be "enabled", we should consider that potentially any push will raise a pipeline, so even an incremental rollout will mitigate the problem only for the time it will run, not after. More considerations in https://gitlab.com/gitlab-com/infrastructure/issues/2632.
is a incremental rollout still required or do we feel comfortable turning on for everyone?
@danielgruesso seems like incremental rollout would be the wise decision regardless of if we can foresee any issues. We do always have an off switch that we can flick back off if we run into problems but I'm thinking that it still might be wise to find out what happens if we turn it on for 1% of our projects. I guess we'd need to do more work to accomplish that, however.
We could add a feature flag that would overwrite application setting. Currently, this is on-off. This feature flag (using flipper) should take into account projects to have a persistent project to use the auto-devops. We could make this feature flag to enable it by project or percentage-of-projects.
I'm not a big fan of extending application settings control to give rollout settings there. So I would say:
enable app setting (make it on by default),
use a Flipper feature flag for rollout deployment based on project-id and/or percentage-of-projects.
@ayufan how should this feature flag interact with the admin setting on gitlab.com?
Will we require the admin setting to be turned on but then we will still be using the feature flag value? Or will we allow the admin setting to remain off but then if the feature flag is enabled for the project percentage we then enable the auto devops anyway?
Presumably in the event of the first case we'll need to ensure this does not then mean on-premise customers now have auto devops disabled because they've turned it on but haven't touched the feature flag yet. In the event of the second option we will not be able to turn it off from admin UI if the feature flag is enabled (maybe this is not a problem...) but it will be a little confusing. Given this is temporary on gitlab.com only then maybe it would not be much of a problem.
Also are we going to have problems if there is no domain set? Presumably no projects are going to actually be doing deploys unless they have already configured a cluster and domain anyway so it will only really be the build and test phases that are doing anything for customers that haven't already set everything up.
Unfortunately, our feature flags are not very intuitive, we cannot make something on by default (or we can via db/migrate), so I see the following options:
It works only when Default to Auto DevOps...
We use negative flag to disable being on: auto_devops_off_by_default with conjuction to admin setting, so admin setting represents global intent, but feature flag represents a way to do gradual rollout,
Since we use the FF, it could be properly presented in Project settings where we show the Instance default whether when FF feature is on or off by default for given project.
However, I dislike the negative FF, so maybe we can do a positive one: current_application_settings.autodevops_enabled? && Feature.enabled?('autodevops_on_by_default'), but then we have to populate a database with enabling that FF on install time:
create db/migration that does: Feature.enable(''),
create db/fixtures/production|development/enable_autodevops.rb that does Feature.enable('').
It seems that we have to change:
Likely we have to simplify this code to make it to use a single source of truth, like one method to check if auto_devops_is_globally_enabled_for_project?.
@ayufan I don't understand why it needs to involve doing database migrations. Since we want to be rolling it out ourselves with the feature flag we can just leave the admin setting off and do the following:
@DylanGriffith It works, I used the && instead of ||. It improves visibility, as FF is effective only when you tick that via Admin settings, not regardless of that. Your approach is simpler, mine slightly over-engineered, but both achieve the same goal, only differ in visibility.
But with your approach, we can also show that in Admin settings that this is enabled via feature flag with the gradual rollout.
.form-text.text-muted=s_('CICD|The Auto DevOps pipeline will run if no alternative CI configuration file is found.')-ifFeature.enabled?('force_autodevops_on_by_default')="Feature is enabled via feature flag (show gradual rollout info) with link to documentation"