TeamCity 2018.1: New Kotlin DSL, High Availability Mode, Improved Docker Integration, and Amazon S3 Out of the Box

Hi, Habr! We recently released a new version of TeamCity - 2018.1. This is the first major release of our CI / CD server this year. And it has something to look at.



The complete list of changes, as always, is impressive . But here we will focus on the four main features of the release. Go!

New TeamCity Kotlin DSL

TeamCity has its own DSL (Domain-Specific Language), with which you can describe project settings and build configurations in Kotlin code, implementing the principles of Infrastructure as Code. In 2018.1, we significantly reworked the format of this DSL, making it simpler, more convenient and more functional.

')

Easier . The DSL format was simplified by the fact that TeamCity now no longer needs the uuid server and project ID, he learned to generate them independently from the name of the projects and build configurations. Here, for example, all the code needed to describe a simple “Hello world” project in TeamCity:

version = "2018.1" project{ buildType(HelloWorld) } object HelloWorld : BuildType({ name = "Hellow world" steps { scriptContent = "echo 'Hello world!'" } }) 

One file All code for describing TeamCity settings is now stored in one file - settings.kts, which should be added to the .teamcity directory.



Portability Since the code now has no binding to a specific server or project, it can be reused for other installations or projects within a single server. It is enough to copy the settings.kts to the corresponding repository.



Creating projects from URL . In order for TeamCity to read and apply the settings from the code, it is enough to indicate to it the link to the repository with .teamcity / settings.kts. All described settings will be executed automatically.



Here is a short demo of the new Kotlin DSL features from antonarhipov (in English):

High availability and read-only mode

In 2018.1, it became possible to start the server in read-only mode. This allows you to set up a highly available TeamCity cluster consisting of two TeamCity servers: a primary and a spare, operating in read-only mode. The read-only server at the same time will have read access to the database and data directory, and will constantly pump up data modifications performed by the main server. In the event of a primary server failure, the read-only server will take over all requests. It is important to understand that the read-only server will only be able to show the last state at the time of the collapse of the main server, but will not allow changing this state.



This is true for large installations, which is important to have uninterrupted access to the CI server, both during scheduled outages and during scheduled updates.

Improved Docker Support

Previously, we already wrote about the fact that TeamCity supports Docker out of the box: launching builds in a container, creating Docker images, adding and deleting them from the repository, launching Docker commands, Docker compose.



This release adds support for the .NET CLI and Powershell runners, which allows you to perform these assembly steps inside the Docker container.



The Docker runner itself has also been updated: the build, push and other commands are natively supported in it.



How docker support for TeamCity works can be seen in this video:

Store artifacts in Amazon S3

TeamCity AWS S3 plugin has existed for some time, but in version 2018.1 we have eliminated many problems and included it in the main delivery. S3 integration so elegantly handles the dependency artifact and clean-up artifacts and is built into the UI TeamCity so that the unsuspecting user may not notice that the artifacts are stored in the S3 bucket.



Here is a demo:

Other improvements

Among other improvements, it is worth noting a more convenient work with assembly steps inherited from templates. In particular, it is now possible to specify pre and post steps in a template, and indicate that configuration steps fall between them.





The new version also significantly improved the work with NuGet feed. Now it can be enabled at the level of a specific project, rather than globally on the entire server, which caused performance problems in the past. As a result, several NuGet feed are now supported in different projects.







If some of your services on the network work for SSL certificates that are not signed by a well-known authority, then instead of the rather complicated process of importing such certificates into a Java server and agents, you can simply upload them to the root server project via a convenient web interface. Both the server and the agents will immediately start using new certificates.



We recently held a webinar, during which antonarhipov demonstrated all of the above in action. It can be seen in the record:





You can download (and also run on AWS, in Azure or from the Docker container) the latest version of TeamCity 2018.1 from our website . Leave comments and suggestions for the new version in our bug tracker .

We remind you that TeamCity Professional provides 100 builds of configurations and 3 builds of the agent completely free of charge , with no restrictions on time and functionality.

Successful builds!