Distributed Build Management and Continuous Integration Server

Remote Build Run and Pre-Tested Commit

With TeamCity's Remote Run and Pre-tested commit features developers can trigger personal builds from one of the supported IDEs: (Eclipse, Microsoft Visual Studio, and IntelliJ IDEA)) to test how their changes integrate into the current project sources and then, if a personal build is successful or there were no new tests failed since the previous build, developers' changes can be committed to the VCS automatically.

Combination of these features allows developers to avoid committing doubtful changes to repository. As a result, bad code doesn't affect the team and work is not interrupted. User can switch off the Pre-tested commit option while customizing remote run settings, and no code will be checked into the VCS regardless of the state of the personal build.

Read more about Pre-tested Commit »

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

Eclipse plugin

• Perform remote run and pre-tested commit to your code base managed by CVS.
• Browse failed test output without leaving the IDE.

Microsoft Visual Studio Addin

• Perform pre-tested commit and remote run to your code base managed by Perforce.
• Subversion 1.6 support.
• 

Running Custom and History Builds

Your team committed two new changes into the version control and kicked the build. Of course, it's failed! Which one of the changes to blame? This is the situation when history builds come to play.

With history builds, you can choose particular change from the change history, and run the build which will only include changes up to this one, quickly identifying the unsafe modification.

History builds can also be helpful to restore your old build bits - you don't have to keep all your build artifacts anymore.

You also have an option to pass custom properties to a build on the build start.

Build Chains and Enhanced Build Dependencies

TeamCity let's you specify snapshot and artifact dependencies for your builds. Setting up such kind of dependencies you can break down a single build procedure into several parts that can be run on different build agents both in sequence and in parallel.

Indirect dependencies are now displayed on the build Dependencies tab.

Build Progress and Estimation

As TeamCity runs your 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 Project home page
• The Build Configuration page
• The Build Results page

To count build estimates, TeamCity considers previous build durations and parameters of the build agent on which the build runs.

On-the-fly Test Results Reporting

TeamCity can track the tests and report all the information on-the-fly both in the web UI and all supported IDEs, and you get this opportunity right from the box.

Developers do not have to wait for build to finish to discover that something is wrong. TeamCity informs about tests failure immediately and provides details on occurred errors, therefore, saving lots and lots of time for the team.

You get all important information about every test which ran: status, name, duration, statistics, and more. For each failed or ignored test TeamCity also provides a direct link to open it in the IDE you use.

The feature is available for testing frameworks which TeamCity integrates with.

In addition to immediate tests results reporting, TeamCity publishes build artifacts as soon as they appear.

To speed up the work even more, you can try during-the-build artifacts publishing feature: use service messages to specify publishing rules.

Tests Results Analysis

TeamCity allows to investigate which tests/classes/packages take most of the build time. For each test, you can also see a graph which shows how test duration changes from build to build.

Build test report allows:

• Grouping by suite/package/namespace/class with cumulative test duration
• Filtering by test status (any, failed, ignored or successful)
• Showing tests of a particular package
• 

Risk Group Tests Reordering

In addition to time-saving features supporting quick testing and getting notifications as soon as the first problems appear, TeamCity enables new Risk Group Tests Reordering feature that provides even faster feedback on tests results. This new feature is especially useful when the waste of time can become a critical factor of the project success - a problem which may arise in almost every team and project.

Using Risk Group Tests Reordering options, you can instruct TeamCity to run tests of specified type before any others. Now TeamCity distinguishes two groups of such tests:

• tests that have failed recently in previously finished or running builds and tests that fail from time to time
• tests that were recently added or edited in developers changelists and included in the running build

Custom Tests Reporting

You can 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 can assist you with abnormal build detection and troubleshooting: it detects builds which are probably "hanging" at the moment and notify developer about them. In addition, TeamCity can stop build automatically if it runs more then specified amount of time.

To investigate the build hanging, TeamCity even provides ability to take thread dump and reliable stop build action - no need to go to the agent to investigate/fix a problem!

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.

Notifications

TeamCity has multiple ways to monitor your projects' health that match almost any team's habits:

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

You can select from a wide range of events to be notified about.

You have the opportunity to apply the order your notification rules are processed plus more notification options are added.

Embedding TeamCity Status in External Pages

Using a status widget, which you can set up by just inserting a small HTML fragment into any web page such as your company's website, blog or a wiki, you can monitor the status of your build configurations on any web page.

Tracking the Status of Your Own Changes

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.

Builds with "My changes" now have "Changes" block highlighted on the Projects page and other places of the web UI.

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.

Windows Tray Notifier

The Windows Tray Notifier can 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 console output of your build that is available right in the web UI: on the Build Results page. You can opt to view the complete log, or only important messages. In addition, TeamCity provides highlighting for error messages and ability to display most important messages in a separate view.

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.

Now TeamCity enables assigning responsibility for build problems with automatic notification a responsible person.

Build Triggering

With TeamCity you can trigger builds:

• manually (via the web interface or your IDE),
• periodically (create daily or nightly builds),
• whenever changes are checked into the source control system
• when a build that is used by a different build configuration completes successfully

Scheduling

TeamCity's build server enables time-based triggering for your build configurations. And you can also 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.