デプロイ後の移行

デプロイ後のマイグレーションは、デプロイ後に任意で実行できる通常のRailsマイグレーションです。 デフォルトでは、これらのマイグレーションは他のマイグレーションと一緒に実行されます。これらのマイグレーションをスキップするには、rake db:migrateを実行するときに環境変数SKIP_POST_DEPLOYMENT_MIGRATIONS を空でない値に設定する必要があります。

たとえば、これはデプロイ後のマイグレーションを含むすべてのマイグレーションを実行します:

bundle exec rake db:migrate

しかし、これはデプロイ後のマイグレーションをスキップします:

SKIP_POST_DEPLOYMENT_MIGRATIONS=true bundle exec rake db:migrate

デプロイメント・インテグレーション

GitLabの新バージョンのデプロイにChefを使っていて、新バージョンのデプロイ後にデプロイ後のマイグレーションを実行したいとします。 通常はchef-client 。この機能を使うには、次のようにコマンドを実行する必要があります:

SKIP_POST_DEPLOYMENT_MIGRATIONS=true sudo chef-client

すべてのサーバーが更新されたら、環境変数_なしで_1台のサーバーでchef-client

このプロセスは、他のデプロイ手法でも同様です。まず環境変数が設定された状態でデプロイし、次に、基本的に1台のサーバーを再デプロイしますが、変数は_未設定に_します。

マイグレーションの作成

デプロイ後のマイグレーションを作成するには、以下の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キューから別のキューへのジョブの移行