Agent pools

Agent pools provide a way to break a single, common pool of agents on separate parts - pools. Each pool has agents and projects assigned. Agent belongs to one agent pool only, but projects can be assigned to several pools.
Builds of a project assigned to a pool can run on the agents from this pool only.

Build failure conditions

"Fail build if" settings of build configuration were moved to a separate step. Also there were two useful additions:

Dependency based test run

Maven, Gradle and IntelliJ IDEA Project build runners now support dependency based run of tests. For example, say your project has these modules: A-prod, A-test, B-prod, B-test.
Modules with -prod suffix contain production code, while modules with -test suffix contain tests for corresponding production modules. Module B-prod depends on module A-prod.
Module A-test depends on module A-prod. Module B-test depends on module B-prod and A-prod.

Now if a build starts with a change in module A-prod TeamCity agent will run tests in both modules A-test and B-test (because B-test depends on A-prod and can be affected by the change).
However, if a change was made in B-prod only, TeamCity will only run tests from B-test module.

So, in general, the more independent your modules - the better. It's a recommended way to design a software, but now you can get real benefit from such approach: faster builds.

NuGet support

Build performance monitor

Each new build now has additional tab, called PerfMon. On this tab you can see CPU/Disk and Memory usages on the agent during the build. You can also click on a point in the chart and corresponding part of the build log will be shown.

For example, from the picture below it is clear that at some point CPU and Disk usage is very low. This lasts for about 20 minutes. Seems like the tests executing at this time need some investigation, probably, most of the time they are blocked on some lock or wait for some event:

Several UI improvements