[meddlepal]

Used GitLab maybe 5 years ago now? I was impressed with it despite its immaturity. These new features look great though.

I found the operation of on-prem GitLab to be a bit of a PITA back then, has that changed? There was a whole bunch of rake tasks and junk you needed to run to upgrade and it required a shutdown of the system.

[tyldum]

Mainly just apt-get these days. Occasionally something is deprecated in the config file, but the release notes are very clear. Never had an issue and our omnibus install has been chugging along since they introduced enterprise version back in the days.

[lbotos]

It's a lot easier, and dead simple to run a small single server install. When you start scaling, it gets a little harder, but our vision it to leverage K8s for that type of deployment.

(Source: work at GitLab, and I wouldn't If we had to manage the infra by hand vs. omnibus/k8s)

[meddlepal]

Any comment on how well the single server install scales before needing to invest in the more complex HA solution?

[lbotos]

Sure! This depends on your orgs "capacity for risk." We don't recommend more than ~300 on a single node just for the developer area. If you have 300 people relying on a literal SPOF (especially a dev shop) that's gonna hurt if there are any problems. That said, I'm aware of customers running a single 132GB node that serves somewhere between 3000-5000 devs. (Please do not go this far)

I'd say at the 150 or so developer mark, we should start talking about scaling (adding a second Geo node for failover at a minimum) or if you need more robust uptime requirements, going towards a more active-active distributed cluster. I use the word "distributed" and not "highly available" as we like to find the right fit for each org. Some orgs need true HA, and it takes something close to ~30 servers to do it. Others, just can benefit from some web frontends, and separating out the DB layer, and potentially traffic shaping to separate CI load / User load.

[jmarneweck]

When I first used Gitlab on SmartOS it was a pain to upgrade manually.

I more recently used Gitlab on Ubuntu using their omnibus package for Ubuntu and the upgraded over multiple versions to get onto a later version of Gitlab. The upgrade process was a lot smoother (no fighting to build gems on SmartOS and patching all over the show to get gems and other dependencies to compile).

I also did a MySQL to Postgresql migration. You have a bit of downtime with the process which chef sorts things out post upgrade of the omnibus package. I did turn the unicorns and disabled ssh logins while I was upgrading the omnibus package just incase something went wrong during the upgrade.

[cevn]

Upgrade is usually as simple as an apt update && apt upgrade for me. Every once in a while they change tables in a non backwards compatible way and you have to force allow it or something. It's all very easy though.

[codereflection]

Upgrading is super easy these days when you go with their omnibus installer. That handles all of the upgrade tasks for you, even skipping over versions which was not really possible with the source install days of old.

[unilynx]

It's on docker, gitlab/gitlab-ce:latest

We're upgrading two or three times a month, and I don't remember having had any issue just letting it update itself for at least a year.

Gitlab's downtime when upgrading the docker image is about 1 - 3 minutes every time, which hasn't been an issue for us (and otherwise I'd just schedule it for midnight)

[BossingAround]

Well, I was able to deploy it on my home "server" within like half an hour. Migration when having hundreds of repos might be a bit more difficult, not sure about that of course.