BUT TeamCity UX is the worst UI from all CI systems that I have used. From first version of Jenkis to managed stuff like CircleCI. People hate is so much that someone added a Slack icon :teamshitty: at work.
Also, with Jenkins you're forced to use groovy for pipeline code :/...
Jenkins seems to suffer from too many cooks/anything goes mentality. It's clearly not well focused. It's feels like a handful of pet-projects lumped into one umbrella.
When it comes to functionality, TeamCity is constantly improving and innovating.
Based on the OP, I suspect their experience is with an old version or maybe misused or misconfigured.
At first, I thought TeamCity's UI was batshit crazy. In retrospect, I think it was just that it's not organized at all like Jenkins is, and I needed to re-adjust my mental model for how the build server should work. Or something like that. All I know is that, at some point along the way, I came to use TeamCity to automate more things, while still spending less time futzing with it than I did with Jenkins.
That said, I feel like TeamCity is also distressingly full of partially implemented features and flaky UX. It's just that its warts tend to accumulate on the periphery, rather than directly between me and the thing I'm trying to get accomplished before I can go home.
So, I think it's about mental model as you wrote, plus where your techstack is in terms of unification (containerization helps there tremendously).
Someone else mentioned groovy with a frown face, but tbh I much preferred writing all jobs in JobDSL, rather than in the Jenkins UI.
Sure, TC has had issues (especially when it came to scaling), but they fixed a lot of those and honestly, it's doing well now.
Issues usually came from people who didn't know how to make robust pipelines or leverage TC's functionality and felt like they had to reinvent everything. And that was in a company with thousands of employees, thousands of TC configurations and hundreds of agents.
>Issues usually came from people who didn't know how to make robust pipelines or leverage TC's functionality and felt like they had to reinvent everything
Blaming the end user is almost never the answer, even less when the average TC user is somewhat technical or very technical. If a tool throws hundreds of things to your face and call it a day, then people will end up reinventing everything since they didn't have a chance to discover how to make sense out of it (without tons of free time and guessing that is). I haven't used the very latest version though so things may have improved further but I believe it'd require a major overhaul to put things in order.
I've seen this happen a bunch of times, and when investigated the opinions are often not based on much thought, or are actually flat out wrong.
My company has just migrated from TC to Jenkins except for the project I run, which is still on TC. Why? Because I've actually read the TC user guide and so understand how it works, what it can do. Plus I like the GUI.
The justification for migration was idiotic, something like "Jenkins has a big community, look at how many plugins there are". Well guess what - Jenkins has more plugins than TC because it needs more to match the feature set. A lot of things that are built in with TC are unmaintained crappy plugins in Jenkins that you have to assemble yourself.
The other day I saw one of the instigators of this migration complaining on Slack that the build queue priorities plugin they were using had gone unmaintained and had serious bugs. Build queue priorities are built in to TC for a long time and JetBrains doesn't ship broken features very often, so my guess is it works. I had to resist engaging in a told-you-so moment ... why bother, the damage was done already.
In another case another senior guy decided on nearly his first week that a major piece of software we use sucks. For years he has constantly made claims of the form "$PRODUCT can't do X" or "feature Y is broken" and when the user guide is checked, in fact it can do X and when asked what is broken about feature Y he can't point to any actual concrete bug reports he can or will file. But nothing will shake his view on this and other junior devs pick it up and echo it to make themselves seem discerning and informed.
Time and time again I've seen stupid product choices in companies done for no better reason than someone formed a snap opinion without bothering to read the user guide. TC works great. It's one of the best CI systems out there. Spend an afternoon reading the user manual from cover to cover and it will pay huge dividends - also note that it's free if you only need 3 agents.
If people try to reimplement things in arbitrary broken shells scripts (the user issues) that can't be run locally, then it's not the CI tool's responsibility either.
So yeah perhaps they'd have done the new experimental UI in one fell swoop if they had less testing, who knows. But I'd rather they have a well tested product than ultra-fast UI replacement.
I pretty much use Gitlab CI these days for anything outside my day job though, and the stuff at work is all Azure Pipelines (via Azure DevOps) now.
At work we're experiencing several issues with triggers that don't kickoff when there are changes in the repo. Builds stuck for 2 hours or more on "Collecting changes". Builds that build from the default branch, even though they were called with a specific branch to build from. I could go on.