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:
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.
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.
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.
Are you using mysql or postgres?
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.
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
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:
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
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.