Database migrations should be tested against versions in which they could be running
## Short description
We have 3 different scenarios for executing database migrations.
1. As we merge them, on gitlab.com
2. Self managed zero downtime, where they execute regular migrations before upgrade, and post migrations after upgrade
3. Self managed with downtime, where migrations are executed regular, post, regular, post, in version order while the application isn't running
Currently we do a decent job testing scenario 1, where we run those migrations against a copy of the gitlab.com production database. Scenarios 2 and 3... not so much. We should fix that.
## Business Justification
Both we and our customers operate clusters that follow 2 and 3, so it's in our best interest to make sure that things are thoroughly tested before releasing them. We've had customers experience substantial issues due to this lack, and that can lead to churn and other issues.
## Expected impact
It's expected we'd see a reduction in upgrade issues reported to support, and an increased adoption of zero downtime upgrade practices.
## Exit criteria
- [ ] We have testing that in merge requests that executes newly introduced regular migrations against the previous version
- [ ] We have testing in merge requests that executes specs against code without the current post-deployment migrations executed
- [ ] We have fixtures for all tables related to new migrations
- [ ] We have a plan to ensure that all tables have fixture data
## Deliverables
<!--
How are we going to get from current state to the exit criteria? What high level
milestones can we define, and what distinct steps could those milestones have.
Ideally, we'd align these to actual product milestones, but it's okay if we don't.
-->
- [ ] Phase 0 (Milestone) - ~"workflow::planning breakdown"
- [ ] Epic is broken down into future phases
- [ ] Issues are created for as many phases as possible and weighted
- [ ] Project is ~"workflow::ready for development"
- [ ] Phase 1 (Milestone) - Brief description of what happens
- [ ] ...
<!-- DO NOT EDIT BELOW - Used for the epic status automation bot -->
<!-- STATUS NOTE START -->
<!-- STATUS NOTE END -->
epic