デプロイ後の移行
デプロイ後のマイグレーションは、デプロイ後に任意で実行できる通常の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インスタンスが実行されている間、このカラムが存在することに依存しているため、ダウンタイムが必要になります。 通常、このような場合は以下のステップに従います：
- GitLab インスタンスを停止します。
- カラムを削除してマイグレーションを実行
- GitLabインスタンスを再度起動します。
デプロイ後のマイグレーションを使用すると、代わりに次の手順を実行できます：
- デプロイ後のマイグレーションを無視して新しいバージョンのGitLabをデプロイします。
-
rake db:migrateを再実行しますが、環境変数は設定しません。
ここでは、新しいバージョン（カラムに依存しなくなった）がデプロイされた_後に_移行が行われるため、ダウンタイムは必要ありません。
このような移行が役立つ他の例もあります：
- GitLabのバグにより生成されたデータのクリーンアップ
- テーブルの削除
- Sidekiqキューから別のキューへのジョブの移行
