5 ms·

I really really want to like Gitlab, I love their openness and I love having the competition with Github. But it seems like every 6 months they have an issue of

I really really want to like Gitlab, I love their openness and I love having the competition with Github. But it seems like every 6 months they have an issue of some description. It's unfortunate the expectations we place on cloud providers but my clients have similar expectations from me so I need to work with providers that can assure me they can offer the kind of uptime I'm expected to provide. Plus the modern way of pipelining code means git is seldom a static silo like it once was which only compounds things when one of your links in the chain has multiple glitches a year. edit: I thought I would get downvoted into oblivion for this but I felt it was a discussion worth having since they relate directly to my experiences with working at scale. So I "took one for the team" - so to speak. Anyhow to answer a few points: * Yes I'm aware git is a distributed VCS but like I said, git is seldom a silo so you'd need to reconfigure your pipeline to point to the new git origin or have your pipeline already configured to accept fallback systems. Quickly your configuration spirals in complexity. * Yes I'm also aware you can self host. This is actually what we did do before moving to a cloud hosted solution. This added complications with our AWS pipelining. Problems that were solvable but again, with additional complexity compared with cloud hosted solutions. At the end of the day all problems can be addressed with enough time and resources however the reason people typically opt for hosted solutions is to reduce complexity not increase it.

amelius 9y ago
But git is a decentralized system/protocol, so in theory if Gitlab is down, you could very easily resort to using a different origin.
- omk 9y ago
  When you have CI/CD in place your central repo going down is a huge hassle.
  - Cthulhu_ 9y ago
    That's why you should make your CI / CD code-based, so you can recreate it from scratch within minutes. At worst you'd lose your previous build states.
    - trome 9y ago
      Might as well Ansiblize it :P
- laumars 9y ago
  In theory yes. But in practice it's not quite so straightforward. If you're working to tight deadlines then having to reconfigure your pipeline because of an outage is both scary and a huge pain in the arse. The reason people opt for cloud solutions is to decrease complexity, not increase it. So if I'm having to run multiple git origins then I would be better off self hosting and just moving those complexities in house.
  - jacquesm 9y ago
    That's exactly why you can run your own gitlab instance. The thing to do when you don't want dependencies is to reduce your dependencies, not complain about a third party service that offers their software for free so you can run it yourself.
    - laumars 9y ago
      > That's exactly why you can run your own gitlab instance. You're oversimplifying things there. It's not just about the physical instance - I could just run git "naked" without Gitlab's tooling if it were just an issue of installing Git. The complexities arise when you then need to have Git exposed to the internet to allow AWS pipelining to operate. We then have gateway into your internal network that needs to be PCI-compliant (for our retail sites), audited by the Gambling Commission (for our online games) and ISO nnnn (I forget what standard we meet off hand). It's fair that most organisations might not have these hoops to jump through, but we do and hence why we migrated to hosted providers to remove some of our complexity. > * The thing to do when you don't want dependencies is to reduce your dependencies, not complain about a third party service that offers their software for free so you can run it yourself.* I think this is grossly unfair. For starters I'm not complaining about Gitlab, I was opening a discussion about them. You might disagree with my points and I welcome your opinion - otherwise it would be a dull and pointless discussion. :) Secondly your point about "The thing to do when you don't want dependencies is to reduce your dependencies" is entirely the point I'm making. Perhaps you've missed some of the issues I've raised or perhaps I've explained myself badly. But I have explored a number of options and not just blindly talking out of my arse (which I appreciate there's no way for you to know this given the anonymous nature of the internet). Lastly why would I be only interested in free solutions given the expectations I have? Currently we do pay for our Git hosting because of our requirements - and my expectations include paying a fee for a service if it solves a few problems. After all we are talking about enterprise systems - any reasonable costs are consolidated and billed back to the client.
INTPenis 9y ago
I use gitlab for one thing, they allow private repos without paying. My needs are pretty basic though, no CI/CD. At some point I've even had multiple remotes in a repo, both on gitlab and github.
luckytobby 9y ago
Everything was back on track very quickly, no data loss. Github has had major service outages recently as well (just google it to refresh your mind). They'll both have a few issues in the future because nobody is perfect. Come on.
- laumars 9y ago
  > "because nobody is perfect. Come on." If only I could make the same counterargument when my clients complain about downtime. :) Sadly in the modern world people expect ridiculous uptimes and thus my expectations are just derived from my clients expectations. I don't like that much either but frankly clients often just get their expectations from their customers demands. These days people expect 24/7 uptime so my job is to facilitate that wherever I can.
  - mugsie 9y ago
    Sure - but is there any alternatives? Gitlab does have issues, but so do GitHub (and other providers). If your service is taken down by code hosting going away there is issues - unless you are running a code hosting service, or managed DevOps - in which case, the onus is on you to develop for failure (of any provider)
  - Xylakant 9y ago
    > If only I could make the same counterargument when my clients complain about downtime. :) If you can't make that argument, then you indeed have a problem. Downtimes happen, reducing them gets expensive fast. 95% is fairly simple, 99.999 is extremely hard - it requires redundancy on each and every level. Every time a client demands this, I reframe their request in terms of required engineering effort. Few, if any, actually care about the 9 behind the decimal point after that. The best clients had downtimes already integrated into their operating plans: What happens if we go down, partially or fully, what do we do, how do we communicate and - most importantly, how do we get back up as fast as possible again.
    - laumars 9y ago
