Gitlab 升級時會需要在特定版本停留，跑完 migrations。如果版本跳很大就會讓升級過程變得很冗長，要怎麼加速呢～
最近要將自架的 Gitlab 從 12.5.5 一口氣升上 16.1.1，同時希望將升級時間壓在半天內。有用過 Gitlab 的朋友應該知道，Gitlab 升級時會需要在指定版本停留，等系統跑完 migration 後才能往下一個停留點，如此往覆。那我們要怎麼加速呢？
如果想要直接看流程，請跳到「實作方法」
目錄：
到底 Gitlab 的 migration 具體有什麼呢？
如何加速呢？
實作方法
到底 Gitlab 的 migration 具體有什麼呢？
在 V14 以前，只有 background migration，從 V14 開始多了一個 batched background migration，以下簡稱一般版跟 batch 版。
如何加速呢？
一般版使用 sidekiq 執行，大部分 jobs 可以在 UI 透過點擊「Add to Queue」馬上執行，其他的都會在一分鐘內執行完畢。
batched 版本的是 gitlab 自己維護的 async job processor，通常 Job 都是一個個且非常低的速率運作。14.1 版加入了可以手動執行 batch 版的 rake job，用這個方式可以立即執行 batch background migration。（點我看文件）
不過因為 14.0 就開始有 batch 版了，因此為了讓 14.0 的 batch 版也可以強制執行，我們會在 14.0 的一般版完成後直接升級到 V14.1.3，batch 版會記錄在 postgres 內，不用擔心進度丟失。到 V14.1.3 時把所有 background migration 跑完。只要不要跑到下一個停留版本（14.3 以後）就不會讓 Batch 版失敗（14.2 開始才有 background migration 的成功與否偵測）
經過實驗，原本需要半小時才能夠繼續升級的 14.0 版，透過這個方法可以壓縮到 5 分鐘內完成
實作方法
廢話不多說，先放指令
$ bin/bundle exec rails c -e production
# 進入 Rails console 後直接貼上以下指令
Gitlab::Database::BackgroundMigration::BatchedMigration.queued.each do |migration|
puts "RAILS_ENV=production bin/bundle exec rake gitlab:background_migrations:finalize[#{migration.job_class_name},#{migration.table_name},#{migration.column_name},'#{migration.job_arguments.to_s.gsub(',', '\,')}']"
end;1上述指令會把還沒完成的 Job 製作成一條條可以執行 rake tasks。退出 Rails console 後，把系統產出的結果貼到 terminal 內，並讓系統跑完，出現 Done. 就代表完成了