July 12, 2018 at 17:51TeamCity 2018.1: New Kotlin DSL, High Availability Mode, Improved Docker Integration, and Amazon S3 Out of the Box
Hello, 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 there is something to look at.
The full list of changes is, as always, impressive . But here we will focus on four main features of the release. Go!
TeamCity has its own DSL (Domain-Specific Language), with which you can describe the settings of projects and build configurations in Kotlin code, embodying 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 due to the fact that TeamCity no longer needs a uuid server and project ID, he learned how to generate them independently from the name of projects and build configurations. Here, for example, is all the code needed to describe a simple “Hello world” project in TeamCity:
Single file . All code for describing TeamCity settings is now stored in one file - settings.kts, which must 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 the same server. Just copy settings.kts to the appropriate repository.
Create projects from a URL . In order for TeamCity to read and apply settings from the code, it is enough to give it a 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):
In 2018.1, it became possible to start the server in read-only mode. This allows you to configure a highly accessible TeamCity cluster, consisting of two TeamCity servers: the main and the spare, working in read-only mode. In this case, the read-only server 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 failure of the main server, the read-only server will accept 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 it will not allow this state to be changed.
This is true for large installations, which are important to have uninterrupted access to the CI server, both during scheduled failures and during scheduled updates.
We previously wrote about the fact that TeamCity supports Docker “out of the box”: launching builds in the container, creating Docker images, adding and removing them from the repository, launching Docker commands, Docker compose.
This release adds support for the .NET CLI and Powershell runners, which allows you to complete these build steps inside the Docker container.
The Docker runner itself has also been updated: it natively supports build, push, and others.
How Docker support works in TeamCity, you can see in this video:
The TeamCity AWS S3 plugin has already existed for some time, but in version 2018.1 we fixed many problems and included it in the main distribution. S3 integration handles dependency artifacts and clean-up artifacts so elegantly and is so integrated into TeamCity UI that an unsuspecting user may not notice that artifacts are stored in the S3 bucket.
Here is a demo:
Among other improvements, it is worth noting a more convenient work with assembly steps inherited from the templates. In particular, it is now possible to set pre and post steps in the template and indicate that the configuration steps fall between them.
The new version also significantly improved work with NuGet feed. Now it can be enabled at the level of a specific project, and not globally on the entire server, which caused performance problems in the past. As a result, several NuGet feeds in different projects are now supported.
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 Java servers and agents, you can simply upload them to the root server project via a convenient web interface. Both the server and agents will immediately begin to use the new certificates.
We recently had a webinar, during which antonarhipov demonstrated all of the above in action. You can see it in the entry:
You can download (as well as run on AWS, in Azure or from the Docker container) the latest version of TeamCity 2018.1 from our website . Leave comments and suggestions on the new version in our bug tracker .
The full list of changes is, as always, impressive . But here we will focus on four main features of the release. Go!
New TeamCity Kotlin DSL
TeamCity has its own DSL (Domain-Specific Language), with which you can describe the settings of projects and build configurations in Kotlin code, embodying 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 due to the fact that TeamCity no longer needs a uuid server and project ID, he learned how to generate them independently from the name of projects and build configurations. Here, for example, is 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!'"
}
})
Single file . All code for describing TeamCity settings is now stored in one file - settings.kts, which must 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 the same server. Just copy settings.kts to the appropriate repository.
Create projects from a URL . In order for TeamCity to read and apply settings from the code, it is enough to give it a 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
In 2018.1, it became possible to start the server in read-only mode. This allows you to configure a highly accessible TeamCity cluster, consisting of two TeamCity servers: the main and the spare, working in read-only mode. In this case, the read-only server 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 failure of the main server, the read-only server will accept 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 it will not allow this state to be changed.
This is true for large installations, which are important to have uninterrupted access to the CI server, both during scheduled failures and during scheduled updates.
Improved Docker Support
We previously wrote about the fact that TeamCity supports Docker “out of the box”: launching builds in the container, creating Docker images, adding and removing them from the repository, launching Docker commands, Docker compose.
This release adds support for the .NET CLI and Powershell runners, which allows you to complete these build steps inside the Docker container.
The Docker runner itself has also been updated: it natively supports build, push, and others.
How Docker support works in TeamCity, you can see in this video:
Store artifacts on Amazon S3
The TeamCity AWS S3 plugin has already existed for some time, but in version 2018.1 we fixed many problems and included it in the main distribution. S3 integration handles dependency artifacts and clean-up artifacts so elegantly and is so integrated into TeamCity UI that an unsuspecting user may not notice that 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 the templates. In particular, it is now possible to set pre and post steps in the template and indicate that the configuration steps fall between them.
The new version also significantly improved work with NuGet feed. Now it can be enabled at the level of a specific project, and not globally on the entire server, which caused performance problems in the past. As a result, several NuGet feeds in different projects are now supported.
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 Java servers and agents, you can simply upload them to the root server project via a convenient web interface. Both the server and agents will immediately begin to use the new certificates.
We recently had a webinar, during which antonarhipov demonstrated all of the above in action. You can see it in the entry:
You can download (as well as run on AWS, in Azure or from the Docker container) the latest version of TeamCity 2018.1 from our website . Leave comments and suggestions on the new version in our bug tracker .
We remind you that TeamCity Professional provides 100 builds of configurations and 3 builds of an agent absolutely free of charge , without restrictions on time and functionality.Have a nice build!