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.
It's literally years in front of the competition ( GitHub and BitBucket).
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.
> 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?
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.
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.
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.
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.
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 ?