3 ms·
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 ou
by 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 agoThat'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.
- jacquesm 9y ago> I think this is grossly unfair. No, I think you are grossly unfair. You write that you 'really, really want to like gitlab', harp on them having 'issues every few months' (as if there is any online service that does not have issues every few months, and which blows this particular issue up to a magnitude it does not deserve) and then present a use-case that gitlab offers the perfect solution for, which you reject for reasons all your own. Sounds to me like you are making a problem rather than using tools in the ways they are intended. Whether the solution is paid or not is not the relevant bit, the relevant bit is that you have the option to self-host which you do not with gitlab's main competitors. Your AWS complexities are not gitlab's problem, they are yours.
- laumars 9y agoLike I said before, we were already self hosting (albeit not with Gitlab's tooling) before moving to a hosted solution. If it were as easy as you claim it to be then we would never have switched aware from self hosting. I am a control freak so I actually prefer self hosting myself. But it was steadily becoming impractical. I apologize if I've badly explained the problems we encountered. But please don't assume I'm some idiot who doesn't know what I'm doing just because your business has it's own different set of requirements than ours. > "Your AWS complexities are not gitlab's problem, they are yours.* I'm not blaming Gitlab. I'm saying AWS complexities make some solutions infeasible. I also said some of the compliance regulations we adhere to also add complexities that make some solutions less practical. I really don't understand why are you being so abrasive about this.
- jacquesm 9y agoBecause your initial comment pans gitlab quite extensively without them necessarily being the party that deserves your scorn.
- laumars 9y ago> Because your initial comment pans gitlab quite extensively I said they have 2 issues arise a year (which, by the way, was already counter argued before you joined the thread). I did also compliment 2 other aspects of their business. So to say my "initial comment pans gitlab quite extensively" and "your scorn" is needlessly sensationalising things. We are all professionals so can we please have a grounded discussion?