6 ms·

I m in one of the companies they quoted as case study. The lies are so horrible I hesitate to do something: they fucked us completely replacing a wonderful gith

I m in one of the companies they quoted as case study. The lies are so horrible I hesitate to do something: they fucked us completely replacing a wonderful github/teamcity combo, it crashes all the time, features are so amateurish (vs teamcity especially) that we're struggling just to do basic things. I dont know what to do, but public investors should stay away: the product is not ready for people to pay for it. It's years behind the competition.

danudey 5y ago
Counterpoint: we've moved to GitLab internally (from SVN, granted), and while GitHub would have been easier because it's far more widely supported in tooling and integrations, GitLab has been great for us so far. I would have preferred to switch to GitHub if we had an internal hosted GitHub Enterprise kind of situation, but so far Gitlab is doing fine for us. It could be a matter of scale, though; perhaps for larger teams, larger repositories, or pre-existing Git-based MR/CI workflows, it's a dumpster fire, but that's not us so we can't speak to it. Who knows though, maybe in a few years I'll regret writing this comment.
sofixa 5y ago
Honestly sounds like an implementation issue. I've run multiple Gitlab instances and I've used some more, and "crashes all the time" isn't a thing that just happens. Most features work fine, core ones even more so, some of the newer ones are clearly not polished enough but mostly function. It's literally years in front of the competition ( GitHub and BitBucket).
- secondaryacct 5y ago
  How many thousands repos do you have ? We are 10k+ users with many many more repos scattered around the world. But the thing I ll say is the git part is satisfactory. It's the CI part we are livid about. It's not "years in front of the competition" if you think of Teamcity. Github focus on what it does right.
  - sofixa 5y ago
    I'd say 5-6k users, and the number of repos is easily between there and 10k on the biggest Gitlab instance I've used. The CI/CD part works well, including for complex multi-project dynamic pipelines. We don't have crashes, ever. > It's not "years in front of the competition" if you think of Teamcity. Github focus on what it does right. The competition for me is the all-in-one solutions like Github and Bitbucket. If you have to deploy, maintain and sometimes pay for an extra CI/CD solution, either something is wrong or you have very very specific requirements. What is it that TeamCity does better than Gitlab CI/CD?
    - secondaryacct 5y ago
      I was gonna write a long list of doleances but you know what, Ill give it a chance after all. We re still learning it, we ll figure it out I guess, and if it's cheaper, well, it s more money for shareholders.
kickopotomus 5y ago
> it crashes all the time, features are so amateurish (vs teamcity especially) that we're struggling just to do basic things. Do you have an on-prem instance? What sort of features does teamcity have that are not there in Gitlab CI? Teams in my org are currently switching from Gerrit/Jenkins combos to Gitlab and I have been pretty pleased so far. I do wish there was a nicer way to experiment with different CI configurations from within the browser to prevent a bunch of pointless commits messing with your config YAML; but, otherwise I have been pretty happy with the flexibility.
- secondaryacct 5y ago
  Well gitlab has all the features of teamcity on paper: it can run a remote script and build any random thing. But why do we need so much work to write the script ? Why is the reporting so bad on test failure, why building complex dependency chains running in parallel and in sequence doesnt work ? Why do we need to touch the repo to change the build descriptor? It's just not as fun to use, immediate, beautiful, and productive. It's thrown on top of the git part, half assed.
Chico75 5y ago
I'm from another company quoted in a case study and can say the contrary overall. It does require work to properly scale for a few thousand of people if you run it yourself but it provides a lot of values for our developers to get their work done and require less maintenance than other SCM/CI systems we had to maintain in the past.
- secondaryacct 5y ago
  Are you one of these developers? Our management speak the same way of our infinite suffering during the migration ;) You may betray yourself: developer dont maintain the CI system, they use it. And while I may accept it's now easier to maintain, why not, it's because it does less of what we need, possibly ?

danudey 5y ago

Counterpoint: we've moved to GitLab internally (from SVN, granted), and while GitHub would have been easier because it's far more widely supported in tooling and integrations, GitLab has been great for us so far. I would have preferred to switch to GitHub if we had an internal hosted GitHub Enterprise kind of situation, but so far Gitlab is doing fine for us. It could be a matter of scale, though; perhaps for larger teams, larger repositories, or pre-existing Git-based MR/CI workflows, it's a dumpster fire, but that's not us so we can't speak to it. Who knows though, maybe in a few years I'll regret writing this comment.

sofixa 5y ago

Honestly sounds like an implementation issue. I've run multiple Gitlab instances and I've used some more, and "crashes all the time" isn't a thing that just happens. Most features work fine, core ones even more so, some of the newer ones are clearly not polished enough but mostly function. It's literally years in front of the competition ( GitHub and BitBucket).

secondaryacct 5y ago
How many thousands repos do you have ? We are 10k+ users with many many more repos scattered around the world. But the thing I ll say is the git part is satisfactory. It's the CI part we are livid about. It's not "years in front of the competition" if you think of Teamcity. Github focus on what it does right.
- sofixa 5y ago
  I'd say 5-6k users, and the number of repos is easily between there and 10k on the biggest Gitlab instance I've used. The CI/CD part works well, including for complex multi-project dynamic pipelines. We don't have crashes, ever. > It's not "years in front of the competition" if you think of Teamcity. Github focus on what it does right. The competition for me is the all-in-one solutions like Github and Bitbucket. If you have to deploy, maintain and sometimes pay for an extra CI/CD solution, either something is wrong or you have very very specific requirements. What is it that TeamCity does better than Gitlab CI/CD?
  - secondaryacct 5y ago
    I was gonna write a long list of doleances but you know what, Ill give it a chance after all. We re still learning it, we ll figure it out I guess, and if it's cheaper, well, it s more money for shareholders.

kickopotomus 5y ago

> it crashes all the time, features are so amateurish (vs teamcity especially) that we're struggling just to do basic things. Do you have an on-prem instance? What sort of features does teamcity have that are not there in Gitlab CI? Teams in my org are currently switching from Gerrit/Jenkins combos to Gitlab and I have been pretty pleased so far. I do wish there was a nicer way to experiment with different CI configurations from within the browser to prevent a bunch of pointless commits messing with your config YAML; but, otherwise I have been pretty happy with the flexibility.

secondaryacct 5y ago
Well gitlab has all the features of teamcity on paper: it can run a remote script and build any random thing. But why do we need so much work to write the script ? Why is the reporting so bad on test failure, why building complex dependency chains running in parallel and in sequence doesnt work ? Why do we need to touch the repo to change the build descriptor? It's just not as fun to use, immediate, beautiful, and productive. It's thrown on top of the git part, half assed.

Chico75 5y ago

I'm from another company quoted in a case study and can say the contrary overall. It does require work to properly scale for a few thousand of people if you run it yourself but it provides a lot of values for our developers to get their work done and require less maintenance than other SCM/CI systems we had to maintain in the past.

secondaryacct 5y ago
Are you one of these developers? Our management speak the same way of our infinite suffering during the migration ;) You may betray yourself: developer dont maintain the CI system, they use it. And while I may accept it's now easier to maintain, why not, it's because it does less of what we need, possibly ?