5 ms·

I like the TeamCity UI. There I said it and mean it. Sure, TC has had issues (especially when it came to scaling), but they fixed a lot of those and honestly,

by Orphis 6y ago

I like the TeamCity UI. There I said it and mean it. 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.

outime 6y ago
To be fair I expect that somebody outside my circle would like it at least! Now that being said: >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.
- pletnes 6y ago
  True, but all CI systems allow you to run arbitrary shell scripts. This is often the source of e.g. hard-to-debug broken builds, because you can’t necessarily run the bits locally, or at least it’s inconvenient.
- Orphis 6y ago
  If you don't read the documentation, sure, it's hard to guess how things work, but it's hardly the responsibility of the tool maker to change that. 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.
- thu2111 6y ago
  I think you should consider that groupthink gets established very easily inside companies. It only takes one brash but senior engineer (even if only in the "been there a long time" sense) to loudly proclaim a tool sucks and how much they hate that tool, and pretty quickly you can get a chorus of "me too" and people who disagree just decide they have better things to do than pick a fight. 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.

by Orphis 6y ago

outime 6y ago

To be fair I expect that somebody outside my circle would like it at least! Now that being said: >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.

pletnes 6y ago
True, but all CI systems allow you to run arbitrary shell scripts. This is often the source of e.g. hard-to-debug broken builds, because you can’t necessarily run the bits locally, or at least it’s inconvenient.
Orphis 6y ago
If you don't read the documentation, sure, it's hard to guess how things work, but it's hardly the responsibility of the tool maker to change that. 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.
thu2111 6y ago
I think you should consider that groupthink gets established very easily inside companies. It only takes one brash but senior engineer (even if only in the "been there a long time" sense) to loudly proclaim a tool sucks and how much they hate that tool, and pretty quickly you can get a chorus of "me too" and people who disagree just decide they have better things to do than pick a fight. 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.