TeamCity 2017.2.3 is available

Yet another TeamCity update is available today. TeamCity 2017.2.3 fixes a few important performance problems, further improves security and provides better integration with Azure Container registry.

See our Release Notes for the full list of fixes.

The data format of TeamCity 2017.2.3 is the same as all the other 2017.2.x builds, which means you can upgrade easily and freely downgrade without lengthy restore from a backup.

When upgrading from TeamCity 2017.2.x, the automatic update will make things easier. If you’re upgrading from older versions, download TeamCity 2017.2.3 and follow our standard upgrade instructions.

Happy building!

Posted in Release | 2 Comments

The official TeamCity Azure Resource Manager template

We are happy to announce the Azure Resource Manager template for TeamCity. You can now deploy TeamCity to Azure cloud services and save time on configuration tasks. Get ready to start using TeamCity in several minutes!


Deploy TeamCity to Azure Cloud Services

The template performs the following tasks:

  • Setting up of an external database
  • Creating a virtual machine for the TeamCity server
  • Configuring the TeamCity server machine
  • Installing the TeamCity server
  • Installing a TeamCity build agent

Depending on your team size, you can select the appropriate TeamCity installation size for evaluation or production usage:

  • Small – suitable for small teams, typically 3 users, 100 builds/day.
  • Medium – suitable for medium sized teams, typically 5 users, 300 builds/day.
  • Large – is intended for large teams, typically 20 users, 1000 builds/day.

To get started, perform the following steps:

  • Specify the resource group name
  • Enter a public SSH key for the TeamCity server machine
  • Enter a password for the database
  • Click Purchase.


Wait for about 10 minutes and you will be able to navigate to the TeamCity URL received from the template outputs:


After opening the TeamCity page, you’ll need to accept the license agreement and set the root account credentials. Now you are ready to use TeamCity.

Configure additional Azure integrations

Your TeamCity server comes with preinstalled plugins which can be used to configure tighter integration with Azure services:

How it works

During the deployment process, the service allocates a Linux virtual machine. The VM is powered by CoreOS with Docker support enabled. It exposes port 80 for the web access and 22 for maintenance in the network security group, so you’ll be able to connect to it via SSH.

Configuration and data files are stored on the disk attached to this VM. The TeamCity server and build agent are started from the official Docker images.

An instance of the Azure database for MySQL is created with the teamcitydb schema. Network security rules are set to make the database accessible from the TeamCity server machine.

In the virtual machine, the TeamCity operation is controlled by the following systemd services:

  • teamcity-server.service controls the lifecycle of TeamCity server
  • teamcity-agent.service controls the lifecycle of TeamCity build agent
  • teamcity-update.service handles the TeamCity updates.

TeamCity upgrade

When a TeamCity VM is created, it has a teamcity-version tag. By updating its value, you can control the current version of the TeamCity server and build agent. After the update, you need to restart the VM entirely or restart the server and agent services via the following commands:

> sudo systemctl restart teamcity-server.service
> sudo systemctl restart teamcity-agent.service

Note: The update could take a few minutes to pull the new version of TeamCity Docker images.

How to diagnose problems

You can connect to the VM and use default systemd tools to control TeamCity services. For instance, during the upgrade you can view the server log using the following command:

> sudo systemctl status teamcity-server.service


Please feel free to leave a comment to this post or file an issue in the TeamCity issue tracker.

Run TeamCity on Azure

Happy building in Azure Cloud!

Posted in Features, FYI, News & Events | 7 Comments

TeamCity 2017.2.2 is released

Here is another update for our latest version, TeamCity 2017.2.2.

This bugfix update addresses over 100 issues, all of them listed in the Release notes.

We recommend updating to this version as it contains several security and performance fixes.

Build 50909 uses the same data format as all the 2017.2.x releases and you can freely upgrade or downgrade if required.

Upgrading is especially easy if you are using TeamCity 2017.2.x – you can use automatic update. To upgrade from older versions, download TeamCity 2017.2.2 and install it on your server.

Your feedback is always welcome in our forum and tracker.

Happy building!

Posted in Features, Release | 2 Comments

Branch specific settings in TeamCity

We’re often asked how to run different build steps in different branches. In fact, this has already been possible in TeamCity for quite some time (since version 9.1), but it seems we need to do a better job explaining how to use this feature.

Let’s assume that you have a build configuration where building of feature branches is enabled.

First, enable Versioned settings for the project where this build configuration resides. TeamCity will ask for a VCS root where the settings are to be stored. For simplicity’s sake, let’s store the settings in the same VCS repository where other project files are located.

For the Versioned settings, make sure the option When build starts is set to the use settings from VCS value. TeamCity will then take the settings from a branch used by the build instead of the current settings.


Once versioned settings are enabled, TeamCity will commit the .teamcity directory with the current project settings to the default branch of the selected VCS root. To start customizing the settings in our feature branch, we need to merge the .teamcity directory from the default branch.

