Find new more efficient trigger for auto-deploy pipelines
Currently auto-deploys are triggered on a schedule. This schedule is suitable for the most part, but I'm curious if there's a way we can potentially be more effective. Here's my unrefined thought.
- We know it takes roughly 1 hour to deploy to all of staging
- We know it takes roughly 1 hour to deploy to all of canary
- We have a mandatory baking period of 1 hour
- Plus between 1 and 2 hours of deploying to production
Depending on when the AMER team member is working, both due to the async nature of GitLab plus timezone shifts between members, we could get somewhere between 2-4 deploys out to production. Is there a differing way we can trigger pipelines that might be more effective or efficient?
Idea
Could we trigger a new auto-deploy pipeline after we reach some environment successfully? - Example might be as soon as canary finishes its deploy, it reaches out to create a new pipeline. Doing so makes when pipelines occur more dynamic but more suitably fits when various team members are able to work. Perhaps we create the trigger after staging?
Downsides
- This makes it more dynamic so we don't have a precise answer for WHEN an auto-deploy will begin
- ...
Advantages
- The goal here is that auto-deploy is waiting on us instead of us waiting on auto-deploy - we're crushing the schedule a bit if we find the right trigger
- ...
That schedule is configured here: https://ops.gitlab.net/gitlab-org/release/tools/-/pipeline_schedules/73/edit
The schedule as of this writing is 0,3,6,9,12,15,18,21
.