TeamCity 2019.2 opens new dimensions of control over the historical data and artifacts created by your builds. A reworked clean-up engine allows you to set up different clean-up policies with a wide spectrum of filters: for example, you may choose to keep all builds from specific branches, or with specific tags.
We believe that new clean-up rules will be particularly useful for companies that have a lot of projects, and for teams that use feature branches during development.
Pros love tools that help them monitor how mission-critical systems are behaving and performing. Starting with 2019.2, TeamCity exposes its metrics via an HTTP endpoint, so they can be scraped by Prometheus and then visualized via the Prometheus web interface, or in a Grafana dashboard.
The metrics include the server performance information, as well as various details on agents, projects, and build configurations.
For many large organizations, a high-performance CI is critical to their workflows. TeamCity takes another step toward a multi-node setup allowing you to add builds to the build queue, manage build problems and investigations, and perform other user-level actions – now on a secondary server.
Developers often open TeamCity many times a day, which is why we want it to be a place where they can quickly find what they need, regardless of the size and complexity of their projects. Following the TeamCity UI roadmap, we are introducing a new build page that gives you an easy way to browse build history, investigate problems, and discover any misconfigurations or bottlenecks in your build chains.
Check out the experimental UI – we're proud of how it now looks and feels.
We want TeamCity to have everything you need in a modern workflow. Version 2019.2 adds support for EC2 launch templates, and lets you run cloud build agents using the launch parameters from your AWS account. With the launch templates, updating and installing new software on build agents becomes a very simple and straightforward task – you no longer need to change anything in the TeamCity project configuration.
Goodbye clicking, hello scripting. The Kotlin DSL now provides a simple and very straightforward syntax for defining build chains. Set up sequential and parallel builds, configure failure conditions and dependencies – and store everything as code.
Project configuration just got easier. Starting with 2019.2, your Kotlin DSL configurations may include custom parameters, which you can define later when importing the project in the UI.
Quickly test your changes by creating a Git patch, uploading it to TeamCity, and running a personal build – without creating any branches or committing anything.
TeamCity UI is getting a major overhaul, and here’s a first taste of what you’re going to get in this version.
Not only have we improved the look, but we've also updated the underlying technology stack so now the UI works as a single-page application, which means you can access parts of it faster and all the changes appear instantly. See the TeamCity UI roadmap to stay up to date with all the planned changes.
In 2019.1, we are targeting the pages related to working with projects and build configurations.
The new project overview presents you with a dashboard-style view over your build configurations. Each configuration gets its own card which displays a histogram with up to 14 of the latest builds. For each of the builds, you can see the status (green means successful, red is failed), build time, and how long the build has spent in the queue. There is also information about the build that is currently running.
The reworked Branches tab displays your default branch at the top, hiding the rest of the branches in an expandable block underneath. The details of the latest builds in the default branch can now be seen right away which increases the visibility of the important data.
Using GitLab? TeamCity 2019.1 adds full support for GitLab. You can now set up a GitLab connection and create projects in TeamCity with one click, by simply picking a GitLab project from the list.
We’ve also added support for GitLab merge requests, so you can now set TeamCity up to automatically run the build on each merge request and then automerge it if the build is successful.
The Go language is now supported natively by TeamCity. Add your Go projects and TeamCity will detect and report Go tests, providing rich insights into the test status, its history across the builds, and duration, and will mark unstable tests as flaky. With the Test History tab, you can now dig deeper into your Go tests.
In addition to basic HTTP authentication, TeamCity now supports authentication based on permanent access tokens. Tokens are useful for REST API authentication, so that you don’t need to expose a user login and password in scripts.
With this more flexible way of creating Spot Instances, you can now have more granular control over your Spot Fleet. TeamCity 2019.1 lets you submit and edit the spot fleet configuration file and specify the strategy, set the target capacity, and add tags to your instances. It is a more advanced and cost-effective way of running your builds on AWS.
The secondary node now has an additional responsibility: processing the build lifecycle. If you turn it on, the secondary node will handle the build-related tasks, such as running and finishing builds, uploading artifacts, and failure conditions processing. This change expands the already broad list of tasks that you can offload from your main server onto a secondary one: collecting changes, serving as a read-only backup node, and now, processing the build lifecycle.
Tools will now only be loaded onto agents on demand. The necessary tools will be loaded only when the first build requiring them appears. This significantly improves the build agent upgrade times and saves you network traffic.
The secondary TeamCity node is designed to take the load off the main TeamCity server by taking over the task of collecting and checking for changes from the Version Control Systems. Outsourcing the collecting of VCS changes to the secondary node thus increases the scalability of the whole installation. It is also possible to use the secondary node for a high availability setup.
TeamCity now extends its support for GitHub pull requests. Filter the pull requests by author and limit it to internal or external collaborators, or open it for everyone. There is also the option to filter the pull requests by target branch.
You can now browse and install plugins in TeamCity directly from the JetBrains plugin repository.
Once a plugin is installed from the plugin repository, you no longer need to restart the TeamCity server for it to be applied.
Similarly, when developing a plugin for TeamCity, there is no need to restart the server anymore.
TeamCity 2018.2 lets you add screenshots and other test data, such as links, artifacts, logs, and numeric values, to the test results. These will be displayed natively in the test details section of the UI.
Unsure how best to describe a setting in the Kotlin DSL format? TeamCity now automatically generates DSL code for all your settings and lets you preview it in the admin UI. Handy for learning DSL format or for just copying parts of DSL to insert into already existing settings.kts file.
You can now let TeamCity suggest or automatically assign investigations to team members based on a number of heuristics. That way the person who most likely broke a build will receive a notification to investigate the failure.
TeamCity 2018.2 lets you specify multiple NuGet feeds to be used by builds in a project and all its subprojects. It also introduces support for NuGet Server API v3.
Up to 100 build configurations and 3 concurrent builds. No user or time limits. Fully featured.
Kotlin DSL has been significantly reworked and improved and now allows simpler usage, portability, and creation of projects from just one file.
The format of the DSL has been simplified. TeamCity no longer requires uuid and project IDs, which makes the code simpler and more readable. As an example, this is all the code you would need for a basic “Hello world!” project in TeamCity:
.teamcity/settings.kts file is now all you need to describe the project settings.
Kotlin DSL scripts are now server and project independent, which means you can share the same script between different servers or even projects on the same server. All you need to do is to check it into the repository.
When creating a project in TeamCity, just point it to the repository with your
.teamcity/settings.kts file and TeamCity will automatically create the project with all the required settings and build configurations, as described in code.
Spin up a High Availability TeamCity installation with the new read-only server mode. The read-only server has access to the database and the data directory, and in the event of the main server becoming unavailable, will accept all the requests and allow read access to the builds, artifacts, etc. Handy for running seamless server upgrades or during unplanned downtime.
Docker wrapper now supports .NET CLI and PowerShell runners.
push, and other Docker commands are now available directly in the new Docker runner, which replaces the old Docker Build Runner.
TeamCity 2018.1 comes with built-in Amazon S3 support. Storing, uploading, downloading, and removing artifacts from S3 is now integrated natively and can be done via the TeamCity UI. The integration handles the dependencies and clean-up so that users wouldn’t even need to know that S3 is under the hood.