LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

数年前に入れたGitLabを、気づけば一度も上げていない。新しい版にしたいが、どこから手を付ければよいのか分からない——。GitLabを自社のサーバーに置いて使っている会社では、こうした状態になりがちです。GitLabのバージョンアップとは、動いているGitLabを新しい版に入れ替える作業で、版の番号を飛ばさずに決められた順に上げていく点に特徴があります。

新しい版には機能の追加だけでなくセキュリティの修正も含まれるため、上げずに放っておくと弱点が残ります。ただし近道はなく、古い版から一気に最新へ飛ぶことはできません。本記事では、GitLabを自社で運用する情報システムの担当者に向けて、版の種類と上げる頻度、段階を踏む順番、バージョンアップの5つのステップ、そして外部に頼むときに確認したい点を整理します。

GitLabのバージョンアップとは

GitLabの版の番号は「18.3.2」のように3つの数字で表し、左からメジャー、マイナー、パッチと呼びます。^*1 どの数字が上がるかで中身と出る頻度が違い、バージョンアップの手間も変わります。まずは3つの違いを押さえておくと、どの版上げにどれだけ準備が要るかの見当がつきます。

使い方が変わる変更はメジャー版にまとめられるため、メジャー版をまたぐときは特に念入りな計画が要ります。^*1 ここで扱うのは、自社のサーバーに置いて動かしているGitLabの版上げです。GitLabを新しく入れるときの考え方やGiteaとの比べ方は、GitLab/Gitea セルフホストGit基盤の外注構築で扱っています。

どのくらいの頻度で上げるか

GitLabは、最新の安定版を使うことを勧めています。上げる頻度を決める手がかりになるのが、修正がどの版まで届くかという保守の方針です。公式の方針は次のとおりです。^*1

• 不具合の修正は、いちばん新しい安定版にだけ入ります
• セキュリティの修正は、最新版に加えて直前の2つのマイナー版にも入ります
• それより古い版は、原則としてセキュリティの修正を受けられません

マイナー版は毎月出るので、上げずにいると数か月で修正の届く範囲から外れます。パッチ版は出るたびに当て、マイナー版も遅くとも3か月に1度は上げる、という周期を決めておくと、保守の範囲から外れずに済みます。もう一つの理由が止める時間です。複数のマイナー版をまとめて上げるときは、GitLabを止めて作業しなければなりません。^*4 小まめに上げるほうが、1回あたりの作業も止める時間も小さくなります。

段階を踏む順番（アップグレードパス）

古い版から最新版へは、一度に飛べません。途中に「飛ばせない版」が決められていて、そこを順に通る道筋をアップグレードパスと呼びます。公式の決まりは次のとおりです。^*2

• GitLab 17.5以降、立ち寄る版はマイナー版の番号が2・5・8・11の版です
• 立ち寄る版では、その版の最初のパッチ版ではなく最新のパッチ版まで上げます
• 1つ上げたら、裏で続くデータの移し替え（バックグラウンド移行）が終わるのを待ってから次へ進みます
• 版ごとの注意点は公式のアップグレードノートにあるので、通る版の分を上げる前に読みます

たとえば18.3から18.11まで上げるなら、18.5と18.8に立ち寄り、それぞれ移行の完了を待ってから18.11へ進みます。立ち寄る版の数だけ作業の回数が増えるため、長く上げずにいた会社ほど作業が重くなります。どの版に立ち寄るかは、GitLabのサポートチームが公開している計算ツールでも確かめられます。^*2

バージョンアップの5つのステップ

公式の手順は、作業そのものよりも上げる前の準備に多くの紙幅を割いています。^*3 準備から上げた後の確認までを5つに分けると、次の流れになります。

• ステップ1：今の版と上げ先を確かめ、立ち寄る版とアップグレードノートを洗い出す。サーバーのOSが上げ先の版に対応しているかも見ます
• ステップ2：設定とデータベースの状態を点検する。データベースの問題は直すのに時間がかかることがあるので、早めに行います
• ステップ3：手順と戻し方を書いた計画を作り、本番を複製した環境で試す
• ステップ4：CI/CD（ビルドやテストを自動で回す仕組み）のジョブを止めてから、立ち寄る版を1つずつ上げる
• ステップ5：サインイン、リポジトリの取得と送信、Runner（ジョブを実行する仕組み）がジョブを受け取るかを確かめる

