Remote Build Run and Pre-Tested Commit
With TeamCity you can build, check and run automated tests on the server even before committing your changes — keeping your code base clean at all times. Optionally, you can set up TeamCity to automatically commit changes to your version control each time they pass all checks.
These features are provided via IDE plugins for Eclipse, Microsoft Visual Studio, and IntelliJ IDEA, and also as a command-line tool. Read more »
Manual and Automatic build triggering
The easiest way to run a build under TeamCity is by simply pressing the "Run" build button. But in most cases you'll also want to use TeamCity for running builds automatically:
- periodically (to process daily or nightly builds), or
- upon version control system check-in (by setting up VCS triggers), or
- upon another build successful completion (by setting up dependencies).
TeamCity offers multiple ways to instantly notify you about build problems or any other changes in your projects:
- Web-based user dashboard
- IntelliJ IDEA, MS Visual Studio, and Eclipse integration plugins
- Jabber/XMPP protocol instant messaging
- RSS feeds
- Windows Tray Notifier
You can set up multiple notification rules on all kinds of events, and also choose the order in which they are processed.
To reduce the number of messages, you can choose to only be notified on builds with your changes.
On-the fly test reporting
One of TeamCity's unique features is the ability to track running tests and report all the information on the fly - both in the web UI and in all supported IDEs. You don't have to wait for a build to finish to discover that something is wrong. TeamCity alerts you about failed tests immediately and provides details on encountered errors, thus saving lots and lots of time for the team.
You get all important information about every test that has been run: status, name, duration, statistics, and more. For each failed test TeamCity also provides a direct link to open it in your IDE.
Risk Group tests reordering
Using Risk Group Tests Reordering, you can instruct TeamCity to run tests of a specific type before any others. Currently, there are two types of tests which you can set up to run before the rest:
- recently failed tests, i.e. the tests failed in previous finished or running builds, as well as tests having a high failure rate (so-called 'blinking tests')
- new and modified tests, i.e. tests added or modified in changelists included in the running build
Monitoring the status of your changes
Getting quick and accurate information about how well your recent changes integrate into the project is what Continuous Integration is all about. Depending on your personal preference, you can choose between different means of monitoring the status of your changes:
- The My Changes page gives you the most accurate and up-to-date results of integrating your own changes into the project code base.
- Plugins for IntelliJ IDEA, Eclipse and Visual Studio provide an efficient way of keeping track of your changes without requiring you to leave an IDE.
Newly Failed Tests and "Fixed in"
When the newly checked-in code fails a test, TeamCity immediately shows it on the Build Results page. If a test did not fail in the previous build, it will be shown as a "New" failed test.
For a failed test, you can see the build in which it failed for the first time with a link to changes in this build.
As soon as the test is fixed, the test name is crossed out and a checkmark appears next to it.
For each failed test, 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. There is also a test history page which shows the history of the test failures / passes.
For each project TeamCity gathers information about its current problems: failing build configurations and not yet fixed tests. This is the place where every team member can see momentary snapshot of the current project status.
Problem responsibility assignment
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 you assign responsibility for this build 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.
Responsibility can be assigned to a whole build or with per-test granularity. For each project you can also see all of the currently assigned responsibilities in a single place.
Analysis of unit tests code coverage
For Java, TeamCity comes with two coverage engines: IntelliJ-IDEA-based and EMMA.
For .NET, TeamCity integrates with NCover and PartCover. In both cases enabling coverage is as easy as selecting a couple of checkboxes in the Web UI. If you are using IntelliJ IDEA, you can also feed it with the code coverage results from TeamCity server to get smart highlighting right in your source code.
TeamCity uses a set of more than 600 IntelliJ IDEA's inspections to analyze your code and identify potential problems, such as:
- unused and unreachable code;
- declaration redundancies;
- performance issues;
- dead code;
- many other problems.
You can check out the code analysis results in a browser and then navigate to a particular string of code in the IDE, where you can suppress or resolve the inspection results.
Detailed test results analysis
TeamCity allows you to investigate which tests/classes/packages take most time to build. 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.
The Dedicated Test Details page contains the entire history of test runs with a test duration chart.
Search for duplicate code in Java and .NET projects
Searching for code duplicates in big projects manually is a very resource-intensive task, requiring huge amounts of time. Not only does TeamCity allow delegating this work to the build servers, but it also helps automate it, by providing constant monitoring of the code base state with no extra effort from you. The search for duplicates is performed on Build Agents and detailed reports are then available in the web UI. If you are using IntelliJ IDEA, you can also see the results of duplicates analysis right in the IDE.
Comprehensive statistics reports
With statistical trends you can track the condition of your projects over time. The visual graphs include information about all the builds of a certain build configuration across all its history. You can:
- Select time range for each type of statistics
- Filter information by data series, for example, by Agent name or by result type
- View average values
- Filter out failed builds and show only the successful builds
- View build summary information and navigate to the build results page
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, and the Build Results page.
To estimate build times, TeamCity considers previous build durations and parameters of the build agent on which the build is running.
Build Configuration Templates
Templates can save a lot of manual work when you need to define a number of duplicate or very similar build configurations. With TeamCity you can create a template with the common (shared) settings, and then inherit any number of build configs from this template. You can also extract a template from any of your existing build configurations.
Build Tags, Pins and Comments
Build tagging is a nice way to organize your builds and quickly filter builds in the build history. You can apply one or several tags to a single build, and then search for builds marked with these tags. You can also leave a comment on a specific build and comment the build's pin action.
TeamCity keeps a history of builds' artifacts and other data such as build logs.
To limit your database of builds and thus manage the hardware load more effectively, you can specify the clean-up policy using the administration interface.
If you don't want builds with all related information, artifacts, etc. to be removed from the database, just pin the desired build and you will always be able to access its artifacts. This can be especially useful if you want to keep the artifacts of some error-free build intended for release or other purposes.
Custom and History Builds
With history builds, you can choose any change from the change history, and run a build that will not include any later changes. This helps quickly identify any unsafe modifications, and may help restore your build's artifacts if they were accidentally lost.
While running builds (including personal builds) you can also configure them with custom properties, environment variables, or even different artifact dependencies.
The change log accumulates the list of pending changes, and the changes already included in the builds of the selected build configuration.
You can view changes between specific builds, or filter them by change committer.
Build Chains and Enhanced Build Dependencies
TeamCity lets you specify snapshot and artifact dependencies for your builds. By setting up such dependencies, you can break down a single build procedure into several parts that can be run on different build agents both in sequence or in parallel.
Accessing build artifacts
Artifacts are files and folders such as installers, WAR files, log files, etc. produced by a build.
You can download artifacts from multiple places in TeamCity's UI: the Projects page, the Build Configuration page or the Artifacts tab on the Build Results page.
You can also download all build artifacts in a single .zip archive.
A build script can also notify TeamCity as soon as the build artifacts are created so they can be uploaded and made available for download even before the build is finished.
Multiple build agents
Build Agents are computers with installed agent software capable of running builds which all together
make up the Build Grid.
As developers integrate their work results into the Version Control System, TeamCity server distributes them to the Build Agents automatically, without the need to install version control software on all of your build agents. Read more »
Load statistics matrix
The Matrix provides you with a bird's-eye view of the overall Build Agents workload for all finished builds during the time range you selected.
By taking a look at the build configurations compatible with a particular agent, you can assign the build configuration to particular Build Agents and significantly lower the idle time. This helps you adjust the hardware resources usage more effectively and fill the discovered productivity gaps.
Build Agents' workload statistics
TeamCity provides a number of visual metrics, namely, statistics of Build Agents' activity and their usage during a particular time period.
You'll find this feature helpful in:
- your daily administration activities aimed at lowering your company's network workload
- locating and eliminating the gap between the most frequently used computers and those which are often idle
- reducing the cost of your hardware resources ownership
TeamCity's Build Agents can have different platforms, operating systems and pre-configured environments that you may want to test your software on. Different types of tests are run under different platforms simultaneously so developers get faster feedback and more reliable testing results.
Assigning builds to a particular agent
Any build configuration can be explicitly assigned to run on a specific Build Agent. In addition, you can manually select any compatible build agent for each particular build in the custom build runner.
Parallel build execution
With this feature you can start off a build on several compatible agents simultaneously. This comes handy, for instance, in the following cases:
- run a build on different platforms (you can set up a configuration, and specify a number of compatible build agents with different environments installed)
- run a build for agent maintenance purposes (you can create a configuration to check whether agents work properly after an environment upgrade/update)
After the installation of Build Agent software, the Build Agents are primarily managed from the web UI.
All connected Build Agents are automatically listed in the Web UI and need to be authorized before being used.
Build infrastructure utilization optimization
With TeamCity you can always check your builds queue and see the estimated start time for any build.
TeamCity also provides statistics on the average time in queue for any particular build configuration.
Together with the "CPU index" benchmark for every build agent, this gives you useful information for deciding when build agents need to be upgraded or when additional build agents should be installed.
Low-profile infrastructure maintenance
To be capable of getting project sources, Build Agents are not required to have any pre-installed and pre-configured Version Control System on them. All the source code is checked-out on the server side. Thus, less effort is required to maintain the company infrastructure.
In addition, Build Agents upgrade themselves automatically, saving the system administrator's time and lowering the cost of TeamCity ownership.
Flexible VCS Configuration
With TeamCity, you can use several different VCS roots for a single build. For example, the majority of your project sources may be located in Perforce, and several plugins in Subversion. TeamCity allows you to configure your project to use sources from both of them simultaneously, by specifying target directories for each VCS via checkout rules.
To reuse VCS settings just configure the VCS root and attach it to the desired build configurations.
File Diffs on the Web
View file differences on the web just like in the IDE and navigate to the project source base from the
If a changed file is an image, the diff view will display that image.
You can also configure integration with Fisheye or other external change browsers.
Advanced VCS build triggering
TeamCity constantly scans all of the build configurations' VCS roots and triggers builds if changes are found. You can also configure rules that prevent build triggering for specific paths, file types, or particular users.
TeamCity supports a "quiet period" - the amount of time to be passed since the last detected change till TeamCity starts the build. This can be used to ensure a build is not triggered in the middle of non-atomic check-ins consisting of several VCS check-ins (or when several VCS roots are involved in a commit).
TeamCity can optionally add a label into Version Control for the sources used for a particular build. You can choose to apply the VCS label for all builds or only for successful ones.
You can also manually label the sources used for a build from the Build Results page.
By default, TeamCity checks out all sources on server and then passes them to agents before each build. In order to free up some more server resources, and in case your build scripts need access to version control-specific directories (.svn, CVS, etc) so that they can perform some VCS operations like check-ins for some types of VCS systems, it is possible to set the checkout mode to "Checkout on Agent".
Amazon EC2 and Virtual Agents
TeamCity takes advantage of cloud computing by putting Build Agents on Amazon EC2. After your Build Agents' AMIs (Amazon Machine Images) are registered, the TeamCity server will account for those virtual machines in its build scheduling and will automatically do a suspend/resume job on them, based on the load and build queue status. Read more »
Issue Tracker integration
How often do you see comments like this: "TW-3431 fixed"? How about a little more detail on the issue at hand? The issue tracker integration provides an in-place bug title, direct navigation to the issue, and other productivity goodies. It is currently available for Jira, Bugzilla and JetBrains YouTrack out of the box, but can easily be extended to other systems via plugins.
TeamCity has many means for native Maven support under the hood. These include creation of the Maven-based build configurations (only the URL to the POM file is needed), visualization of the various project data gathered from POM, and a new type of dependency trigger - Maven artifact trigger. This type of trigger starts a build each time the specified Maven artifact changes.
You can enable coverage for Maven-based builds in just a few clicks. Read more »
Extensibility and Customization
Displaying Custom Build Results
TeamCity can change the build status directly from the build script. You can set the status (build failure or success) and change the build description text.
Declarative statistics charts and custom metrics
With TeamCity you can create your own statistics graphs with simply providing the required data in XML configuration files. Custom statistics also supports displaying multiple graphs on a single chart.
Custom test runners support
With the help of service messages, you can report tests progress, failures, or ignored tests. You can also mark build progress and change status, publish artifacts during the build, and more. All this is possible simply by writing specially formatted lines of text to the standard output.
TeamCity can process various XML reports and feed data to TeamCity. The following formats are supported:
- Ant's JUnit task
Third Party HTML Reports
If your reporting tool produces HTML reports, you can easily add a new tab to the Build Results page that will display the report.
Reports from the latest builds can be set to display as additional tabs on the Projects page.
TeamCity functionality can be extended in a number of ways. You can make declarative changes using bits of XML, which provide additional information about your builds, or you can write a real TeamCity plugin using the new and improved OpenAPI.
With Open API you can develop integration with version control systems, issue tracking systems, build tools, IDEs, and notification programs.
Some TeamCity plugins including FxCop, Eclipse, Rake runner, and ClearCase VCS support plugin are open source and could make an excellent start for your own plugins.
More TeamCity Features
JVM Crashes and Out of Memory Problems Detection
Similar to detecting hanging builds, TeamCity also detects crashes of the JVM and Java out of memory problems. TeamCIty will set a special prefix to build status if such problem is detected, and such builds will be easily discovered in the build history. To simplify the developers' lives, TeamCity will try to find crash logs and memory dumps and upload them as artifacts for such builds.
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 the developer about them. In addition, TeamCity can stop build automatically if it runs for more than the specified amount of time.
To further investigate the build hanging, TeamCity also has a reliable "stop build" action - no need to go to the agent to investigate/fix a problem!
TeamCity supports several authentication schemes:
- Default Authentication (cross-platform)
- NT Authentication (cross-platform)
- LDAP Authentication (cross-platform)
LDAP authentication enables TeamCity to retrieve user profiles and group memberships from your company's directory, and to keep them synchronized with the LDAP server. There's also an option to automatically create or remove user accounts once they are found in the associated LDAP group.
Thread Dump for Running Builds (.NET + Java)
This feature allows you to obtain a thread dump of your running build for investigation without even the need to log in to the build agent, and it works for both Java and .NET builds.
User Management with Per-project Access and Roles
TeamCity users can be organized into groups and assigned privileges via an enhanced engine. Once included in a certain group, a user gets all the roles assigned to the group. Right from the Web UI you now can:
- assign and configure roles to users in specific projects
- filter users belonging to a certain group
- specify notification rules for groups
When a new user is added, she is assigned to the "All Users" group.
Audit of user actions
TeamCity logs user actions into the Audit log. This log is a great time-saver if you need to discover who deleted a build configuration or project, assigned a role to a user, added a user to a group, and so on.