But before making any changes in the .teamcity directory in your feature branch, bear in mind that not all the changes there will be applied. For instance, if you add a new project or a build configuration, such changes will be ignored. This happens because TeamCity does not support different sets of projects and build configurations in feature branches.

Besides, there is a chicken and egg problem. Currently TeamCity loads settings from .teamcity while the build sits in the queue. But to load the settings from a repository, TeamCity needs to know this repository settings (VCS roots). Thus VCS roots are always taken from the current project settings.

The same story is with build triggers and snapshot dependencies. TeamCity needs triggers to decide when to place builds into the queue. And TeamCity needs snapshot dependencies to create a build chain (graph of builds) before the builds are going to the queue. Hence the changes in .teamcity affecting these settings are ignored too.

But there are plenty of other settings whose changes will affect the build behavior:

  • build number pattern
  • build steps
  • system properties and environment variables
  • requirements
  • build features (except Automatic merge and VCS labeling)
  • failure conditions
  • artifact publishing rules
  • artifact dependencies

By default, the settings are stored in the XML format. Since there is no publicly available documentation for this format, it is hard to guess how to change build steps correctly, or how to add a build feature. This is what a command line build step looks like in XML:

What can help here is seeing how TeamCity generates these settings. For instance, get a sandbox project on your TeamCity server for such experiments, and browse the audit page for settings difference after each change:


Another option is to use Kotlin DSL (see the Settings format option on the Versioned settings page). In this case, instead of .xml files, .kt files will be stored under the .teamcity folder.

A Kotlin DSL project can be opened in IntelliJ IDEA Community (free and open-source IDE from JetBrains). Kotlin DSL files look much more concise, and IDE auto-completion makes it much easier to work with them, especially in the recent TeamCity versions. This is what the same command line build step looks like in Kotlin DSL:

Some additional hints:

  • Since TeamCity 2017.2 you can browse Kotlin DSL documentation using the following URL: <TeamCity server URL>/app/dsl-documentation/index.html
  • If a build loads settings from the VCS repository, you should see something like this in the build log:
  • Actual settings used by the build are stored in the buildSettings.xml file under the hidden build artifacts. This file can be helpful if something does not work as expected.
  • If you’re using remote runs instead of feature branches, then all the same abilities are also available, provided that the .teamcity directory is  present in your repository and versioned settings are configured as described above.

Finally, one more thing to keep in mind. If changes under .teamcity in your feature branch were temporary, you should not forget to revert the settings during the merge with the default branch. For instance, if you removed some long running steps or switched off some tests for convenience.

Happy building!

Posted in Features, How-To's, Tips&Tricks | 1 Comment

Webinar recording and Q&A: What’s New in TeamCity 2017.2

The recording of our December 20 webinar, What’s New in TeamCity 2017.2, is now available on the JetBrains YouTube channel.

In this webinar, Wes Higbee goes over the new features of TeamCity 2017.2, the latest release of TeamCity. He demonstrates how the Docker-specific build runners and the new Docker support build features work; the built-in .NET CLI support for building the .NET Core projects; the new composite builds for aggregating build results; as well as the default and multiple templates.

Continue reading

Posted in Features, Webinar | Tagged | Leave a comment

TeamCity 2017.2.1 is released

Today we are releasing an update for the latest TeamCity version, TeamCity 2017.2.1.

This is a bugfix release fixing over 100 issues. For details please see the Release notes.

Upgrading is strongly recommended if you are using with TeamCity. As will deprecate a number of older cryptographic standards in February 2018, this change will affect agent-side checkout in all TeamCity versions before 2017.2.1 and server-side checkout in TeamCity versions prior to 9.0.2. If upgrading is not possible for you, see this workaround.

Other users are also advised to update to this version as it features a number of important fixes.

TeamCity 2017.2.1 has the same data format as all the 2017.2.x releases, which means that downgrading is possible if required.

If you are already using TeamCity 2017.2, use the Updates page for an automatic update.

Update 1721

To upgrade from older versions, download TeamCity 2017.2.1 and install it on your server.

We’ll appreciate your feedback: feel free to use our forum and tracker.

Happy building!

Posted in Bugfix, Release | Tagged | Leave a comment

What’s New in TeamCity 2017.2, December 20th Webinar

Join us Wednesday, December 20th, 16:00 – 17:00 CEST (10:00 AM – 11:00 AM Eastern) for our free live webinar, What’s New in TeamCity 2017.2 with Wes Higbee.

r (1)

In this webinar, Wes Higbee will go over some of the major features of the latest TeamCity release. He will demonstrate how the Docker-specific build runners and the new Docker support build features work; the built-in .NET CLI support for building the .NET Core projects; the new composite builds for aggregating build results; as well as the default and multiple templates.

Space is limited, so please register now. There will be an opportunity to ask questions during the webinar.

About the presenter:

Wes McClureWes Higbee is passionate about helping companies achieve remarkable results with technology and software. He’s had extensive experience developing software and working with teams to improve how software is developed to meet business objectives. Wes launched Full City Tech to leverage his expertise to help companies rapidly deliver high quality software to delight customers. He has a strong background in using Continuous Integration with TeamCity to bring quality to the table.
Posted in Features, Webinar | Leave a comment

