back

by rcarmo·10y ago·view on hn ↗
I chose Gitlab for my former company over GitHub Enterprise because we wanted an on-prem solution, and it worked well enough for ~200 folk. We did have to tweak (and occasionally break) a few things, since quite a few people suffered from NIH syndrome and wanted things done "the right way".

In general, I liked it, but it always irked me that its Ruby underpinnings made it hard to upgrade/migrate stuff (we basically just swapped LXC containers at one point, not sure how it was handled during the last upgrade). If anyone ever manages to do a credible alternative that does _not_ use Ruby in any way but keeps the overall GitHub-like workflow, a lot of operations folks will switch _instantly_.

(Like https://try.gogs.io/explore, for instance)

Also, like some commenters already pointed out, the CE edition was ridiculously limited in some regards - we mostly skipped the bits we didn't like and did product-level ticketing outside it (using Trac), with Gitlab issues used only for "techie" stuff, tracking fixes, etc.

But today I'd probably just sign us all up for GitHub and be done with it, or fire up a VM image from some marketplace - there's hardly any point in maintaining our own infrastructure or doing a lot of customization.

4 comments
Nowadays, the omnibus package makes gitlab pretty easy to maintain.

I had to do an upgrade from Gitlab 6.9 (source-based on ubuntu 12.04) to 8.3 (omnibus rpm on rhel7, managed via puppet) recently, and it was surprisingly smooth.

The package-based installer bundles all the needed software, which is quite okay for software like gitlab that often depends on specific versions of auxiliary software. It uses a built-in chef to configure its components.

I performed the upgrade in two steps, first to 7.14 (on the source-based install), then did a backup/restore to the new server with omnibus and upgraded it to 8.3.3 with yum.

Gitlab migrated the database mostly correctly (there were some issues with the LDAP provider; some users had the wrong provider in the database, but that was easy to fix manually. I'm not sure what caused it) which was quite a surprise considering I went up 2 major versions in two steps. Even upgrading the source-based installation went very smoothly even though it had to download a couple dozen ruby gems from the internet.

The upgrade also affected CI functionality for one of our users but I think that was because it relied on pre 8.0 non-builtin CI, and simply needed reconfiguration for the new system.

Afterwards, a point-release upgrade took a whopping 5 minutes (most of which was downloading and extracting the new RPM).

I'm sorry to hear you're not satisfied with GitLab and I would love to know more.

1. What things did you have to tweak?

2. Did you try our Omnibus packages for upgrades? It should be just apt-get upgrade https://twitter.com/J_Salamin/status/687884326629937152

3. What features of EE belong in CE in your opinion?

1. For starters (besides other internal stuff), we were the guys who needed Shibboleth support. You might recall there were a few pull requests from a colleague of mine regarding that :)

2. No, we had to tweak the source, so I don't think the packages were useful.

3. Static pages, hooks and merge approvals would be right at the top of my list. Audits would be nice to have, but we figured out how to do that on our own.

Also, issue handling needs some improvement. We just couldn't map our Trac workflow to it - but that's a fairly longer story, and it would probably be the same if we used GitHub.

Thanks for your reply and for contributing code.

1. Shibboleth is now supported in the Omnibus packages https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/inte...

2. Hopefully you can use the packages now that the Shibboleth code is merged.

3. GitLab Pages, git push hooks, merge request approvals and audit logs are available in EE.

Note that point 3 was an answer to the question

> What features of EE belong in CE in your opinion?

which means rcarmo knows they're in EE, but thinks they belong in CE.

OK, thanks.
I thought you could do on-prem with GitHub Enterprise?
GitHub Enterprise was essentially a closed VM that did not allow us to do the sort of customisation we needed - nor, most crucially, mount the git repos from our enterprise SAN.

Gitlab allowed us to do that without any hassle, even running inside an LXC container.

> But today I'd probably just sign us all up for GitHub and be done with it

Did you mean Gitlab?

Nope. GitHub. In that past context, it made more sense.