部署后迁移

部署后迁移是常规的 Rails 迁移，可以选择在部署后执行。默认情况下，这些迁移会与其他迁移一起执行，但这需要停机时间。要跳过这些迁移，您必须在运行 rake db:migrate 时将环境变量 SKIP_POST_DEPLOYMENT_MIGRATIONS 设置为非空值。

例如，这将运行所有迁移，包括任何部署后迁移：

bundle exec rake db:migrate

但是，这会跳过部署后迁移：

export SKIP_POST_DEPLOYMENT_MIGRATIONS=true
bundle exec rake db:migrate

对于 GitLab.com，这些迁移由发布经理自行决定，通过 部署后迁移流水线 每日执行。

部署集成

假设您使用 Chef 部署新版本的 GitLab，并希望在部署新版本后运行部署后迁移。通常您会使用 chef-client 命令来完成此操作。要使用此功能，您必须按以下方式运行此命令：

export SKIP_POST_DEPLOYMENT_MIGRATIONS=true
sudo chef-client

一旦所有服务器都已更新，您可以在单个服务器上再次运行 chef-client，但 不设置 环境变量。

对于其他部署技术，过程类似：首先您会设置环境变量进行部署，然后重新部署单个服务器，但 不设置 该变量。

创建迁移

要创建部署后迁移，您可以使用以下 Rails 生成器：

bundle exec rails g post_deployment_migration migration_name_here

这会在 db/post_migrate 中生成迁移文件。这些迁移的行为与常规 Rails 迁移完全相同。

使用场景

部署后迁移可用于执行会改变现有 GitLab 版本所依赖状态的迁移。例如，假设您想从表中删除一列。这需要停机时间，因为 GitLab 实例在运行时依赖于该列的存在。通常在这种情况下，您会遵循以下步骤：

1. 停止 GitLab 实例
2. 运行删除该列的迁移
3. 再次启动 GitLab 实例

使用部署后迁移，我们可以遵循以下步骤：

1. 部署新版本的 GitLab，同时忽略部署后迁移
2. 重新运行 rake db:migrate，但不设置环境变量

在这里，我们不需要任何停机时间，因为迁移是在部署新版本（不再依赖该列）之后进行的。

这些迁移有用的其他示例：

• 清理由于 GitLab 中的错误生成的数据
• 删除表
• 将作业从一个 Sidekiq 队列迁移到另一个队列