TeamCity Support for AWS EC2 Container Service

TeamCity has been able to run build agents on AWS EC2 instances for ages.

In addition to this, the new plugin for TeamCity, Amazon ECS Support, allows running Docker-based build agents in an EC2 Container Service cluster.

The plugin is compatible with TeamCity 2017.1.x and later.
First, download the plugin and install it on the TeamCity server as usual.

Next, create a cloud profile in your project


Specify the AWS region and enter credentials to access AWS API and test your connection.


To make the plugin work, the provided credentials need the IAM role with the following permissions granted:

  • ecs:DescribeClusters
  • ecs:DescribeTaskDefinition
  • ecs:DescribeTasks
  • ecs:ListClusters
  • ecs:ListTaskDefinitions
  • ecs:ListTasks
  • ecs:RunTask
  • ecs:StopTask

Finally, create a cloud image which will correspond to the build agent configuration you need by specifying the task definition, cluster to run build agent tasks, and agent pool for your agents.


In contrast to using EC2 as a cloud provider (which allows using almost infinite computation resources with no additional configuration required), using the TeamCity ECS plugin in production requires the ECS cluster to be configured properly.
The following aspects should be considered:

  • Cluster capacity (cpu, disk)
  • Cluster scale in and scale out
  • Security
  • Build agent logs collecting
  • etc.

To make it a bit easier, we’ve published the Terraform template we are using on our side to set up the infrastructure for TeamCity TestDrive build agents.

Even when configured properly, the ECS cluster will likely be limited in terms of available resources. So, when TeamCity tries to start one more cloud build agent in the cluster, there might be no CPU or RAM available. You can specify the “Max cluster CPU reservation” percentile in the cloud image to make TeamCity stop running new cloud agents when the CPU reservation limit is reached. This requires the additional AIM role: cloudwatch:GetMetricStatistics.

Feel free to download the plugin and try it on your server, or give the plugin a test drive in the cloud. Please share your feedback with us!

Happy building with TeamCity!

Posted in Features, FYI | Leave a comment

TeamCity 2017.2 is released!

We are thrilled to announce that TeamCity 2017.2 has been released today!

First of all, we’d like to thank all our users who helped us make the product better:
it really means a lot to know that you are willing to take time and report your success or problems, that you venture to try out our pre-release versions, that you are as excited about the new release as we are. We, the TeamCity team, really appreciate this.


Now let’s talk about the TeamCity licensing news: the TeamCity Professional license increased the number of build configurations, and instead of the 20 you are now entitled to 100 build configurations with our free version!

Why we decided to increase it? We believe that as projects and teams grow, they can get more and more benefit from TeamCity and take advantage of the features which are visible on larger-scale installations. For instance, with a limit of 20 build configurations, there is a little chance you’ll be able to put to full use such features as snapshot dependencies, Kotlin DSL, templates or even projects hierarchy. Not to mention that the modern trend towards microservices architectures also requires a larger number of different build configurations.

Next, this release is packed with new features; most of them have been already announced in our early access program for TeamCity 2017.2, so here is the summary:

  • The built-in TeamСity-Docker integration is now available for agents on Mac, Linux, and Windows. The integration provides a number of features to facilitate working with Docker under TeamCity.
  • Out-of-the-box support for .NET CLI: you can now build, test, and deploy .NET Core projects
  • Aggregated results from several build configurations can be now obtained using Composite builds
  • Deployment build configurations make it easier to deploy and redeploy the results of the builds such configurations depend on
  • Easy TeamCity server upgrade with the new automatic update option
  • and much more, including the improved UI.

The detailed description is available in the What’s New.

Download the brand new TeamCity 2017.2 and check the Upgrade Notes before you install the new version!

Don’t have the time and resources to set up a test server? Test drive the latest version of TeamCity in the cloud.

We always carefully consider your feedback and you are most welcome to use our forum or tracker.

Happy developing and building!

Posted in Features, News & Events, Release | 7 Comments

TeamCity 2017.2 RC is here

Greetings, everyone!

We are pleased to announce the release candidate for TeamCity 2017.2. We’ve been mostly focusing on polishing the new features and tackling issues, so this is essentially a bugfix release.

Build #50444 addresses over 100 problems, listed in our release notes.

TeamCity 2017.2 RC is still work in progress, and it changes the TeamCity data format so be sure to install it on a trial server as downgrading is not supported. You can try the new automatic update feature or download the TeamCity 2017.2 RC build and install it as usual.

This may be your last chance to report issues on this preview version, as we are planning to release TeamCity 2017.2 next week.

Your feedback will be greatly appreciated: feel free to post it here in comments, in our forum or tracker.

Follow us for the latest news on the upcoming release.

Happy developing and building!
The TeamCity Team

Posted in Bugfix, EAP | Leave a comment