What's New in TeamCity 9.0

Moving projects between TeamCity servers

Now TeamCity provides the ability to move projects among servers: you can transfer projects with all their data (settings, builds and changes history, etc.) and with your TeamCity user accounts from one server to another. All you need to do is create a usual backup file on the source TeamCity server containing the projects to be imported, put the backup file into the <TeamCity Data Directory>/import directory on the target server and follow the import steps on the Administration | Projects Import page.

For now there are still some limitations:

Only backup files created with a TeamCity server of the same version as the current server are supported.
the backup files do not contain artifacts, so artifacts are not imported automatically; the same applies to build logs, because since version 9.0 build logs are stored under build artifacts - however, we provide scripts enabling you to move artifacts and logs.
audit records are not imported
global server settings (authentication schemes, custom roles, etc.) are not imported More details on this feature are available in Projects Import.

Storing project settings in Git and Mercurial

TeamCity provides the Storing Project Settings in Version Control of project settings with the version control. Synchronization is supported for Git and Mercurial only. You can enable synchronization on the Versioned Settings page in the project administration area. With the synchronization enabled:

each administrative change you make to the project settings in the TeamCity Web UI is committed to the version control; changes to several projects will generate a cumulative commit;
if you alter the settings in the version control, the TeamCity server will detect the modifications and apply them to the project on the fly. Enabling synchronization for the project also enables it for all its subprojects. TeamCity synchronizes all changes to the project settings (including modifications of build configurations, templates, VCS roots, etc.) with the exception of SSH keys. The project settings are stored in the .teamcity folder in the repository.

As soon as synchronization is enabled in a project, TeamCity will make an initial commit in the selected repository for the whole project tree (the project with all its subprojects) to import the current settings.

TeamCity will not only synchronize the settings, but will also display changes to the project settings the same way it is done for regular changes in the version control. You can configure the changes to be displayed for the affected build configurations. Such changes are ignored by build triggers.

Server clean-up in background

If you use TeamCity in a distributed team, you no longer have to face the pain point of finding a time slot suitable for everyone to perform your server clean-up: TeamCity now runs clean-up in background, which means that there is zero maintenance downtime.

Note that if you are using the HSQL database, there is still a short period of server unavailability when the HSQL database is being compacted. For production purposes, switching to an external database is recommended.

Simplified custom charts management

Earlier, to edit custom charts you had to manually modify xml files. Now you can easily manage custom charts using the TeamCity Web UI:

on the Statistics tab for a project or build configuration using the Add new chart button.

on the Parameters tab of the build results page, where the list of Reported statistic values provides checkboxes to select the statistic value for a new project- or build-configuration-level chart.

In addition, the custom charts definitions are stored on the project level, so they are available to Project Administrators. More details on this feature are available in Custom Chart. Note that the default charts cannot be modified.

Favorite builds

To easily access builds you want to monitor, you can mark them as favorite. Optionally, any manually triggered build can be added to your Favorite Build automatically. The marked builds will be listed on the My Favorite Builds page available in your user profile.

You can also Subscribing to Notifications on your favorite builds.

Build Time report

Similarly to the Disk usage, now you can see how many resources are taken up by a project with its subprojects: the new Build Time Report is now available in the Project-related Settings of the TeamCity Administration area. By default, the report displays total build duration within the last 24 hours for the server and individual projects with the percentage in relation to the parent project. The scope can be further drilled down to the build time of an individual build configuration.

Meta-Runner improvements

Working with meta-runners has become easier: now if you need to fix a meta-runner, there is no need to edit its xml definition; instead you can create a build configuration from the meta-runner, debug and fix it. Then you use the Extract meta-runner action to apply changes to the existing meta-runner.

Besides, you no longer need access to the < TeamCity Data Directory> on the disk to upload a meta-runner - you can now upload it from the TeamCity Web UI.

7-zip support for published artifacts