つまずきやすいのはステップ3の戻し方です。バックアップから戻すときは、バックアップを取った版と戻す先の版が同じでなければなりません。また、バックアップには暗号の鍵と設定ファイルも含める必要があります。^*3 本番の複製で一度通しておけば、時間のかかる移行がどのくらい続くかも前もって測れるので、止める時間を利用部門に伝えやすくなります。

外部に頼むときに確認しておきたい点

GitLabのバージョンアップを外部に頼むときは、作業の当日だけでなく、前後の準備と確認まで含めて範囲を決めておくと進めやすくなります。見積もりの前に、次の点を確かめておきます。

• どこまで頼むか：アップグレードパスの洗い出し、検証環境での試し、本番の作業、上げた後の確認のうち、どれを任せるか
• 止める時間：作業の時間帯と、開発部門やCI/CDの利用者への知らせ方
• 戻し方：バックアップの取り方と、戻す手順を本番の前に試すかどうか
• 周りの部品：リポジトリを保存するGitalyを別のサーバーに置いている場合や、検索にElasticsearchを使っている場合、その版上げも含めるか^*3
• 次回以降：毎月のパッチ版と、数か月ごとのマイナー版を、だれがいつ上げるか

特に次回以降の担当は、決めないまま終わりやすい点です。一度大きく上げても、その後に止まれば数か月で同じ状態に戻ります。ビルドやテストの自動化までまとめて見直したい場合は、CI/CD構築支援を外注するメリットと進め方も参考になります。

まとめ：GitLabのバージョンアップで確かめておきたい3つの点

GitLabのバージョンアップを進めるうえで、確かめておきたい点は3つに整理できます。第一に、セキュリティの修正が届くのは最新版と直前2つのマイナー版だけなので、数か月ごとに上げる周期と担当を決めること。第二に、古い版からは立ち寄る版を順に通り、各段で裏の移行が終わるのを待つこと。第三に、本番の複製で手順と戻し方を試してから本番に臨むことです。この3点を踏まえておけば、「上げようとしたら途中で止まり、元にも戻せない」という事態を避けやすくなります。版上げの計画や作業に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：GitLab Docs「GitLab release and maintenance policy」（https://docs.gitlab.com/policy/maintenance/）。出典：版の番号の付け方（メジャー・マイナー・パッチ）、それぞれの公開の周期、不具合とセキュリティの修正を入れる版の範囲、最新の安定版を勧める記述を参照（2026年11月確認）
2. *2　参考：GitLab Docs「Upgrade paths」（https://docs.gitlab.com/update/upgrade_paths/）。出典：立ち寄る版（required upgrade stops）が x.2・x.5・x.8・x.11 であること、最新のパッチ版まで上げること、バックグラウンド移行の完了を待つこと、アップグレードノート、計算ツール（Upgrade Path tool）の記述を参照（2026年11月確認）
3. *3　参考：GitLab Docs「Create a GitLab upgrade plan」（https://docs.gitlab.com/update/plan_your_upgrade/）。出典：上げる前の情報収集と点検、本番の複製での試験、バックアップと戻し方（版の一致・暗号の鍵と設定ファイル）、CI/CDの一時停止、上げた後の確認項目、Gitaly・Elasticsearchの扱い、失敗時の対応の記述を参照（2026年11月確認）
4. *4　参考：GitLab Docs「Consider upgrade downtime options」（https://docs.gitlab.com/update/downtime_options/）。出典：1台構成では止めて上げること、複数のマイナー版をまたぐときは止めて上げることの記述を参照（2026年11月確認）
5. *5　参考：GitLab Docs「Upgrade a multi-node instance with zero downtime」（https://docs.gitlab.com/update/zero_downtime/）。出典：止めずに上げるには負荷分散などを備えた複数台の構成が要ること、マイナー版を1つずつ上げることの記述を参照（2026年11月確認）

Tweet