What's New in TeamCity 8.1
Simplified setup
Create project from URL
If you have a URL to a project in a version control system, you can easily create a project in TeamCity using this URL only. TeamCity will detect the type of your version control system, create a VCS root for you in the new project, verify connection to the repository, create a Build Configuration, and propose pre-configured Configuring Build Steps to run your build. It was easy to create a new project before, but now it's really a no-brainer.
TeamCity auto-detection mechanism supports most popular version control systems and a wide range of build tools and technologies, including: Maven, Gradle, Ant, NAnt, MSBuild, Visual Studio solution, Powershell, Xcode, Rake, IntelliJ IDEA, as well as various command line scripts.
Similarly to creating a project from URL, you can also create a VCS root from a repository URL only:
Besides that, if while creating a new VCS root TeamCity detects a duplicated VCS root, it will show a warning and suggest using the existing VCS root:
Suggested settings
If there are some configuration changes that could improve your build configuration setup, TeamCity will suggest them via a new suggested settings icon:
Advanced and default settings
TeamCity has a lot of options and configuration tweaks. As usual, most of them are useful in a minority of cases, but they often distract new users and make the product look more complicated than it actually is. To address this problem, we introduced advanced settings. All complicated options and the settings used not so often are now marked as advanced and are hidden by default (unless their values were changed, in which case the modified advanced settings are automatically shown).
The settings of a build configuration whose values have been changed from defaults are now marked with an orange border. If a build configuration is inherited from a template, the template settings play the role of the defaults; thus, all settings redefined in a build configuration can be easily located.
Easier settings override in inherited build configurations
For a build configuration inherited from a Build Configuration Template, the settings like the maximum number of running builds, execution timeout, build failure conditions and some others could not be overridden even with the help of parameter references. In TeamCity 8.1 we addressed this problem. The following settings can now be overridden and this can be done in place, without introducing new parameters:
build number format
artifact paths
build options (hanging builds detection, status widget, number of simultaneously running builds)
VCS checkout mode
checkout directory
clean all files before build
show changes from snapshot dependencies
execution timeout
all common build failure conditions, including execution timeout
Easier build artifacts configuration
If your build produces Build Artifact, you can configure TeamCity to publish these artifacts to the server. Previously the process was a bit tedious, because you had to know the exact paths to the artifacts. In 8.1 we added the ability to browse the checkout directory of a build. Now, once a build is finished on some agent, you can easily browse the checkout directory and pick artifacts: 
Listing build targets
The available Ant, NAnt and MSBuild targets can be viewed right in TeamCity web interface: 
The same is supported for IntelliJ IDEA run configurations, artifacts and inspection profiles.
Project and build configuration navigation
Project and build configuration editing pages have been reworked for better consistency:
the project tab navigation changed to the vertical layout
the navigation sidebar inside build configuration pages has been moved to the left
the actions like copy, move, extract template, have been moved from the sidebar to the upper right Actions menu
External database set-up on the first start
When setting up TeamCity for the first time, you can configure it to use an external database right on the server start-up: just select the type of the database and specify the database connection settings. However, you may still need to download the JDBC driver for your database.
Additional build features
Feature branches auto-merge
If you are using feature branches with Git and Mercurial, with the help of the Automatic Merge Build Feature you can now configure TeamCity to merge a feature branch automatically to the master if a build in the feature branch completes successfully. There is also an option to merge manually from the build's Changes tab.
The whole user experience is similar to the Pre-Tested (Delayed) Commit feature. Developers push commits in their own branches. TeamCity monitors these branches and runs a build on the pushed changes. If a build satisfies the merge criteria (successful, or there were no new failures in it), the branch is merged by TeamCity into default/master or any other branch configured in the auto-merge build feature. Unlike pre-tested commit, no IDE is required to use this feature.
VCS labeling build feature
The VCS Labeling settings were reworked as a Adding Build Features instead of options in the VCS Settings section. The existing settings are converted automatically to the new format. The build feature allows for more flexible configuration: you can now have different labeling settings for different VCS roots, or disable and redefine the labeling settings inherited from a template. 
Project-level settings
Per-project Maven and Build report tabs
Previously Maven settings and build report tabs could be configured on a global level only and only system administrators were able to manage them. Since version 8.1 these settings are moved to the project level and are now available for editing by project administrators.
As with any other project-level settings, Maven settings and Build report tabs defined in some project are available not only to this project but to all sub-projects as well. Existing settings will be moved to the Root project during server upgrade.
Per-project SSH Keys
If your Git (JetBrains) repository requires SSH access, to use it in TeamCity in earlier versions you had to put the SSH private key in some location on the server, and in case of the agent side checkout - to each agent where your build was to be executed.
Now, you SSH Keys Management an SSH private key right into the project using the TeamCity web interface. You can then configure the Git VCS root to use this uploaded key.
More Health Reports
We added several new health reports:
detect problems with reusing builds for configurations with snapshot dependencies
detect queued builds sitting in the queue without compatible agents
report cloud agent issues (e.g. the agent machine cannot be stopped, or an agent is in the idle state longer than the timeout)
detect exhaustion of the server disk space and pause the build queue in such a case
detect missing Maven settings
detect database collation mismatch in TeamCity tables
All suggested settings detected by TeamCity are shown under the special Suggested settings category in the server health report. Some of the health reports that do not require administrator's permissions are now available in the user space, on the build configuration home page.
Finally, server health report has been redesigned a bit: 
Changes page aka "My Changes"
The page previously known as Viewing Your Changes now has a user selector allowing you to see modifications made by any other TeamCity user the same way you see your own changes. As a result the page was renamed to Changes. Besides, instead of the carpet showing the status of builds, each change now has a new pie-chart icon with pie slices showing the relative size of pending, successful, as well as old and new problematic builds affected by the change.
Statistics improvements
We expanded Statistic Charts to occupy the whole page width. Statistics charts now support zooming. In addition, all statistic values published by a specific build are now available on the Build Working with Build Results tab with the ability to see history of changes for reported values: 
Build failure condition on a metric change
A Build Failure Conditions has been extended with the support for percentage. You can now fail a build if the number of tests is, for example, 10% lower than in some other build. We have also redesigned the web interface to make it more straightforward: 
Improved build run time estimation
TeamCity always estimated build duration based on the average run time of the latest builds in the history of a build configuration. Starting with 8.1 we switched to a new algorithm taking into account build stages reached by a running build. For example, if a build is still executing a build step and TeamCity knows that there are two more build steps, the system will calculate the time left for the current step execution and add the time required to complete the next two steps.
REST API Improvements
Since TeamCity 8.1, new features are available in TeamCity REST API. It can now be used to:
trigger a build; while triggering a build, a change to the build can be specified as well as all the rest of the settings from the custom run build dialog.
list builds in the build queue
stop a running build
access the canceled build details
query for investigations for a build problems and tests in addition to build configuration investigation
list investigations assigned for a user
list the build's tests
get test run history
delete a build agent
assign project to an agent pool.
As a security measure, users without the VIEW_USER_PROFILE (View user profile) or CHANGE_USER (Modify user profile and roles) permissions can no longer list users and user groups.
Support for JaCoCo
JaCoCo coverage engine is now available for Maven, Ant, Gradle and IntelliJ IDEA builds.
For now JaCoCo coverage results are shown in TeamCity web interface only and cannot be loaded from TeamCity in IDE.
Support for Visual Studio 2013, Subversion 1.8, Xcode 5 and more
TeamCity is now fully compatible with Microsoft Visual Studio 2013, Team Foundation Server 2013, Subversion 1.8 and Xcode 5.
In addition, we bundled the fresh version of Maven - 3.1, and upgraded Ant to version 1.8.4. The bundled dotCover has been upgraded to version 2.6.
Backup / Restore improvements
The duration of the process of Restoring TeamCity Data from Backup has been decreased. Since there were many problems with failed restore process due to the lack of disk space, we added a new "--continue" command to continue process from the point where it failed.
Other improvements
several security issues were fixed related to web UI XSS vulnerability and partial information exposure for users without sufficient permissions
the packages restore command introduced in NuGet 2.7 is now supported
the Copy action is now available for templates
an artifact dependency can be configured on a previous build of the same build configuration (TW-12984)
you can browse the TeamCity Data Directory right from the web interface using the Administration|Global Settings|Browse Data Directory tab; it is also possible to upload new files and modify the existing ones
changing IDs of a build configuration, project or VCS root does not invalidate bookmarked links with previous IDs
project names in the UI got drop-down menus with all the sub-tabs and the Edit Settings link for quick navigation. Build configurations now also list all the sub-tabs in their drop-downs
Save and Cancel buttons are moved to the left
a project can be selected in the Investigation dialog when an investigation is assigned for a test. This is useful when the test fails in a sibling projects
a new option in YouTrack integration allows for monitoring all projects from the YouTrack server automatically
a new build parameter is introduced to pass Predefined Build Parameters into the build script (TW-4502)
the Shared Resources build feature has been improved to pass all the taken locks into the build. See the related upgrade notes entry
the schedule trigger has got the timezone setting for the cron-based trigger
the TeamCity JIRA integration now uses JIRA REST API instead of RPC
Ruby Environment Configurator now supports RVM with .ruby-version files
VCS Checkout Mode has been reworked to reduce the number of unnecessary Clean Checkout
all artifacts published by a build are now cached in the local artifact dependencies cache on the agent, this should speedup artifact dependencies in some cases
fixed issues
Previous Releases