JetBrains shoves TeamCity into the cloud, pitches Kotlin for build pipelines because YAML is 'really a pain'

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 …

[Elledan]

Anything but YAML

After a run-in with YAML for CI purposes in the context of Travis, I can't argue with the view that the use of YAML has all the appeal of sticking one's hand into a meat grinder. Heavens know that after the Nth cryptic YAML parse error from somewhere in the build pipeline I wanted nothing more than to rage quit.

While I had some not unpleasant experiences with the Groovy-based DSL for an automation plugin with Jenkins CI, I'm not convinced that Kotlin is more suited somehow. To me it feels more like a 'We use Kotlin because we created it' kind of deal, but that's something one has to find out in practice, I guess.

Either way it's not YAML, which is already a sole reason to use it over YAML :)

[Throatwarbler Mangrove]

Re: Anything but YAML

Out of genuine curiosity: which solution do you prefer? (Open question to all commentards.)

[Elledan]

Re: Anything but YAML

I found the aforementioned Jenkins CI setup with DSL automation plugin for setting up tasks from a Git repository (task updated when pushing a new commit) to be a reasonably effective setup.

Not that it was perfect, mind you. As with any CI system, there has to be an easy way to test and validate a CI task before adding/updating it, which was an unsolved problem then.

Have a staging/production division of the CI system as well, perhaps?

[J27]

Re: Anything but YAML

I'm not a big fan of YAML, but you can get an editor that validates your file to avoid things like that.

[Anonymous Coward]

Complexity for it's own sake?

When build pipelines are almost as complex as the code being built you have to wonder if it's for developers benefit or for the bank balance of the companies flogging these systems. Building software from a high level perspective is a relatively simple solved problem, it should become easier as the years go by, not evolve into some byzantine nightmare that only trained high priests can comprehend.

Or maybe I should just say get off my lawn.

[Robert Grant]

Re: Complexity for it's own sake?

That's why there's a GUI for building pipelines.