What's New in TeamCity 7.0
Agent Pools
If you have tens of agents shared between several projects you probably suffer from the following issues:
there are no agents available for your project because all of them are used by builds from other projects;
you cannot easily change software on agents because it can affect not only your builds but builds from other projects too;
it is not easy to predict whether builds from your project will gain some benefits if more agents are added to the system.
To solve some of these issues you could assign agents and build configurations one to one, but this would be a tedious and absolutely not scalable approach due to low granularity level.
TeamCity 7.0 addresses these problems in a more convenient way. You can distribute your agents among several agent pools and assign each project to a pool. A project can be assigned to more than one agent pool, but agent can reside in a single pool only. If a project is assigned to a pool, its builds can run on agents of this pool only. They won't affect other pools and other projects. There is also a so-called Default pool, that cannot be removed and serves as a place for all agents and projects not assigned directly to other pools.
Ability to perform one-to-one assignment between agents and build configurations is still there and provides a fine grained control within a pool.
Agent pools can be configured on the "Pools" tab under "Agents": 
When you have agent pools configured you can easily monitor pools load on the agents matrix page: 
If your project belongs to a single pool and there are no other projects in the pool, it is convenient to watch build queue for this pool only. This feature is also available: 
Agent pools also affect compatible agents pages: 
Typed build parameters
When defining a build parameter either on build configuration or project level, you can specify a type of a control for this parameter. For example, if a parameter has two values - true or false, it is natural to show it as checkbox. Currently this only affects custom build dialog.
Besides control type, you can also specify some standard properties for each parameter, such as:
label - custom label to display for this parameter in custom build dialog
description - text to be shown under the control in custom build dialog
display type: normal, hidden or prompt. If hidden is specified, parameter will not be shown, but will be sent to a build; if prompt is specified, TeamCity will always require a review of parameter value, even when you trigger a build by simply clicking the "Run" button; if normal is selected, parameter will be shown as usual
Supported control types are:
text field
checkbox
select
password
If password parameter is used, TeamCity will do its best to hide the actual value of password parameter. You won't see the password in build logs, TeamCity web interface, or IDE plugins. It will be stored in configuration files in scrambled form. Note that as TeamCity performs global replacement of the password in build log, you have to choose relatively strong passwords - those that are unlikely to appear in the build log as a sequence of characters.
Parameter specification (a part of parameter which defines how to show it) cannot be overwritten if a parameter is inherited from a template or project.
Build Chains
Build Chain (a collection of builds combined by snapshot dependency) is a TeamCity approach to setting up something similar to a pipeline. They first appeared in What's New in TeamCity 4.0 (released in November 2008) and have seen many improvements since then.
Some important notes:
each build chain is a directed acyclic graph, i.e. build chain cannot have cycles
all builds in a chain will have either the same revision, or, in case of several VCS roots, revisions corresponding to changes made at the same moment of time
if a build depends on another one by a snapshot dependency it means the build cannot start until the dependency finishes
several build chains can have common builds. For example, in order to reduce build chain execution time, TeamCity can decide to merge some build chains, if the results of a previous chain can be reused in a subsequent chain
Given the complexity of build chains, it is not easy to represent them visually. But we decided to make a first step in this direction in TeamCity 7.0. We added a new "Build Chains" tab on project and build configuration pages. The tab shows Build Chain containing builds from the project or build configuration correspondingly. The tab looks like this:
For each build chain you can see all builds that constitute a build chain as well as their status: not triggered, in queue, running or finished. Clicking a build in a chain will highlight this build and all its direct dependencies (both upstream and downstream). Since there can be several build chain in a single project, there is an ability to filter them.
But this page not just visualizes the chain, but also provides some abilities you can't easily reproduce using earlier versions of TeamCity. For example, the following chain is in not triggered state:
This means some of the builds were not started yet. By pressing the "Run" button you can continue the chain, i.e a new build will be started on the chain revisions and associated with builds from this chain. An 
Besides build chains presentation we've made some other important improvements.
Changes from dependencies
For a build configuration with snapshot dependencies you can enable showing of changes from these dependencies transitively. The setting is available on the "Version Control Settings" step of the build configuration administration pages: 
Enabling of this setting affects pending changes of build configuration, builds changes in builds history, change log and issue log. Changes from dependencies are marked with 
. For example: 
With this setting enabled, "Schedule Trigger" with a "Trigger build only if there are pending changes" option will consider changes from dependencies too.
Finish build trigger
Finish build trigger has become a little bit smarter too. If a build configuration is set up with a "Finish build trigger" and has snapshot dependencies to selected build configuration, the trigger will run the build on the same revisions and will attach the build to the chain. Thus you can have automated promotion of builds in a chain.
Build failure conditions
Newly added build configuration editing step called "Build Failure Conditions" accumulates all settings that define when the build should be marked as failed. Standard options like "fail build if at least one test failed" were moved from the "General Settings" step to this page.
Besides the standard options, you can find two new build failure conditions:
Fail build on metric change
Fail build on specific text in build log
Fail build on metric change
With the help of this build failure condition you can track whether a specific statistical value changes within certain limits, and if it exceeds these limits, a build will be marked as failed. For example, you can require that the size of artifacts in your build is never less than 1Mb. Or that line coverage is always more than 80%.
There are cases when a build must be marked as failed if some statistical value differs significantly from a previous build (or from some reference build). For example, you may want to fail a build if the number of covered lines drops significantly compared to the previous build. Or, if compared to a build marked with some tag (reference build), the number of duplicate code fragments increased by more than a specified threshold. This is all possible with "fail build on metric change" condition.
Fail build on specific text in build log
The name of this failure condition speaks for itself. If text in the build log matches some regular expression, a build will be marked as failed. You can also define a failure message that will be shown in build status text and in the build log.
Incremental builds
Maven, Gradle and IntelliJ IDEA Project build runners now support incremental building (for IDEA it's limited to running tests). 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 the corresponding production modules.
Now if a build starts with a change in module A-prod, TeamCity agent will run the tests in both modules (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 the tests from B-test module.
In general, the more independent your modules are, the better. Modularity is a common good practice of software design, and now you can get another benefit from such approach: faster builds.
To enable this functionality for Gradle or IntelliJ IDEA project runners, simply turn on "Run affected tests only (dependency based)" checkbox. For Maven, you should enable "Build only modules affected by changes" checkbox.
Note that since IntelliJ IDEA project runner operates with run configurations instead of individual tests, when the "Run affected tests only (dependency based)" checkbox is enabled the runner will execute run configurations depending on affected modules only.
Read more about incremental building feature Maven.
REST API
A long-standing feature request to allow build configuration editing via REST API Plugin has finally been implemented. Now you can get complete settings of a build configuration or template via REST and can also change them. You can also create and delete build configurations, projects and VCS roots.
Here is an example of how to get build configuration steps:
curl -v --request GET http://user:pass@localhost:8111/app/rest/buildTypes/id:bt2/steps
Save individual step details to a file:
curl -v --request GET http://user:pass@localhost:8111/app/rest/buildTypes/id:bt2/steps/RUNNER_1 -o response.xml
And create a new step (a copy of the saved one):
curl -v --request POST http://user:pass@localhost:8111/app/rest/buildTypes/id:bt2/steps --data-binary @response.xml --header "Content-Type: application/xml"
REST API has had "/app/rest/application.wadl" since the very beginning, but it has now got an XML schema attached (see <ns2:grammars><ns2:include href="application.wadl/xsd1.xsd"> element and try application.wadl/xsd1.xsd request) and will hopefully get some more inline comments soon.
If you are already using the REST API please note that the protocol version has Upgrade Notes.
Additionally with TeamCity 7.0 REST API you can:
change project level parameters
authorize and disable agents and get parameters reported by an agent
change user properties (e.g. VCS usernames)
pause build configurations
get content of a file from VCS using revisions of a build
REST API Plugin
Integrations
ReSharper Inspections
New Inspections runner for .NET is now available. Internally this runner uses parts of JetBrains ReSharper, so basically it means that ReSharper Code Analysis is now available on the server side too. This runner helps you detect errors and problems in C#, XAML, XML, and ASP.NET code.
Key benefit of .NET Inspections runner is that it can use ReSharper 6.1 settings profiles. So you can easily tune the runner to match your own code style.
Inspection results are shown in the standard TeamCity interface.
Also, links to on-line inspections wiki are available for some inspection types.
Which should help you learn how the code can be improved.
Known issues
We still have a few unresolved technical problems which could lead to incorrect inspection results. All these issues will be targeted in the future releases. Among them:
in order to have adequate inspections execution results it might be necessary to build your solution before running analysis. This pre-step is especially relevant when you use (implicitly or explicitly) code generation in your project, see TW-19220.
currently you could face with problems if you use MSBuild properties in your project files, see TW-19678.
NuGet
NuGet is a relatively new tool in .NET world. In brief, it aims at solving dependency management issues experienced by many .NET projects. You can read more about NuGet on NuGet.org.
TeamCity offers several NuGet-related features:
keep an up-to-date NuGet version on all agents and on TeamCity server
new build runners
NuGet Installer - installs and updates NuGet packages on agents for subsequent build steps
NuGet Pack - creates NuGet package from a spec file
NuGet Publish - publishes NuGet package to a given NuGet feed
TeamCity can act as a NuGet feed server
with the help of NuGet Dependency trigger TeamCity can watch for changes in a specified NuGet package
TeamCity as NuGet feed server
If you publish NuGet packages as TeamCity artifacts you can enable NuGet Server feature on Administration -> NuGet Settings page.
In this case TeamCity will provide its own NuGet feed with all published packages. You can use this feed in Visual Studio to get notifications when packages are updated on the server.
Maven
Maven settings
Maven settings files often contain shared settings for all Maven-based projects within a company. Until TeamCity 7.0 it was hard to define them in TeamCity as you had to store these settings in version control (or on a network share), and remember to use command line options to specify a path to them. Now you can upload your settings files to TeamCity:
And then use them in Maven-specific build steps:
Bundled Maven 3
Maven 3 is now bundled with TeamCity in addition to Maven 2. You can select which Maven version to use in Maven build step.
Own local artifacts repository
In TeamCity 7.0 you can also isolate a specific build configuration artifacts repository from other local repositories. This can be done in one click on build step page. 
Subversion 1.7 support
TeamCity 7.0 is compatible with Subversion 1.7:
TeamCity can communicate with Subversion 1.7 servers
TeamCity can create and update a 1.7 working copy on the agent in case of agent side checkout
Visual Studio Add-in supports Subversion 1.7 for Remote Run and Pre-tested commit
TeamCity Eclipse plugin supports Subversion 1.7 for Remote Run and Pre-tested commit
Since IntelliJ IDEA does not yet support SVN 1.7, TeamCity plugin for IntelliJ IDEA also won't work with 1.7.
User interface & usability improvements
Several user interface improvements have been made in TeamCity 7.0.
Branch graphs in change log
Project and build configuration change log now shows branch graphs for distributed version control systems like Git or Mercurial.
There will be as many graphs as the number of VCS roots you have in your project or build configuration. When clicking a node in the graph, corresponding part of the change log is highlighted.
Also in places where information about committer is shown, TeamCity will try to show the TeamCity user name instead of the version control user name.
New administration area
We restructured the TeamCity administration area to make it more logical, scalable and to bring some often used pages up front.
Current problems & investigations
If you are assigned as investigator for some problem, a counter near your name will be updated: 
Click on the counter will bring you to the "My Investigations" page: 
Note that for each failed test on this page you can get a bunch of information instantly, without a need to leave the page. For example, you can see all build configurations in which this test is currently failing. You can also see a current stacktrace and information about a build where the test is currently failing. You can also see information about the first failure of this test, again with stacktrace and build.
Similar improvements were also applied to project's "Current Problems", "Investigations", and "My Changes" pages.
We also decided to get rid of Bulk investigation mode introduced in TeamCity 6.5. Instead, we always show checkboxes for investigation assignment or mute: 
Build log tree view
Build log tree view has got several improvements: 
You can filter build log by message priority, expand all nodes in the whole build log, or within a single node only. Tree view is now available for running builds as well (it was not so before TeamCity 7.0).
Artifacts browsing
Browsing inside artifact archives from within the TeamCity UI has become extremely easy. Supported archive types are: .zip, .jar, .war, .ear, .tar, .tar.gz, .apk, .sit. Browsing archives inside archives is supported too.
If you want to download a file from an archive in a build script, use this URL syntax:
http://<server url>/repository/download/<build conf id>/<build>/<archive>!<path in archive>
See more on this in our Patterns For Accessing Build Artifacts
We also removed the "Base Path" field in project report tabs, as its only purpose was to handle paths inside archives. 
Small, but noteworthy changes
Space required for a single build configuration on overview page has been reduced to fit more data:
Quick navigation between build configurations of a current project is accessible from breadcrumbs in user and administration area:
While staying on a build log, it is sometimes necessary to see the build summary quickly - now you can easily access it from each build tab:
Layout and styles in most of the dialogs have been improved:
Before
After
Restyled diff view with a new feature to copy file content to clipboard:
Run button has become much more usable and good looking:
My Changes page shows estimates for queued builds on Builds tab.
Newly created projects are not added to the overview automatically (yellow prompt is shown instead).
Text fields that accept command line arguments, as well as text fields used for parameter values now auto-expand as you type and support multiline input.
All projects popup now supports filtering by build configuration name, in addition to filtering by project.
Changes by current user are highlighted in the changes popup, also too long comments are clipped.
When TeamCity is able to determine agent operating system, a corresponding icon is shown near the agent name.
Java coverage report presentation improved.
A more detailed presentation of the test details (test history) page.
Other improvements
Performance monitor
New "Performance Monitor" build feature can help you to track hardware resources used by your build. Upon build finish you'll see an additional tab called "PerfMon" with results like: 
Here you can see that build produced zero CPU and Disk usage during a period of several minutes, starting at 15:00. Most likely there was some code spending a lot of time in wait state. By clicking a point in the chart, a part of build log for this period of time will be shown.
Performance monitor spawns a separate process which gathers hardware statistics. Statistics is gathered for the whole agent machine, so it won't work properly if you have more than one agent installed on the same machine and these agents run builds in parallel. CPU, Disk and Memory usage are all percentages of what is available on the agent. Sometimes you can see that only 50% of CPU is being used by a build. This usually means that a build does not utilize all CPU cores of the agent machine. Platforms supported by PerfMon are Windows, Solaris, Linux and MacOS X.
Per-check-in builds
VCS trigger now supports two new options:
Trigger one build per each checkin
Trigger one build per group of checkins from the same user
With the first option enabled, each new check-in will result in a build added to the queue and associated with this check-in (i.e. build won't include other changes).
If the second option is enabled, and there are several pending changes, TeamCity will group them by user and will start builds having single user changes only.
Clean sources
Option to run a build with clean sources was added to custom build dialog and to "Schedule Trigger".
Build execution timeout
Global, per-server build execution timeout can be defined for all of the builds. If build configuration level timeout is specified, it will override the global setting.
Diagnostics page
Diagnostics page now shows current memory usage and JVM arguments. In case of memory issues (high memory usage for a prolonged period of time), a warning will be shown in TeamCity web interface. If you customized some TeamCity internal properties, you can see them on Diagnostics page too.
Artifact dependencies
Artifact dependencies now support syntax similar to checkout rules, i.e. you can define a set of new line delimited rules: [+:|-:]SourcePath[!ArchivePath][=>DestinationPath]
Enable / disable parts of build configuration
Settings like build triggers, build steps, build features and build failure conditions can be disabled in build configuration or template. Disabled settings will stay inactive until they are enabled again. If you disable a build step, this build step will not be executed on the agent. Inherited settings can be disabled too, for example, if a build step is inherited from a template, you can disable it in the build configuration and define some other step instead of inherited one.
Agent hardware information
Plugin providing information about agent hardware was available for quite some time (see http://youtrack.jetbrains.net/issue/TW-4857). We decided that it is useful enough to bundle it with TeamCity distribution. The plugin provides the following parameters:
teamcity.agent.hardware.memorySizeMb- agent physical memoryteamcity.agent.hardware.cpuCount- number of CPUs (cores) on agentteamcity.agent.work.dir.freeSpaceMb- available free space in Mb on a disk where agent work directory resides, updated on every build finish
Artifacts cleanup
Ant-like file patterns can be specified for artifacts cleanup rules, in the form: [+:|-:]Ant_like_pattern
VCS username
VCS username, default for all of the types of version controls, can be specified on user profile.
Viewing personal builds of other users
To see personal builds of other users enable "Show all personal builds" setting on your profile.
Ruby environment configurator
First of all, the long standing bug with non-functional Ruby environment configurator (http://youtrack.jetbrains.net/issue/TW-14803) has now been fixed.
Also, agents now detect the presence of RVM and report rvm_path environment variable with the path to RVM. This way you can easily set up your build configurations to run on agents where RVM is installed. Enabling of Ruby environment configurator will add this requirement automatically.
Previous Releases
What's New in TeamCity 6.5