TeamCity can now compress published artifacts to a 7-zip archive: * / => dist.7z As with other supported compression algorithms, you can also specify artifact dependency for the files inside a 7-zip archive: dist.7z!folder/** Browsing inside 7-zip archives is also supported, but not browsing inside a 7-zip placed into another 7-zip archive.

Push parameters to dependencies

When you add a build which depends on other builds to the queue, you can change the parameters of the builds this build depends on. For example, our ReSharper team has a compile build producing dlls containing the debugging information which the installer build depends on. Most of the time we need the installer with the debug information, but for the release build we need the debug switched off. Now we can specify the parameter disabling the debug mode in the installer build and push it to all builds in the chain using the Predefined Build Parameters in the parameter name.

Customizable behavior on snapshot dependency failure

Previously TeamCity offered limited control over dependent build status if a dependency failed. Now new options are available for more flexible configuration. For each failed or failed to start dependency you can select one of the four options:

Run build, but add problem: the dependent build will be run and the problem will be added to it, changing its status to failed (if problem was not muted earlier)
Run build, but do not add problem: the dependent build will be run and no problems will be added
Make build failed to start: the dependent build will not run and will be marked as "Failed to start"
Cancel build: the dependent build will not run and will be marked as "Canceled".

Per-project configuration of issue tracker integration

The configuration of integration with issue trackers has moved to the project level, and now users with the Project Administrator permissions can access this feature in the Project Settings. If you are using different issue-trackers for different projects, you will definitely benefit from this improvement. Enabling integration for the project also enables it for all its subprojects; if the configuration settings are different in a subproject, its settings have priority over the project's settings.

Perforce streams and new options support

You can configure a Perforce VCS Root to monitor Perforce streams. Both server and agent-side checkout modes are supported.
New options were introduced for Perforce VCS roots: support for p4 clean introduced in Perforce 2014.1, ability to provide extra p4 sync options, like --parallel

Other version controls

NTLM authentication can be used for Subversion repositories.
TeamCity now supports configuration of Mercurial options per repository leaving behind the old approach which implied editing global mercurial configuration files on the server and agents. Now it is possible to enable some mercurial extensions only in the repositories where they are required.
The Use mirrors option has been added to Git and Mercurial VCS root settings page.
Better git/hg progress reporting for the agent-side checkout: now all executed commands are shown in a build log.

Tagging queued / running builds

TeamCity now provides an option of Build Tag queued builds. There are several ways of doing it:

from the Triggering a Custom Build dialog
from the Actions menu of the queued build page

WebSockets for server events

Now TeamCity establishes a WebSocket connection between the server and the browser if both parties support the WebSocket connection. This allows delivering server events to the browser more efficiently, making the TeamCity Web UI more responsive.

TeamCity switches to polling when the WebSocket connection is unavailable in the following cases:

TeamCity requires Tomcat version 7.0.43 and above for WebSockets to work; TeamCity will switch to polling automatically if this is not the case.
The WebSocket connection is not available for Internet Explorer versions below 10 and Safari; for them polling will be used.
If the TeamCity server is behind a proxy, How To... is required for the WebSocket connection to work.

Gradle project in Inspections (IntelliJ IDEA) and Duplicates Finder (Java)

TeamCity inspections and duplicate code analysis tasks are now available for Gradle projects in addition to IntelliJ IDEA and Maven projects.

Backup / restore performance improvements

After upgrading to 9.0, TeamCity will start a background process optimizing the VCS changes database structure. After the process finishes, backup and restore should start working faster. You can safely create backups while this process is running, but it is not recommended to use these backup files for projects import, as some VCS related data may not be imported to the target server.

Other

Notifications can be configured to be sent out for builds on non-default branch. This is configured via "Edit Branch Filter" notification rules setting
Floating point numbers support for statistic values: TeamCity supports fractional numbers with up to 6 decimal points for all statistic values
Bundled Maven 3.2.3
Now the Maven artifact dependency trigger can use authorization configured using the new advanced settings of the trigger.
Instead of old school DTD files for project configuration files, TeamCity now uses the XML schema: http://www.jetbrains.com/teamcity/schemas/9.0/project-config.xsd
NuGet feed supports API v2. The feed performance should be much better.
The ability to specify which fields to include into REST API responses via the fields parameter graduated from experimental state (was introduced in 8.1)
LDAP error reporting into the teamcity-ldap log was improved a lot and now provides more guidance on fixing incorrect settings
Unicode Support for MS SQL and Oracle: the national character sets (nchar, nvarchar, nclob types) for text fields are now supported in MS SQL and Oracle databases used by TeamCity. You can now use Unicode characters to store the user input and data from external systems, like VCS, NTLM, etc.

Last modified: 20 April 2023