Auto DevOps Configuration
Problem to solve
- Teams need to be able to customize Auto DevOps; disabling certain functionality and controlling certain choices
- People don't understand what Auto DevOps is capable of
- People don't understand what is required for various parts of Auto DevOps to work
Further details
While thinking about solving (2) and (3) above, it seems that one way to show people what Auto DevOps consists of and what it depends on is to actually list out everything that is part of Auto DevOps and show certain parts as disabled if prerequisites aren't met (with helpful explanations, of course).
So from https://about.gitlab.com/auto-devops/, we see that Auto DevOps has 12 components:
- Build
- Test
- Code Quality
- SAST
- Dependency Scanning
- License Management
- Container Scanning
- Review Apps
- DAST
- Browser Performance Testing
- Deploy
- Monitoring
But some of those require Premium or Ultimate subscriptions, and some require at least one Kubernetes cluster to be connected to the project. Some of these can be disabled independently, but disabling some will impact related components.
-
Build -
Test -
Code Quality (requires Premium) -
SAST (requires Ultimate) -
Dependency Scanning (requires Ultimate) -
License Management (requires Ultimate) -
Container Scanning (depends on Build) (requires Ultimate) -
Review Apps (depends on Kubernetes) -
DAST (depends on Review Apps, although we could theoretically run on production) (requires Ultimate) -
Browser Performance Testing (depends on Review Apps, although some version could work on master only) (requires Premium) -
Deploy (depends on Build) (Depends on Kubernetes) -
Monitoring (depends on Deploy)
Build has a choice for BUILDPACK_URL
.
SAST has choice for SAST_CONFIDENCE_LEVEL
.
Dependency Scanning can disable remote checks (DEP_SCAN_DISABLE_REMOTE_CHECKS
).
And then Deploy actually has a couple configuration choices
-
Continuous deployment to production -
Automatic deployment to staging, manual deployment to production -
Straight deployment to production -
Deploy to production via canary -
Deploy to production via incremental rollouts
-
And Deploy has AUTO_DEVOPS_CHART
, REPLICAS
(and PRODUCTION_REPLICAS
, CANARY_REPLICAS
), POSTGRES_ENABLED
(and POSTGRES_USER
, POSTGRES_PASSWORD
, POSTGRES_DB
). Replicas should be set via the Deploy Board though (although I really wish this was visible as variables too and even if not, potentially it should be in the Application Control Panel anyway). Enabling/disabling postgres, redis, etc. should be here, but the user, password, and other details shouldn't be front-and-center.
And then there's AUTO_DEVOPS_DOMAIN
, which should actually evolve to CLUSTER_WILDCARD_DOMAIN
or something like that.
There will be more values over time. Like setting individual custom domains for production.
Proposal
Present the various components and configuration choices in a single configuration form where some elements are disabled explaining why and how to enable them. Alternatively, don't put all the information in a single form, but pick the components first, and then configure settings for the components separately. Or maybe even inline or popup. To the extent that all of the environment variables mentioned above are "advanced options" that aren't necessary, they could be put behind an options or settings link/button. But picking the staging/canary/rollout feels like an important choice to surface as teams will legitimately want one over the other.
-
Build -
Test -
Code Quality (requires Premium) -
SAST (requires Ultimate) -
Dependency Scanning (requires Ultimate) -
License Management (requires Ultimate) -
Container Scanning (depends on Build) (requires Ultimate) -
Review Apps (depends on Kubernetes) -
DAST (depends on Review Apps, although we could theoretically run on production) (requires Ultimate) -
Browser Performance Testing (depends on Review Apps, although some version could work on master only) (requires Premium)
-
-
Deploy (depends on Build) (Depends on Kubernetes) -
Continuous deployment to production -
Automatic deployment to staging, manual deployment to production -
Straight deployment to production -
Deploy to production via canary -
Deploy to production via incremental rollouts
-
-
Monitoring (depends on Deploy)
-
Lastly, provide a few shortcuts that configure things in common patterns like:
-
Test -
Test, Code Quality, and Security (everything that doesn't require k8s - requires Ultimate) -
Everything
What does success look like, and how can we measure that?
(If no way to measure success, link to an issue that will implement a way to measure this)