What’s new in TeamCity 2020.1

TeamCity 2020.1 features conditional build steps, allows launching build agents in a Kubernetes cluster, and integrates with Azure DevOps and Jira Software Cloud. It adds more capabilities to secondary servers in a multi-node setup, comes with a new Slack notifier, and has many great improvements to the experimental UI.

Conditional build steps for unconditional versatility

Conditional build steps for unconditional versatility

Have you ever wanted to execute different command line scripts on different platforms, or deploy changes in different branches to different staging servers? Now you're free to do just about anything! TeamCity 2020.1 allows you to specify conditions for your build steps and execute them only if the criteria are met.

Build with scale in a cluster. 10x K8s.

Build with scale in a cluster. 10x K8s.

Simple and reproducible cluster deployments are now available out of the box. TeamCity 2020.1 lets you implement a scalable CI/CD architecture on top of Kubernetes: build agents can be launched automatically when you need them, do their job, and then be removed after the build is completed.

Multi-server magic

Multi-server magic

Running multiple TeamCity servers and making them work together can elevate your CI/CD to a whole new level of performance and reliability. We have improved how TeamCity works in a clustering environment by extending the capabilities of secondary servers with trigger processing and support for user-level actions in the UI.

Trigger processing

Professionals working with large installations have hundreds if not thousands of triggers that fire on changes in VCS, package updates, and new artifacts. To help them achieve the highest possible performance, we now allow secondary servers to take part in this process and take some load off the primary server.

User-level actions

We have improved the UI of the secondary server, making it possible to modify user profiles, change view of projects and configurations, manage build agents, and more.

Easier deployment of cloud build agents

TeamCity 2020.1 comes with a new option to download a pre-packaged agent distribution from the TeamCity server. Pre-packaged build agents don’t need to update themselves upon connection to the TeamCity server, and this makes creating and updating cloud images faster and more straightforward.

Level up your notifications

Level up your notifications

To take TeamCity’s notification capabilities to new heights, we’ve implemented a new build feature that allows project administrators to set up automatic alerts to the entire team. New notifications can be configured on the build configuration level, so you can edit, reuse, and share them using the Kotlin DSL.

The all-new Slack notifier lets your team get notifications about the status of your builds directly in Slack.

The power of integrations

Jira Software Cloud

Jira Software Cloud

TeamCity has always had elegant integration with Jira, which automatically replaces issue codes in commit messages with links to the respective Jira issues. To support even more workflows, we have extended the integration and started to send the status of your builds and deployments to Jira Software Cloud. Now you can look into your CI/CD pipelines and release history right in your issue tracker, and see which issues are associated with failing builds.

Azure DevOps

Azure DevOps

We have extended the list of Git hosting services supported by the Pull Requests build feature, and added support for the Azure DevOps pull requests. The new option allows you to automatically run builds on pull request branches of the Azure DevOps, similarly to how you can do it with GitHub and GitLab.

New Sakura UI

New Sakura UI

Most developers use CI/CD every day, and we want it to feel like home. That’s why we’re continuing our quest to create a new UI that will be fast and easy to use, and will let us deliver new features faster.

To support more use cases of the classic TeamCity, the experimental UI of version 2020.1 comes with updated Agents and Projects pages, and allows configuring the project sidebar.

There is more to this release! For the full list of changes in TeamCity 2020.1, please refer to the TeamCity documentation.

What’s new in TeamCity 2019.2

TeamCity 2019.2 gives you great new ways to manage the clean-up of your builds and to monitor your server’s performance. It supports EC2 launch templates, and features a new DSL syntax for defining build chains. It also provides an easy way to run personal builds with Git patches, and adds many improvements to the experimental UI.

Power up your clean-up

Clean-up rules in TeamCity

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.

Bird’s eye of your CI

TeamCity metrics in Prometheus

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.

Scalability, taken further

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.

More ways to be productive with experimental UI

New build page in experimental UI

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.

EC2 launch templates. Builds taken to new heights

Support for EC2 launch templates

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.

Level up your DSL

Build chains, built easily

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.

Many parameters. One template.

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.

Run more. Wait less. Start builds with Git patches.

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.

For the full list of changes in version 2019.2, see the TeamCity documentation.

What’s new in TeamCity 2019.1

New look, new feel, fewer clicks

New UI Sidebar Project overview

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.

Project overview

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 Branches tab

The Branches tab

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.

Full GitLab support out of the box

Full GitLab integration

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.

Go all the way

Native Go support

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.

Token-based authentication

Token-based authentication

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.

Snapshot dependencies without sources synchronization

Snapshot dependencies without sources synchronization

You can now turn off the synchronization of code revisions for the snapshot dependencies. This is handy when running deployments and lets you promote one of the older builds in the chain using the latest deployment configuration.

AWS Spot Fleet requests

Processing build lifecycle

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.

Processing build lifecycle on a secondary node

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.

Processing build lifecycle

On-demand tools loading

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.

There is more to this release! Find out about the other new features.