Automated staging deploys

Once the package is available, gstg main and canary stages should be automatically deployed.

MVP

When a new gitlab-ee package is available a pipeline is

The pipeline that will run the job will be on https://ops.gitlab.net/gitlab-org/takeoff/
Decide on the pipeline steps for deploying to staging. By splitting these out into multiple stages it will make it easier to retry in the case of failures.
- package warmup
- blessed node / migrations
- deploy to the fleet
- post deploy migrations (should be the first step or manually started as it prevents rollback)

First we need to determine if a new package is available https://gitlab.com/gitlab-org/release/framework/issues/53
- Trigger a pipeline immediately after the omnibus package pipeline finishes? This will need to issue an api call using a token for the pipeline to start.
- Check in once an hour to see if the package is ready for installation? This is probably frequent enough for automatic installs and the operation to check is likely a cheap one.
  - package cloud api or something that issues an apt-cache query?

Create a gitlab-qa step that starts with a subset of tests that are run https://gitlab.com/gitlab-org/release/framework/issues/60
Check for outstanding critical alerts

In order to trigger a rollback a version will need to be specified for the pipeline.

Git needs to be deployed before the rest of the fleet, to do this we will need a new flag passed to takeoff for rollback
The CICD pipeline should be paused when a rollback is required, via chatops
The pipeline will need to be initiated from chatops with a version string explicitly set

Edited Nov 12, 2018 by Marin Jankovski