Timed jobs
Description
When deploying to production, it's often useful to deploy to a canary first, and then if there are no problems, deploy to production automatically. We currently let you deploy this way, but with a manual approval to production. We should support some kind of time-based promotion to production. We have an issue for incremental, timed rollout (https://gitlab.com/gitlab-org/gitlab-ee/issues/1660), but maybe a smaller, more general iteration would be to have timed jobs. e.g. run this job 3 hours after this other job succeeded (unless it's cancelled manually or via API).
It could also help with Auto DevOps so we could put canary into the auto flow (although I'm not sure that would be our default behavior, but it could be available as a settable option).
Proposal
job:
when: 3 hours
Also on Environments page, add a notice that a canary deploy is in progress and buttons to accelerate promotion to production, block promotion to production, and revert canary. (Maybe the last two are a single function if often done together, but at this point, I'm not sure if people would want the canary around for testing. Probably not, as it presumably impacts productivity of whoever is using it.)
Links / references
- Somewhat inspired from https://code.facebook.com/posts/270314900139291/rapid-release-at-massive-scale/
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