TeamCity: Second Class Citizen to Jenkins? Why?

Hi Ed, what do you think would be helpful for you personally regarding "selling" TeamCity to your friends/colleagues? Any materials you can think of in particular?

Overall, I see your point about somewhat low awareness of TeamCity in many parts of the DevOps community.

Part of the issue is that Jenkins is free and TeamCity is only free for 20 build configs.

It is the same thing as people using eclipse instead of IDEA because eclipse is free even though it is stinking pile of horse poo!

Maybe a community edition that only has support for a limited set of plugins/runners might help.

Although, I feel the biggest awareness of IDEA was Android Studio. 

Maybe you can do something like TravisCI and provide free build configs to GitHub projects so people are aware of it from their free time.

The current option for open source licenses doesn't apply to one man projects with low throughput which means that people don't get the exposure to it.

Thanks for your ideas. That's true, TeamCity is a commercial software, which makes it a bit harder to compete with its free OSS counterparts price-wise. Although I believe the free Professional edition is a very generous offer, and our usage numbers confirm it.

>Maybe you can do something like TravisCI and provide free build configs to GitHub projects so people are aware of it from their free time.

That's actually an interesting input, we'll take it into consideration.

Yes... TeamCity & JetBrains is extremely generous. I don't think it's a "cost thing," more of an "awareness thing." Frankly, rarely have a need for more than 20 build configurations, and until recently have never had to purchase a license (in 10 years). Selling the idea to my CTO wasn't hard at all, after showing him how much time/money was being saved.

As a DevOps Architect, I can't tell you how many unsolicited emails I get for seminars from Jules Louis @ DevOps.com for webinars showing that Jenkins is the only real tool for running continuous integration (which I use TeamCity for so SO much more). Which is the point of my original post: "We need more TeamCity Cowbell!"

We need more TeamCity Cowbell!

Please hire a team of TeamCity evangelists to speak at conferences, do interviews, be active online (hire more if already have a team). More Tweets. More community walk-through tutorials -- most of the ones I've read start off really strong but end too soon and don't provide enough detail needed to actually accomplish the task, or leave you hanging.

Yes, I get those as well, and TBH you shouldn't expect such aggressive marketing from JetBrains. Nevertheless, we certainly are planning to expand our evangelism team and produce more educational and promotional materials.

Hi,

sorry for bringing up an old thread, but actually, in two companies I worked at, Teamcity's licensing scheme is a problem for the acceptance. For instance, where I work now, we have very long lasting tests (2h or more). Those tests must run on in 20 different configurations. So the only way to get the results in a reasonnable time is to parallelize them. We would love to parallelize them to the maximum, but for that we would need 20 agent licenses, plus the agents for the builds themselves, so a license for 50 agents.

The funny thing is that the 20 agents run on 2 standard PCS, because the actual tests are running on target hardware connecting to the PC. The agent just needs to flash the firmware and do I/O. But since one agent can only handle one run at a time, we need to start numerous agents on one PC. So here the BOM:

- 2 standard PC: €1500

- Hardware and cables: €500

- One Teamcity license: € 12,999.00

I would't call that generous. We are not a big company, we are just a small company dealing with many configurations and long lasting tests!

Even if we were a big company, € 12,999.00 is a very amount, especially when compared with, say, Jenkins...

So, to improve Teamcity acceptance, I would say: a much more aggressive stepped tarif... Who wants to start at € 1,999.00 and be forced after a few years to pay € 12,999.00?

Hi Olivier,

We have the related request in our tracker you can vote for: https://youtrack.jetbrains.com/issue/TW-13849. 

There are two ways to run parallel tests: 1. use several build configurations; 2. introduce parallelism inside the build script. Can the second approach be used in your case?

Hello Alina,

unfortunately, no, because each run uses/blocks a specifc hardware equipment.

If one agent was able to run builds in parallel, the licensing problem would indeed be solved. That would also save us the effort to maintain multiple agents installation on a given PC.

Another option would be to count multiple agents running on the same PC as a single agent, as far as licensing is concerned.

By the way, this ticket wouldn't help us:

https://youtrack.jetbrains.com/issue/TW-13849

Because the test configuration and the test results are specific to a build, we can't run several tests within one TC build.

This would help though:

http://youtrack.jetbrains.com/issue/TW-34200

See also:

https://teamcity-support.jetbrains.com/hc/en-us/community/posts/206855145-Lack-of-parallelization-on-the-agent-level-e-g-Jenkins-executors-

https://teamcity-support.jetbrains.com/hc/en-us/community/posts/206190519-Running-two-configurations-on-one-agent-simultaneously

Hi Olivier,

Thank you for your feedback. Please vote for the requests you are interested in.

What about the second option, will it work for you?

> 2. introduce parallelism inside the build script

Hi Alina,

no, it won't. Imagine we build in Teamcity an Android distribution that runs on mobile phones, and we support 20 different phones from a single code baseline. With every commit, we want to test it on every of the 20 phones. Each test takes 2h.

We have defined the common functionality in a TC template, and used it to create 20 different build configurations, with the communication parameters of the mobiles phone, e.g. a configuration called "Nexus 5 S/N 123456" with parameter "hardware_slot=12", another "HTC One S/N ABCD" with parameter "hardware_slot=7". When one of the configuration is triggered, the firmware is flashed on the phone and the tests are started.

We want to see in TC the result of a complete single test run on a given phone, so we cannot parallelize within a build configuration. Since one agent can only run one build at a time, and has to wait for the result, one agent is completely blocked for 2h.

The only solution we have right now is to increase the number of agents, but it's really expensive. License costs are the bottleneck.

If the agents were able to deal with multiple runs in parallel, we would be fine. The performance is not an issue, since the phones are stressed, not the PC.