gitlab-rake db:migrate: Separate rake tasks for pre-deployment and post-deployment migrations

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Proposal

Currently post-deployment migrations are executed separately by setting and environment variable:

SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-rake db:migrate

Working with a customer to test zero downtime upgrades, the upgrade failed. We found that the environment variable wasn't being set correctly, even though testing and logging within the process suggested it was.

Having separate rakes task like db:migrate:pre_deployment and db:migrate:post_deployment what will only run the specified migrations would be a more robust way to construct automation for upgrades.

It would also be much easier to test: once an environment is upgraded, there's no easy way to test a bug fix in the automation, since there's no migrations to run.

With new dedicated tasks, if they run and generate some of their default output, administrators supporting GitLab can be more certain that the problem is fixed.

I don't propose removing the existing mechanism, since setting the variable and using the existing rake task is how GET and bespoke customer automation currently handles upgrades. So, hopefully it's possible to support both approaches and be reasonably DRY.