What's New in TeamCity 10.0
Server and Agent Requirements
Minimum server Java
Starting from TeamCity 10.0, the TeamCity server requires the Java 8 JRE/JDK (included in the Windows .exe distribution).
Recommended agent Java
Starting from the next TeamCity version, the minimum requirement for the Java on the agent will be Java 1.8 (included in the Windows .exe distribution). If an earlier version is detected, TeamCity displays a health item suggesting that you now consider upgrading the agent Java.
DSL for TeamCity Project Configuration
In this release we introduce a new way to create projects and build configurations - the ability to define settings programmatically using DSL based on the Kotlin language. All there is to do is enable version settings for your project, select kotlin as the format and commit the settings to your version control. TeamCity will generate necessary Kotlin files for this project and check them in to the specified repository under the .teamcity directory.
Two-Node Server Configuration
A TeamCity server can operate in two modes now: main TeamCity server (default mode) and running builds data processor, displayed as Running Builds Node in the UI.
In a two-node installation the server started as the running builds node handles all of the data produced by running builds (build logs, artifacts, statistic values), pre-processes it and stores it in the database and on the disk. The primary purpose of this node is to provide the scalability option for really large installations running several hundreds of agents on a single server now and planning on expanding their installation in the future.
The main TeamCity server handles all other tasks: user interface, VCS-related activity, management of agents, etc.
Cross-server projects popup
The new projects popup allows connecting multiple TeamCity servers and provides search and instant access across all projects and build configurations on the connected servers.
Simplified Project Setup with GitHub and Bitbucket Cloud
If you have an organization account in GitHub, GitHub Enterprise or Bitbucket Cloud , you can connect TeamCity to these source code hosting services making it easier for the organization users to create new projects, Git or Mercurial VCS roots, GitHub or Bitbucket issue tracker, which are now supported out of the box.
For example, your organization administrator can create a parent project and configure connection to GitHub there once, and the users will see a list of GitHub repositories URLs in the TeamCity Web UI, which will make setting up subprojects a lot simpler for them.
TFS
TFS support in TeamCity 10.0 has been significantly enhanced with the following features:
Versioned project settings in TFS
Now TeamCity allows storing the project configuration settings in a TFVC repository. The user specified in the TeamCity TFS root must have permissions to check in changes to the repository.
Cross-platform TFS integration
Starting from this version, TeamCity supports cross-platform TFS integration, which works on Linux, Mac OS X, and Windows platforms. Without installing additional software, TeamCity servers and build agents can interact with Team Foundation Servers (from 2010 to 2015) and Visual Studio Team Services.
Team Foundation Work Items Tracking
Since TeamCity 10, Team Foundation Work Items tracking is integrated with TeamCity. The integration supports TFS 2010+ and Visual Studio Team Services.
If you used Visual Studio Online Work Items plugin prior to TeamCity 10.0, it can be safely removed: after upgrade, TeamCity will detect the existing issue tracker connections of this plugin and convert them into TFS Work Items.
Perforce
Feature branches support for Perforce streams
For VCS roots where Perforce stream is specified, you can now enable support for feature branches. When feature branches support is are enabled, TeamCity will monitor all streams matched by branch specification, and youll get the picture similar to the with Git and Mercurial.
Support for Perforce jobs
If you use Perforce jobs to label your commits, the changes associated with jobs are now marked with a "wrench" icon 
Other VCS-related features
Default auto-checkout on agent
The default setting for the VCS checkout mode is changed: now TeamCity will prefer to check out the sources on the agent before the build. If the agent-side checkout is not possible, TeamCity will display a corresponding health report item and will use the server-side checkout.
TeamCity falls back to the server-side checkout in the following cases:
No Git or Mercurial client is found on on the agent
The Git or Mercurial client is present on the agent, but is of the wrong version
The agent has no access to the repository
If a Perforce client cannot be found on the agent using the same rules as while performing actual checkout or if stream depot is used and the checkout rules are complex (other than . => A )
It only applies to newly created build configurations; all the existing one will work as configured before. Note that Git LFS is now supported for checkout on agent.
Improved Support for Commit Hooks
Our documentation now details commit hooks configuration for TeamCity in various VCS repositories.
If you have commit hooks configured, TeamCity will use a combined approach to check for changes in the VCS: traditional polling and commit hooks. Now if a commit hook initiates the process of checking for changes for some VCS root in TeamCity, TeamCity will automatically increase checking for changes interval for this VCS root. But if TeamCity detects a change in this VCS root during regular polling, then the checking for changes interval will be reset to the initial value specified by the user when the VCS root was created. This is done for the case when a commit hook stopped working for some reason.
Cloud support
There is a significant number of improvements in TeamCity agent cloud support:
The Run Custom Build dialog and the IDE's remote run customization dialogs allow you to run a build on any agent of a certain cloud image (TeamCity will also attempt start a new one, if no available cloud agents of that type exist)
When configuring a cloud image, you can now select an agent pool for the newly created cloud agents. Previously all of them were placed in the default pool.
VMware vSphere
When configuring a cloud profile, you can now limit a number of instances across all images and set the limit per image.
Unique hostnames for Windows and Linux vSphere cloud agents can be specified now when adding an image using the Customization spec option.
Custom names for agent images are supported now.
TeamCity detects cloud profile changes immediately, and forces shutdown of the agents started prior to these changes once the agents finish the current build.
Amazon EC2
Amazon EC2 images are now configured via a more convenient web interface, similar to the one in VMware vSphere plugin
It is now possible to run a custom script on the launch of an Amazon EC2 instance (applicable to instances cloned from AMI's only). The Amazon website details the script format for Linuxand Windows.
Custom tags can now be applied to EC2 cloud agent instances. Amazon tag restrictions need to be considered.
EBS optimization is turned on by default for all instance types supporting it.
If a user removes an image from a profile, a warning is displayed that the instances already started by TeamCity will not be automatically stopped.
Flaky Tests Detection
TeamCity now supports flaky tests detection. A flaky test is a test that is unstable (can exhibit both a passing and a failing result) with the same code. Flaky test detection is based on several heuristics.
The dedicated project tab, Flaky Tests, displays such tests along with the total number of test failures, the flip rate for the given test and reasons for qualifying the test as a flaky one. You can also see if the test is flaky when viewing the expanded stacktrace for a failed test on the build results page, where such tests are marked with a special icon 
.
When you assign investigations for a flaky test (or multiple tests), the resolution method is automatically set to 'Manual'.
Note that is branches are configured for a VCS Root, flaky tests are detected for the default branch only.
Project Configuration Export
It is now possible to export configuration filesfor a project with its children as a zip archive to later import it to a different TeamCity server. The Project Settings | Settings Export page allows exporting the config files for a project and its subprojects, as well as external dependencies, i.e. build configurations used in snapshot dependencies, templates used as well as vcs roots and all main settings (ssh keys, issue trackers, oauth connections etc...) defined in the parent project.
The settings archive also contains a report.log file detailing the reasons for exporting external entities.
Email Verification
TeamCity administrators can enable / disable email verification (off by default) on the Administration | Authentication page.
If email verification is enabled on the TeamCity server, the Email address field in the user account registration form becomes mandatory. When an address is added / modified, the users will be asked to verify it. If the email address is not verified, TeamCity will display a notification on the General tab of the user account settings. Verified email addresses will be marked with a green check on the Administration | Users page.
During the project import TeamCity will take verified emails into account. If there are two users with different usernames, but the same verified email, TeamCity will provide a possibility to merge these users.
Exclude Patterns for Artifact Paths
It is now possible to specify newline- or comma-separated paths in the form of -:source [ => target] to exclude files or directories from publishing as build artifacts.
Rules are grouped by the right part and are applied in the order of appearance, e.g.
will tell TeamCity to publish all files except forfolder1 into the target_directory.
Agents Management
Agent limit in pools
When creating an agent pool, it is now possible to set a maximum number of agents in a pool to prevent the situation when all the available build agent licenses are used up by a single pool.
If the maximum number of agents is reached, TeamСity will not allow adding any new agents to this pool. This includes moving agents from other pools and automatic authorization of cloud agents. New cloud agents will not start if the target pool is full. The limit is not applicable for the Default Pool.
Project-bound agent management permissions
In this release we introduce project-level permissions to perform a tasks like authorize or disable for an agent.
A user can perform a task controlled by one of these permissions on all the agents belonging to some pool provided this permission is granted to the user in all the projects associated with this pool.
The Authorize project agent permission and the recently introduced "maximum number of agents" setting for an agent pool enable you to set up the system in a way which allows project administrators to run new agents and authorize/add them to their pools without involving the global server administrator.
Distributing Tools to Agents
In this release we unified all of the tasks to distribute tools to agents under the single interface. Now, you can manage NuGet versions, install recent version of ReSharper command line tools, or upload an arbitrary tool in a zip archive - all from the same Administration | Tools page.
New Server Health Reports
New server health reports have been added:
agents not running the recommended Java: this report shows all of the agents running under Java version < 1.8
report for large server side patches with a recommendation to switch to the agent-side checkout
inefficient artifacts publishing: TeamCity detects a build publishing many small artifact files and suggests publishing them as a single zip archive
if a project or build configuration has secured parameters and is configured to build GitHub pull requests, this report will raise a warning, because malicious code submitted via a pull request can obtain these secured parameters
health report suggesting configuring a GitHub / Bitbucket issue tracker if a VCS root points to GitHub / Bitbucket.
Web UI
The TeamCity Web UI has been improved in a number of ways:
New Projects popup - the new popup provides better performance and allows browsing projects and build configurations on multiple servers.
New Create project / Create build configuration buttons have a drop-down now and you can select whether you want to create a project manually, from a URL, or using the popular version control systems GitHub.com and Bitbucket.
Performance improvements - calculation of changes, artifacts and some other build-related data has been moved into background, which resulted in faster loading of pages.
Console view in Build Log - the dark theme for the build log can now be enabled by selecting the appropriate check-box.
Refreshed icons in web UI - Build status icons, icons for projects and build configurations, icons for investigations have been changed to a more modern look. Some light face-lifting has been done to parts of the web UI.
The Agent pools page has been reworked to provide better performance in case of a large number of pools and agents
The branch filter field in build triggers, build features, notification rules, artifact dependencies, and other places now has an icon showing available branches to simplify defining filter rules.
Project / Build Configuration Settings Improvements
Artifact Dependencies and Agent Requirements can now be disabled to preserve them in settings without affecting the build (similarly to build features, triggers and build steps).
Inherited artifact dependencies in build configurations can now be redefined similarly to agent requirements and other settings
Multiple agent requirements for a single parameter can be added now. The conditions are treated as 'and' to determine compatible agents.
Disabled editing of project or build configuration settings via the web UI is added if you generate the settings via code (e.g. via REST API) and want to forbid changing the settings via the UI.
Performance of the project and build configuration settings editing has been greatly improved especially for large installations with thousands of projects
Notifications enhancements
Previously it was not possible to configure notifications to watch for builds with your changes in specified build configurations. In this version we reworked how notifications are configured in an attempt to make them more flexible and more obvious:
Bundled Plugins
TeamCity 10.0 now includes the following plugins so you no longer need to install them separately. The plugins features have been improved:
Deployer plugin - open source plugin, containing a number of additional runners to upload files to FTP, SSH and deploy wars into Apache Tomcat servlet container
Commit Status Publisher - open source plugin providing ability to submit status of a build into different VCS hosting services: JetBrains Upsource, GitHub and GitHub Enterprise, GitLab, Bitbucket Cloud and Bitbucket Server, and Gerrit
VMware vSphere plugin - open source plugin providing support for cloud agents on VMware vSphere
Bundled tools updates
Ant runner: the bundled Ant distribution has been upgraded from 1.9.6 to 1.9.7
.NET dotCover coverage: the bundled dotCover is updated to 2016.1
ReSharper command line tools: the bundled R# CLT is updated to 2016.1
Java inspections and duplicates: the bundled IntelliJ IDEA is updated to 2016.2
REST API
The REST API has been significantly improved and now enables you to:
get and updateTeamCity license keys
get help on locator usage by sending a request with the
$helpstring as the locatorget the build status icon for several builds, using the
<teamcity URL:port>/httpAuth/app/rest/builds/aggregated/<build locator>request andstrobbuild locator dimension.fetch hanging builds
find builds with several tags
filter builds based on the time specified by the build locator
set a comment when disabling a build agent
list the agents compatible with a build configuration and filter agents by compatible build configurations (excluding non-started cloud agents (images) which are not yet exposed via the REST API)
trigger a build on an agent pool
get the projects and build configurations as well as their order on the Overview page as configured by the specified user
change the order of projects and build configurations
disable/enable artifact dependencies and agent requirements
get all runs (the number of test invocations) for a test
get test mutes affecting a specific build configuration
list users by email, group and user property
get the indication of the build configuration settings if it was inherited from a template or a project
edit project features via
.../app/rest/projects/XXX/projectFeaturesrequestget pending changes for a build configuration
get information about a changed file action: added, edited, removed, copied or unchanged reported via the
changeTypeattribute for the files listed by<teamcity URL:port>/httpAuth/app/rest/changes/id:<changeid>schedule checking for changes for a set of VCS roots
Other Improvements
Now configuration of issue trackers, versioned settings, custom charts, shared resources and third-party report tabs was moved from < TeamCity Data Directory>/config/projects/< ProjectID>/pluginData/plugin-settings.xml to < TeamCity Data Directory>/config/projects/< ProjectID>/project-config.xml file. The file now has the <project-extensions> element which contains all of the above-mentioned project features.
The Administration | Projects Import page now allows uploading the backup archive for import.
TeamCity search has been improved - you can now find builds with the specified build problem.
It is possible to make a parameter read-only via the parameter specification, such a parameter cannot be changed via the custom build dialog
Maven-related operations performed on the server-side are now moved to a separate process
It is possible to pause all or selected build configurations for a project.
Starting from this release TeamCity uses unidirectional agent-to-server connection via the polling protocol by default. If for some reason the polling protocol cannot be used, TeamCity switches to the fallback bidirectional communication via xml-rpc.
When Perforce VCS mapping is edited, clean checkout is no longer forced. Note, however, that clean checkout will be triggered for all Perforce vcs roots after upgrade to TeamCity 10.
The new option in Subversion VCS root, Enable non-trusted SSL certificate, allows TeamCity to connect to SVN servers without properly signed SSL certificate.