Upgrade GitLab enterprise from 16.5.1 to 16.7.3

How to Use GitLab Upgrade
1

Hello,

I currently have a production GitLab server operating on version 16.5.1 and aim to upgrade it to the latest security patch, 16.7.3. The server details are as follows:

  • Server: CentOS 7.9
  • SQL: PostgreSQL 13.11
  • GitLab: 16.5.1
  • GitLab runner: 16.5.0

As I proceed with the upgrade, I have encountered the following uncertainties:

  1. Prior to upgrading the GitLab server, is it necessary to upgrade PostgreSQL to version 14, or will the current version 13.11 supports?

  2. Should I upgrade my GitLab runner to version 16.7.0 before proceeding with the GitLab upgrade?

  3. Could someone clarify if the upgrade path should follow the sequence 16.5.1 => 16.5.7 => 16.6.5 => 16.7.3? Is this correct?

  4. Before initiating the aforementioned steps, I plan to take a backup of GitLab and the database using the command gitlab-backup create. Is there any other recommended backup plan in case a rollback becomes necessary?

I would greatly appreciate any guidance on the above queries.

Thank you,
Shiva.

2

Hi,

  1. You do not need to upgrade PostgreSQL manually if you are using the bundled PostgreSQL that comes with gitlab-ce or gitlab-ee. Gitlab will upgrade it itself if it needs doing. If you are using an external PostgreSQL database, then you will need to check the Gitlab Upgrade documentation for more information relating to that: Upgrade GitLab | GitLab

  2. I don’t believe it matters, I generally upgrade both of mine at the same time.

  3. The upgrade path can be checked here in the docs: Upgrade GitLab | GitLab but there is also a link here to use the Upgrade Path tool, of which I link here: Upgrade Path

Both in fact confirm, that from 16.5.1 you can upgrade directly to 16.7.3 (no need to upgrade to 16.5.7 first).

  1. Backing up is important, so yes, it is good to use the gitlab-backup create command. That creates a backup in /var/opt/gitlab/backups. If your server is a VM, then it is probably also easier and quicker to use snapshot functionality, as this can be easily reverted if something goes wrong. A restore of a backup will take longer, depending on how large the backup is. This is also not including potentially reinstalling your server from scratch, configuring with Gitlab before the restore can be done. That said, please don’t rely on snapshots on their own. So it’s good to have both types of backups.

Please also note, if you do take VM snapshots, once the upgrade has finished successfully and you have verified that all is working OK, to then delete the snapshot. The reason for this is it has a huge impact on VM performance.

Hope that helps!

2 Likes
3

Hi Iwalker,

Thank you for sharing the information in detail.

In addition to this, do you have any idea how to roll back the upgrade in case if it fails? If yes, please could you shed some light on it?

Thanks,
Shiva

4

Hi, no I’ve never rolled back a failed upgrade. I always ensure I have a backup before upgrading. Then if it fails, I much prefer to reinstall the version of Gitlab before the upgrade and restore the data.

People have done rollbacks, but I don’t know what kind of problems can occur later in the future. That’s why I prefer to not attempt rollbacks.

Also, if you have Gitlab installed on a VM, it’s just as easy to make a snapshot of the VM before the upgrade. If it fails, just revert the snapshot. Much quicker than restoring a backup or even rolling back a failed upgrade.

2 Likes