trome 9y ago
Run your own Gitlab instance, it isn't very hard to do. The point is to use Git in a decentralized manner, not circle around one closed platform or another. The main Gitlab instance being under such heavy load is not too great either, more needless centralization...
ergo14 9y ago
Try RhodeCode, you will get both mercurial and git. Since I prefer Mercurial over git I don't have any other option than to run my own instance.
- chrisBob 9y ago
  Try bitbucket. We use it at work and it is a nice service that includes Mercurial support
  - zepolen 9y ago
    Never ever using Bitbucket again, worst experience ever. Gitlab for Git and Rhodecode for Mercurial are so much better.
  - ergo14 9y ago
    But you can't self host bitbucket with mercurial support? I thought only the online version supports hg?
    - JimDabell 9y ago
      I think he was responding to: > Since I prefer Mercurial over git I don't have any other option than to run my own instance. You do have another option – you can use Mercurial with Bitbucket. Sure, it's not self-hosted, but you were complaining that you were forced to self-host because you prefer Mercurial, right?
      - ergo14 9y ago
        I'm not compaining about self-hosting - in fact I prefer that.
mdekkers 9y ago
Really, HN? Parent might not be a _popular_ opinion, but the parent stated the opinion in a mature, non-inflammatory manner. Communities go downhill quickly when a certain "critical mass" of users get downvote rights, and downvoting becomes a poor proxy for intelligent discourse. It is deeply frustrating when a cool community such as HN increasingly stifles reasoned debate with the split second, zero cost decision of downvoting a comment you don´t agree with. Remove downvoting, or increase the cost of downvoting (as in, one downvote will cost you 5 karma points, or something like that) because the HN I grew to enjoy is quickly starting to look like just another subreddit. edit: typos
MildlySerious 9y ago
I think this is, at least in part, a perceived thing. GitLab's technical blog posts regularly hit the HN frontpage, while GitHub's issues just seemingly get swiped under the rug, unless it's major, or it's positive news of them introducing new features. Just earlier I got messages that 'info for the latest commits couldn't be loaded' on GH, whatever that means, but I don't see a blog post as to why on HN.
- laumars 9y ago
  I think you're right. I've been doing more reading on Gitlab and their competitors and it seems I'd forgotten about a few incidents with Github and Bitbucket. I guess it just goes to show that openness is a double edged sword. Though I'm still thankful that businesses like Gitlab do adopt such policies.

amelius 9y ago

But git is a decentralized system/protocol, so in theory if Gitlab is down, you could very easily resort to using a different origin.

omk 9y ago
When you have CI/CD in place your central repo going down is a huge hassle.
- Cthulhu_ 9y ago
  That's why you should make your CI / CD code-based, so you can recreate it from scratch within minutes. At worst you'd lose your previous build states.
  - trome 9y ago
    Might as well Ansiblize it :P
laumars 9y ago
In theory yes. But in practice it's not quite so straightforward. If you're working to tight deadlines then having to reconfigure your pipeline because of an outage is both scary and a huge pain in the arse. The reason people opt for cloud solutions is to decrease complexity, not increase it. So if I'm having to run multiple git origins then I would be better off self hosting and just moving those complexities in house.
- jacquesm 9y ago
  That's exactly why you can run your own gitlab instance. The thing to do when you don't want dependencies is to reduce your dependencies, not complain about a third party service that offers their software for free so you can run it yourself.
  - laumars 9y ago
    > That's exactly why you can run your own gitlab instance. You're oversimplifying things there. It's not just about the physical instance - I could just run git "naked" without Gitlab's tooling if it were just an issue of installing Git. The complexities arise when you then need to have Git exposed to the internet to allow AWS pipelining to operate. We then have gateway into your internal network that needs to be PCI-compliant (for our retail sites), audited by the Gambling Commission (for our online games) and ISO nnnn (I forget what standard we meet off hand). It's fair that most organisations might not have these hoops to jump through, but we do and hence why we migrated to hosted providers to remove some of our complexity. > * The thing to do when you don't want dependencies is to reduce your dependencies, not complain about a third party service that offers their software for free so you can run it yourself.* I think this is grossly unfair. For starters I'm not complaining about Gitlab, I was opening a discussion about them. You might disagree with my points and I welcome your opinion - otherwise it would be a dull and pointless discussion. :) Secondly your point about "The thing to do when you don't want dependencies is to reduce your dependencies" is entirely the point I'm making. Perhaps you've missed some of the issues I've raised or perhaps I've explained myself badly. But I have explored a number of options and not just blindly talking out of my arse (which I appreciate there's no way for you to know this given the anonymous nature of the internet). Lastly why would I be only interested in free solutions given the expectations I have? Currently we do pay for our Git hosting because of our requirements - and my expectations include paying a fee for a service if it solves a few problems. After all we are talking about enterprise systems - any reasonable costs are consolidated and billed back to the client.

