Require merge requests that include migrations to specify a rollback procedure
In !15137 (merged) a background migration was added, and it was found this migration did not perform well due to the lack of an index. The migration did not offer a way of rolling back the changes, nor was there a rollback procedure defined in the merge request description. While sometimes rolling back is not possible (e.g. when removing data), we need to at least start requiring developers to:
- Think about how to roll back the data
- Add a rollback procedure for background migrations (this is already done for normal migrations)
- Describe this in the merge request, so a release manager or SRE doesn't have to go through the code to figure out how to revert something
Code wise I am thinking of the following changes:
- We require that background migrations define a
revert
method - We require that migrations that schedule a background migration define a
down
method. This method should remove any pending jobs itsup
method` scheduled, then schedule the reverting of migrations - BackgroundMigrationWorker#perform needs to take an optional argument that when set triggers a revert, instead of a normal migration
- We write a RuboCop rule that enforces all this (e.g. by requiring a non-empty
revert
method in background migration classes)