Application configuration
Description
We already provide some ways for people to control the configuration of their application. With Auto DevOps, you can use our default Helm chart, or you can provide your own. Auto DevOps listens to variables like PRODUCTION_REPLICAS to set the number of pods to spin up when deploying to production. We should explore more configuration options, and make these first-class parts of GitLab.
Proposal
- Make Auto DevOps configuration driven by variables: https://gitlab.com/gitlab-org/gitlab-ce/issues/37290
- Add more options to Auto DevOps configuration UI: https://gitlab.com/gitlab-org/gitlab-ce/issues/38547
- Scaling (with slider): https://gitlab.com/gitlab-org/gitlab-ce/issues/38543
- Auto Scaling: https://gitlab.com/gitlab-org/gitlab-ee/issues/3584
- Idling: https://gitlab.com/gitlab-org/gitlab-ee/issues/3585
- Deployment strategy (staging vs production) https://gitlab.com/gitlab-org/gitlab-ce/issues/38549
- Canary: https://gitlab.com/gitlab-org/gitlab-ce/issues/38550
- Services (postgres, redis, mongo, …): https://gitlab.com/gitlab-org/gitlab-ce/issues/32825, https://gitlab.com/gitlab-org/gitlab-ce/issues/38551
- Enable/Disable Auto DevOps jobs: https://gitlab.com/gitlab-org/gitlab-ee/issues/3586
Links / references
- Builds on https://gitlab.com/gitlab-org/gitlab-ce/issues/32825
- Depends on https://gitlab.com/gitlab-org/gitlab-ce/issues/37397
- Very similar to https://gitlab.com/gitlab-org/gitlab-ce/issues/32553
Documentation blurb
Overview
What is it? Why should someone use this feature? What is the underlying (business) problem? How do you use this feature?
Use cases
Who is this for? Provide one or more use cases.
Feature checklist
Make sure these are completed before closing the issue, with a link to the relevant commit.
- Feature assurance
- Documentation
- Added to features.yml
Activity
mentioned in issue #38547
@tauriedavis I imagine a first iteration would look very similar to
(from https://gitlab.com/gitlab-org/gitlab-ce/issues/32553), but under the Auto DevOps settings and instead of enabling staging and production apps, just set the strategy to automatically deploy to one or the other.
Edited by Mark Pundsack@tauriedavis But then also the scaling parts are really important, they just don't fit into the project settings as they'd be on a per-environment basis. I'm not sure exactly where they should go, as overloading the environments display seems like a bad idea.
@markpundsack for the presentation, I've added the options to it's own section under CI/CD settings. Does this align with all the variables we want to show at the time? I will add the environment slider separately as its on mockup on the environments page for the sake of the presentation but this mockup should include everything else we want to show.
Edited by Taurie DavisBut yeah, that looks complete.
Small thing, but the relationship between staging and canaries isn't obvious. I know why you did it that way, because you can only enable canaries if you're not automatically deploying to production, but it makes it look like you're deploying canaries to staging, but they're actually production canaries... Not sure how to fix. Maybe just include canaries as sub thing under production and have it disabled.
Some future iteration could improve the treatment of the services so that it supports an arbitrary number of services.
-
Okay, I was confused about the canaries thing. I thought it was for production but the issue seemed linked to staging. I understand now. Will just clarify using language for now but we should improve before any sort of implementation.
Edited by Taurie Davis It's linked in the sense that the way Auto DevOps is currently written, you can't enable canaries if you're auto deploying to production since promoting from canary to production is a manual step. There could be some world where we automatically promote from canary to production after X minutes or some production test or whatever.
@tauriedavis Also, if you're going to put the scale sliders elsewhere, you should probably move the autoscaling and idling stuff to the same place as they'd apply at the environment level, not project level. e.g. review apps might scale to 1 and idle, but production would autoscale between 10 and 20 apps and never idle.
-
@markpundsack I moved the environment configurations to a new environment configure section. Im not sure what Im looking at in terms of the heroku add ons.
Edited by Taurie Davis @tauriedavis looks great!
@tauriedavis Small thing, but with an app scaled to 156, it probably doesn't make sense to also have idling enabled.