INTPenis 9y ago

I use gitlab for one thing, they allow private repos without paying. My needs are pretty basic though, no CI/CD. At some point I've even had multiple remotes in a repo, both on gitlab and github.

luckytobby 9y ago

Everything was back on track very quickly, no data loss. Github has had major service outages recently as well (just google it to refresh your mind). They'll both have a few issues in the future because nobody is perfect. Come on.

laumars 9y ago
> "because nobody is perfect. Come on." If only I could make the same counterargument when my clients complain about downtime. :) Sadly in the modern world people expect ridiculous uptimes and thus my expectations are just derived from my clients expectations. I don't like that much either but frankly clients often just get their expectations from their customers demands. These days people expect 24/7 uptime so my job is to facilitate that wherever I can.
- mugsie 9y ago
  Sure - but is there any alternatives? Gitlab does have issues, but so do GitHub (and other providers). If your service is taken down by code hosting going away there is issues - unless you are running a code hosting service, or managed DevOps - in which case, the onus is on you to develop for failure (of any provider)
- Xylakant 9y ago
  > If only I could make the same counterargument when my clients complain about downtime. :) If you can't make that argument, then you indeed have a problem. Downtimes happen, reducing them gets expensive fast. 95% is fairly simple, 99.999 is extremely hard - it requires redundancy on each and every level. Every time a client demands this, I reframe their request in terms of required engineering effort. Few, if any, actually care about the 9 behind the decimal point after that. The best clients had downtimes already integrated into their operating plans: What happens if we go down, partially or fully, what do we do, how do we communicate and - most importantly, how do we get back up as fast as possible again.
  - laumars 9y ago

trome 9y ago

Run your own Gitlab instance, it isn't very hard to do. The point is to use Git in a decentralized manner, not circle around one closed platform or another. The main Gitlab instance being under such heavy load is not too great either, more needless centralization...

ergo14 9y ago

Try RhodeCode, you will get both mercurial and git. Since I prefer Mercurial over git I don't have any other option than to run my own instance.

chrisBob 9y ago
Try bitbucket. We use it at work and it is a nice service that includes Mercurial support
- zepolen 9y ago
  Never ever using Bitbucket again, worst experience ever. Gitlab for Git and Rhodecode for Mercurial are so much better.
- ergo14 9y ago
  But you can't self host bitbucket with mercurial support? I thought only the online version supports hg?
  - JimDabell 9y ago
    I think he was responding to: > Since I prefer Mercurial over git I don't have any other option than to run my own instance. You do have another option – you can use Mercurial with Bitbucket. Sure, it's not self-hosted, but you were complaining that you were forced to self-host because you prefer Mercurial, right?
    - ergo14 9y ago
      I'm not compaining about self-hosting - in fact I prefer that.

mdekkers 9y ago

Really, HN? Parent might not be a _popular_ opinion, but the parent stated the opinion in a mature, non-inflammatory manner. Communities go downhill quickly when a certain "critical mass" of users get downvote rights, and downvoting becomes a poor proxy for intelligent discourse. It is deeply frustrating when a cool community such as HN increasingly stifles reasoned debate with the split second, zero cost decision of downvoting a comment you don´t agree with. Remove downvoting, or increase the cost of downvoting (as in, one downvote will cost you 5 karma points, or something like that) because the HN I grew to enjoy is quickly starting to look like just another subreddit. edit: typos

MildlySerious 9y ago

I think this is, at least in part, a perceived thing. GitLab's technical blog posts regularly hit the HN frontpage, while GitHub's issues just seemingly get swiped under the rug, unless it's major, or it's positive news of them introducing new features. Just earlier I got messages that 'info for the latest commits couldn't be loaded' on GH, whatever that means, but I don't see a blog post as to why on HN.

laumars 9y ago
I think you're right. I've been doing more reading on Gitlab and their competitors and it seems I'd forgotten about a few incidents with Github and Bitbucket. I guess it just goes to show that openness is a double edged sword. Though I'm still thankful that businesses like Gitlab do adopt such policies.