弊社事務所（と言っても私1人で使ってる）のソースコード管理はGitLabです。スペックがあるマシンでないと動かせないデメリットはありますが、GitHubに近い（それ以上の時も）機能が揃っていて、日々利用しているツールや趣味でとりあえず書いたコードなども全部こちらに入れています。
（最近はGitHubのプライベートブランチが無料になったので、そちらも使いつつですが）
日ごろから利用していたものの、忙しさにかまけてアップグレードをサボったばかりにちょっと大変だったのでメモがてら共有です
アップグレードをサボるとアップグレードしづらくなる
GitLabも毎年何度かマイナーなアップデートが入って、メジャーアップグレードもあります。特にメジャーアップグレードは依存関係のアップグレードも多くて、DB(Postgresql)のバージョンがメジャーバージョンになったりすると気をつけることが多いようです。
そんな時にどうすればいいかというと、アップグレードドキュメントをみて最適なアップグレード方法を知る必要があります。
まずはここを見ます -> Upgrading GitLab | GitLab
私の環境はOmnibus版と呼ばれる、Linuxサーバーなどにパッケージマネージャー経由でインストールするバージョンです。Omnibus版のアップグレードドキュメントはこちらです。
Upgrade GitLab by using the GitLab package | GitLab
そしてここからが大事ですが、例えば v12 のシステムを v14 へ一度にアップグレードはできないです。なのでアップグレードパスを見ながら、指定されたバージョンごとにアップグレードを繰り返します。
2022-05-19現在のアップグレードパスのバージョン順番はこうなっているようです。
8.11.Z -> 8.12.0 -> 8.17.7 -> 9.5.10 -> 10.8.7 -> 11.11.8 -> 12.0.12 -> 12.1.17 -> 12.10.14 -> 13.0.14 -> 13.1.11 -> 13.8.8 -> 13.12.15 -> 14.0.12 -> 14.9.0 -> latest 14.Y.Z
Ubuntu/debianで使われてるaptでは以下のようにバージョン指定をしてアップグレードを続けていきます
$ sudo apt update
# v12の中途半端なバージョンからからv13へアップグレードをする
# v12からv12の最終バージョン？までアップグレード
$ sudo apt install --upgrade gitlab-ce=12.10.14-ce.0
$ sudo apt install --upgrade gitlab-ce=13.0.14-ce.0
アップグレードのステップはすぐに踏まないで一旦待つこと
この記事で一番大事な話です。アップグレードパスをその通りに進めるのは合っているものの、アップグレードが終わったタイミングでまた次のアップグレードを行うと起動不可能になることがあります。
これは、アップグレード後にDBのマイグレーション処理がバックグラウンドで走っている状態で、マイグレーション処理が終わる前にアップグレードを行うとDBのテーブルの不整合が起きてしまうようです。（そういうふうに見えていたので実際は何が起こってるかはちゃんと調査しきれてないです。）
起動ができなくなると手動でDB回りを直すのは難しそうで、結局バックアップを復元（スナップショットを戻すなど）する必要があるので注意です。そのためバックアップも非常に大事。
マイグレーション処理は、[ホストのアドレス]/admin/background_migrate のアドレスから確認できます。このページを見てタスクがなければ、バックアップ（スナップショット）を取った後にアップデートをすれば安全です。
まとめ
まとめというか言いたいことはこちらでした。とくにドキュメントはちゃんと見た方がいいです。当たり前ですが未来の自分のために書いておきます。
- 日頃からアップデートは大事: 面倒な手順を増やさないようにできる
- バックアップは必ず行う（アップデート時もスナップショットをとりながら進めるとロールバックがとても楽）
- アップデートはドキュメントを見る: メジャーバージョンアップの時の注意点はしっかり見ること