3.1

Pre-tested Commit

With TeamCity's unique Pre-tested Commit feature (available in IntelliJ IDEA, Eclipse, and Microsoft Visual Studio), the developer's changes to be committed to the VCS are first tested on the server bypassing the VCS:

• If the committed changes fail the tests, the code is not integrated and the developer is notified so he can safely work on a fix. The bad code doesnt affect the team and work is not interrupted
• If the build is successful, the changes are committed to the VCS automatically

Read more about Pre-tested Commit »

Remote Run

The Remote Run feature enables developers to create personal builds. The developers can trigger these builds from one of the supported IDEs (IntelliJ IDEA, Eclipse, and Microsoft Visual Studio) to test how their changes will integrate into the current project sources. But unlike the pre-tested commit feature, no code is checked into the VCS regardless of the state of the personal build initiated via Remote Run.

See a Live demo on performing remote run from within Eclipse.

Build Progress and Estimation

As TeamCity runs builds, you can conveniently evaluate their progress and current state from a number of different places, to name just a few of the most frequently used:

• The Projects page
• The Build Results page
• The Build Queue page

Information on estimated build duration, build start time and planned build agent is now displayed on the Build Queue page.

On-the-fly Test Results Reporting

TeamCity is an ideal tool for continuous testing. TeamCity displays tests results on-the-fly: even before the build is finished, you can see the results in multiple places of the web UI and IDEs.

Parallel tests running support

TeamCity now correctly reports JUnit and TestNG tests run in parallel via Ant "parallel" task or TestNG paralleling.

Custom Tests Reporting

You can now benefit from TeamCity's tests reporting possibilities even when your testing framework is not directly supported by TeamCity. By printing the specially formatted messages to the build standard output, you send test events to TeamCity and get on-the-fly test reporting. This feature can be useful for custom frameworks support and doesn't require developing a fully-fledged TeamCity plugin.

Newly Failed Tests and "Fixed in"

When new code fails a test, TeamCity immediately shows it on the Build Results page. You can view a detailed description of the problems that occurred or navigate to the test code in the IDE right from the web UI.

As soon as a developer fixes the code that failed the test, and a build with the fix passes, the test name is crossed out and a check mark near it appears.

Hanging Builds Detection

TeamCity 3.0 can assist you with build troubleshooting: it detects builds which are probably "hanging" at the moment and displays it in the web UI.

To be informed of hanging builds, opt to get the notifications on these events (navigate to My Settings and Tools | Watched builds and Notifications and select the The build is probably hanging option).

Thread Dump for Running Builds (.NET + Java)

This is another one of TeamCity's unique features that helps you discover strange problems with your builds - such as build hangs and deadlocks. It allows you to obtain a thread dump of your running build for investigation without the need to log in to the build agent. This feature is available for both Java and .NET builds.

Just click the link for the running build, and a page showing the thread dump of the build processes(es) opens, ready for further investigation.

TeamCity has multiple ways to monitor your projects' health:

• The user dashboard
• IntelliJ IDEA, MS Visual Studio, and Eclipse
• E-mails
• Jabber/XMPP protocol instant messages
• RSS feeds
• The Windows Tray Notifier

RSS feeds

If you use an RSS reader, you can now be notified about finished builds via a TeamCity generated RSS feed. Select from a wide range of options, subscribe to the URL created by the program, and receive new messages about:

• All new, successful or failed builds
• Builds triggered by changes made by all users, a particular user, or only your changes

The feed entries you will later receive contain a summary of the build results for the selected build configurations and links to the build changes and the build log.

External status widget

We decided to make it easy for software development teams to let their customers and other people view the status of different builds. No special magic — just insert a small HTML fragment into any web page:

• your company's website
• a blog
• a wiki
• Confluence

And get an overview of the current project status: the latest build results, its ID, the date and a link to the latest build artifacts.

This "version" of the projects dashboard does not require a login of any kind and of course the builds' status is constantly updated.

To start using this feature, you have to either create a new build configuration or edit the general properties of an already existing one and select the Enable status widget option.

The My Changes Page

The results of integrating your own changes into the project code base neatly separated from the rest of the team are always available on My Changes page.

In TeamCity 3.0 we made a number of enhancements of this page:

• on-demand content load (Today, Yesterday, and Older sections)
• improved performance
• VCS roots-related information is now displayed

In Your IDE

You can monitor the status of the integration of your changes in the IDE's that TeamCity supports (IntelliJ IDEA, Eclipse, and Microsoft Visual Studio): view the status of personal builds and get pop-up notifications on the builds' status.

Notifications

TeamCity provides many possibilities for notifying the developers about the status of the projects they monitor. A wide range of predefined notification rules and events helps you avoid information overload, stay tuned to the development process and switch to other applications only when it is really necessary. For example, you can:

• select from a wide range of notification services
• customize the events which trigger the notification

Receive notifications only when the build status changes

When watching builds of the specific build configurations, you can opt to receive notifications:

• on the first failed build after successful
• on the first successful build after failed

Ability to watch all projects

When customizing the notification rules, besides the Watch builds of the selected build configurations you can now select All projects to monitor all builds of all the projects' build configurations.

Windows Tray Notifier

The Windows Tray Notifier can now automatically update itself.

If you work in a Windows environment, you might want to be notified about the status of selected projects via the Windows Tray Notifier.

As the status of the builds changes, so does the icon in your system tray. With just one click you can access the Quick View window and get a picture of the monitored projects. Clickable links let you navigate to TeamCity's web interface.

Build Log

A build log is a list of the events that took place when creating a build. It is available on the Build Results page, where you can view the complete log, or only important messages.

The full build log is available for download from the Build Results | Build Log tab.

Responsibility Tracking

If for some reason your builds fail, this becomes evident to the entire team. TeamCity provides a very handy means of figuring out which changes might have caused the build failure and lets that developer take responsibility for it either in the web UI or in IntelliJ IDEA. The entire team is then informed that someone is working on a fix and again when the fix is complete.

Scheduling

TeamCity's build server enables time-based triggering for your build configurations.

Now you can use Cron Expressions for triggering your builds.

On VCS check-in

Whenever an updated version of a file appears in the project VCS, TeamCity creates a new build providing an automated build process.

Set how often TeamCity scans the VCS for changes and specify a "quiet period" — an amount of time that needs to pass before TeamCity runs a new build if no commits were made.

Dependency triggering

TeamCity lets you specify artifact dependencies and provides dependent build triggering. When creating new builds, you can opt to use the artifacts of:

• the last pinned build,
• a successful build,
• the last finished build (this can be useful when integrating changes with third-party libraries)
• a build with a particular number

You can view information on the build artifacts that were used to create the build on the Build Results page | Dependencies tab.