Remove old database migrations
We're coming up to the %12.0 release for GitLab; this gives us an opportunity to safely remove all migrations in the following directories that were (being ultra-paranoid) added before the %11.0 release.
Going from the v11.0.6-ee tag, it seems we could remove:
-
db/migrate
- 807 migrations -
db/post_migrate
- 144 migrations -
ee/db/migrate
- 220 migrations -
ee/db/post_migrate
- 14 migrations
There's also some code in lib/gitlab/background_migration
, and elsewhere, that is solely used by these old migrations. This could also be removed.
The basis for this safely is our upgrade guides - we only provide for seamless upgrades within a major version: https://docs.gitlab.com/omnibus/update/README.html#mandatory-upgrade-paths-for-version-upgrades
If people want to go from, e.g., 10.0 to 12.0, they must follow this path:
10.0.0 ->
10.8.7 ->
11.0.0 ->
11.11.x ->
12.0.0
In this way, removing the migrations doesn't affect the ability of our users to upgrade.
Rails notes that we can do this: https://edgeguides.rubyonrails.org/active_record_migrations.html#old-migrations
Some StackOverflow threads about the topic, with a variety of pros and cons:
- https://stackoverflow.com/questions/4248682/is-it-a-good-idea-to-purge-old-rails-migration-files
- https://stackoverflow.com/questions/20119391/delete-old-migrations-files-in-a-rails-app
The benefits at GitLab are mostly around doing away with technical debt - having these files sat around on their own terms means we need to maintain them, and the code they depend on.
One example is in this MR: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/25598 - gitlab-shell/bin/gitlab-keys
code has been kept around since 2017, solely to enable a background migration that everyone has already run. This played a part in the issue missing the %11.9 release window.
Another example is our introduction of the FactoriesInMigrationSpecs
cop: https://gitlab.com/gitlab-org/gitlab-ce/issues/44990 - we have a number of background migration specs that use factories, and it often leads us to introduce nasty workarounds into production code. Deleting these files outright means that we don't need to put engineering effort into bringing them up to standard.
I'll assign this to the %12.0 milestone, since I really think we should do it. If we decide not to, we can just close the issue before then!
cc @gitlab-org/maintainers/rails-backend @dblessing (for a perspective from self-managed support)