Identify deployer tasks that could be moved into release-tools
At &154 (comment 451670520) @jarv wrote a brief description of the tasks that today belongs to the deployer
.
I propose we convert that list into a set of issues for Phase 2:
-
Environment locking #1482 (closed) - This ensures that from the time we tell chef that it should stop installing the EE package on chef runs, to the time when we update chef with the new version of omnibus and re-enable intalls on chef runs, that no other deploys can happen on that environment -
Haproxy checks #1484 (closed) - This ensure that all servers for an environment are READY or in MAINT before we proceed with a deploy. We use Ansible inventory to get the list of HAProxy servers but since that is sourced from the Chef server we could also do it in a ruby script. Example of getting HAProxy in chatops could be modified for this. -
Package check #1485 (closed) - This does a check to ensure that package is indexed in package cloud, we may want to make this part of the check that the package is ready to be deployed. -
Asset sync #1486 (closed) - This does an rsync of assets to the asset bucket. To do this, it either uses the registry image that was created for assets, or extracts it from the package. Maybe it would be better to leave this in deployer but there is no Ansible requirement for this. -
Omnibus version update before and after #1487 (closed) - This is a script that updates a chef role to disable/enable package installs on chef runs, and updates the version after the deploy is complete. -
Grafana annotations #1488 (closed) - Adds grafana annoations before and after deploy -
Slack notification #1489 (closed) - Slack notifications before and after deploy -
QA triggers #1490 (closed) - Triggers QA runs, smoke/reliable tests after staging and canary. For canary we trigger QA for both the canary stage and the main stage, the reason for this is for the unlikely case that a db migration (which happens before canary) impacts everything. -
Release tracking #1394 - this is currently triggered in release tools so it will make sense to remove the trigger
This should help us identify dependencies on other systems and make an informed (and documented) decisions on each of those tasks.
Issue template
<!-- Title: Move TASK_NAME from deployer to release-tools -->
<!--
A brief overview of the task.
The text in https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/1395 is a good start
-->
## Responsibilities
This job is responsible for the following tasks:
* track X
* create Y
* trigger Z
## Dependencies
<!-- every interaction with other systems, including our own environments should be listed here -->
* ops.gitlab.net
<!-- * `release/tools` project -->
<!-- * `release/metadata` project -->
<!-- * GitLab.com -->
<!-- * sentry.GitLab.net -->
/label ~"release-tools single pipeline" ~AutoDeploy ~"team::Delivery"
/epic &361
An example can be seen at #1394
Edited by Amy Phillips