This article is more than 1 year old
JetBrains shoves TeamCity into the cloud, pitches Kotlin for build pipelines because YAML is 'really a pain'
No free plan: That's one way to avoid crypto-mining abuse of build minutes
JetBrains has released TeamCity Cloud, a hosted version of its Continuous Integration (CI) tool, with support for Kotlin DSL (Domain Specific Language) for configuring build pipelines.
TeamCity was first released in 2006 but to date has only been an on-premises product. Its role is to run tests and builds so that code changes are compiled and (insofar as it can be automated) verified as ready for deployment.
TeamCity does not itself build software, but instructs agents on build servers. An entire CI pipeline includes test, build and deployment, often to a staging server prior to production rollout.
According to JetBrains product marketing manager Alexander Rassokhin, pressure for a TeamCity cloud version only really kicked in with pandemic-enforced remote working last year. "TeamCity has always been an enterprise-level solution," he said.
In the context of software development, "most larger sized companies didn't consider moving to the cloud until very recently. This started to change rapidly last year when most people started working remotely. We started to see this paradigm shift happening in the larger clients."
JetBrains' own survey of the developer ecosystem last year showed that TeamCity is well behind the pack in terms of CI tool adoption. 55 per cent said they use Jenkins or Hudson; 27 per cent Gitlab CI; and after that a bunch of others – including GitHub Actions, CircleCI, Azure DevOps Bitbucket Pipelines, and more. TeamCity had just 8 per cent adoption.
A likely factor was that surveys like this do not break out commercial versus free users. TeamCity is a commercial tool, though the on-premises version has a free licence for up to three build agents and 100 build configurations. The cloud version has no free plan at all. A free plan is on the roadmap, Rassokhin told us.
Use cases
Why would a development team choose TeamCity versus these other, better-known CI tools? "There is no ultimate tool that is good for everything," said Rassokhin. "Most companies use a mix of tools."
Unsurprisingly, since JetBrains is an IDE company, the main appeal of TeamCity has been its IDE integration. "We really try to understand everything that happens during the build process. TeamCity can analyse what went wrong, find who was the author of the change that caused the failure, suggest the exact line of code that probably caused it and even open it directly in your IDE," he said.
Gitpod ditches Eclipse Theia for Visual Studio Code under redesign, sponsors new dev experience event
READ MORE"You can work inside JetBrains IntelliJ IDEA, edit your code and launch TeamCity jobs without switching windows and get the feedback right in the same window."
That is as you would expect, but the most distinctive feature of TeamCity is the option to use Kotlin DSL for build configuration. Kotlin is the language invented by JetBrains which runs on the JVM (Java Virtual Machine) and has been officially adopted by Google for Android development.
"We believe that this is the right way to go," said Rassokhin. "Kotlin gives you a way to work with a very tidy and compact code that is easy to maintain. With Kotlin you have all the advantages that a real programming language gives you, including tools like refactoring and auto-completions in your IDE."
JetBrains developer advocate Matthias Koch said: "If you dive into the DevOps world, chances are high you meet YAML around the next corner. For some tools, like Docker and Kubernetes, I think it's a good match. However, for CI infrastructure it often becomes a nightmare. Yet almost every CI/CD service out there is YAML-first." Rassokhin said that "large projects that are written in YAML they are really a pain to read. They are very hard to support."
Use of Kotlin is not essential, though. A web UI offers a visual approach, or there is an API that integrates TeamCity with other scripts.
There are a few issues with TeamCity Cloud. One is that only Linux and Windows build agents are supported. Building for macOS or iOS requires developers to bring their own Mac and hook it up as a self-hosted build agent. There is also a lack of customization options: no plugins can be added to TeamCity cloud. An Enterprise plan with plugin support is promised "before the end of 2021."
Pricing is somewhat complex and starts from $45 per month for three committers and 24,000 "build credits," where these credits translate to hours on build servers, with how much you get depending on the size of the build server. 24,000 credits translates to 2,400 minutes on "Linux small."
By contrast, GitHub will give you 2,000 free Actions minutes per month, or 3,000 for $4 per user. GitLab offers 400 CI/CD minutes free per month (less generous than it used to be) or 10,000 for $19 per month.
TeamCity then is somewhat expensive. Still, charging is one way to overcome a problem plaguing the free services: users abusing them to run cryptocurrency mining scripts, as happens on Azure DevOps and elsewhere. ®