I'm on Gitlab 5 with a bunch of projects. How do I update and avoid catastrophe?

Question:
What’s a realistic upgrade path for us? Any suggestions are welcome as long as they keep our data intact.

Background:
Our company has Gitlab 5 set up via a Turnkey Linux (version 13 of this VM). It’s now a fairly integral part of our company and has about 40 projects on it.

There are tons of updates and features in the new versions that I’m practically drooling for. However, updating manually from version 5 to a recent version seems nearly impossible, and I can’t find any way of exporting/importing the data between versions.

I personally haven’t done an upgrade from that far back, or have any experience with turnkey linux. So take my advice with a grain of salt. But the steps I would attempt would be:

  1. Clone your VM, and boot up the clone to attempt a trial migration. You need to gain confidence in the upgrade plan before you do this on your production.
  2. Do the migration to 5.1 : https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/update/5.0-to-5.1.md
    Confirm the migration worked before moving on.
  3. Do the migration to 6.0 : https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/update/5.1-to-6.0.md
    Confirm the migration worked before moving on
  4. Do the migration to 7.14 : https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/update/6.x-or-7.x-to-7.14.md
    Confirm the migration

You are basically up to date, time to switch to a more sustainable solution for upgades in the future:
Switch to using the gitlab omnibus packages: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/update/README.md#upgrading-from-non-omnibus-postgresql-to-an-omnibus-installation-using-a-backup

Basically you are going to want to take a backup of your non-omnibus 7.14 repo, boot up a new clean VM without gitlab on ubuntu/centos/debian that will become your new production gitlab instance. Install 7.14 omnibus from the gitlab package presitory. And restore your backup. This will make future upgrades tons easier.

1 Like

I was about to write some steps but @twk3 got this right.

With some steps and testing I believe it’s pretty doable to migrate to latest version. There are a few questions that need to be answered first.

  1. Are you using mysql or postgres?
  2. Will you upgrade to omnibus packages (recommended) or stay with source installation?

I’m not familiar with turnkeylinux, but I guess it is like bitnami, source installation with custom startup scripts, etc.

Needless to say, always keep a backup before any upgrade. Then fire up a cloned VM of your current production setup and follow the steps @twk3 mentioned.

The big plan would be to migrate to a minimum version that supports omnibus packages (see the archives page at the very bottom), then upgrade to a version where the repositories were introduced and finally update to latest version using apt/yum.

The key is to reach to a version that is supported by omnibus packages. From there on you just donwload the package and use dpkg/rpm to install and eventually you use the repository.

@twk3 and @axil, thank you very much. That’s very helpful.

@axil, we’re currently using mysql. I’d very much like to upgrade to the Omnibus packages, they seem much easier to manage.

I successfully upgraded from 5.4 to 8 stable yesterday.

Gitlab 5 was installed on CentOS from source and we use MySQL hosted on another server.

I just followed the guides in order:

  1. 5.4-to-6.0.md

  2. 6.x-or-7.x-to-7.14.md

  3. 7.14 to 8.0 update guide

You don’t need to convert to Postgres to use 8.

It was a little confusing finding the right docs because there’s a real big push to use the Omnibus edition.

Care to elaborate on that? What would you like to see? I’m in the process of writing some docs for upgrading from old source installations to newer omnibus packages.

It’s true that the omnibus is prefered, mostly due to the fact that this is used on production for gitlab.com and thus tested more than the source installations.

And yes you can always use an external db, be it mysql or postgres :wink:

The quality of the upgrade guides are excellent. There were a few issues, but the entire process wasn’t as bad as I had thought it would be.

Care to elaborate on that? What would you like to see? I’m in the process of writing some docs for upgrading from old source installations to newer omnibus packages.

The guide for upgrading to 8.0 isn’t in the update directory:
https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/update

Would’ve saved me a lot of googling if the guide was included there.

And yes you can always use an external db, be it mysql or postgres :wink:

My DB confusion concerning the omnibus was from reading this page about it being only for EE. Good to hear that I misunderstood the document:
Using a MySQL database management server (Enterprise Edition only)

1 Like

Hmm, actually I was wrong. Using mysql depends on the ruby mysql2 adapter which is not installed in omnibus packages. You’d have to add it manually with a couple of hacks…

Thanks for the help guys. This actually solved itself. A colleague managed to break our Gitlab VM through some complicated server shenanigans, so we just bit the bullet, started a new server, and managed to get all our projects synced up from local copies. Took a bit of time but well worth it, Gitlab 8 is a massive improvement.

1 Like