stage | group | info |
---|---|---|
Data Stores |
Database |
Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review. |
Post deployment migrations are regular Rails migrations that can optionally be
executed after a deployment. By default these migrations are executed alongside
the other migrations. To skip these migrations you must set the
environment variable SKIP_POST_DEPLOYMENT_MIGRATIONS
to a non-empty value
when running rake db:migrate
.
For example, this would run all migrations including any post deployment migrations:
bundle exec rake db:migrate
This however skips post deployment migrations:
SKIP_POST_DEPLOYMENT_MIGRATIONS=true bundle exec rake db:migrate
For GitLab.com, these migrations are executed on a daily basis at the discretion of release managers through the post-deploy migration pipeline.
Say you're using Chef for deploying new versions of GitLab and you'd like to run
post deployment migrations after deploying a new version. Let's assume you
usually use the command chef-client
to do so. To make use of this feature
you'd have to run this command as follows:
SKIP_POST_DEPLOYMENT_MIGRATIONS=true sudo chef-client
Once all servers have been updated you can run chef-client
again on a single
server without the environment variable.
The process is similar for other deployment techniques: first you would deploy with the environment variable set, then you re-deploy a single server but with the variable unset.
To create a post deployment migration you can use the following Rails generator:
bundle exec rails g post_deployment_migration migration_name_here
This generates the migration file in db/post_migrate
. These migrations
behave exactly like regular Rails migrations.
Post deployment migrations can be used to perform migrations that mutate state that an existing version of GitLab depends on. For example, say you want to remove a column from a table. This requires downtime as a GitLab instance depends on this column being present while it's running. Usually you'd follow these steps in such a case:
Using post deployment migrations we can instead follow these steps:
rake db:migrate
but without the environment variable setHere we don't need any downtime as the migration takes place after a new version (which doesn't depend on the column anymore) has been deployed.
Some other examples where these migrations are useful:
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。