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.
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).
Notifications
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
- E-mail
- 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.
Current Problems
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.
Quality Tracking
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.
Server-side inspections for Java, JSP, JavaScript, and CSS
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 Management
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.
Build History
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.
Change Log
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.
Build Infrastructure
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.
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
Multi-platform builds
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)
Agent management
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.
VCS Interoperability
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
web.
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).
VCS Labeling
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.
Agent-side Checkout
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".
Key Integrations
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.
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.
Maven integration
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.
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.
XML Reporter
TeamCity can process various XML reports and feed data to TeamCity. The following formats are
supported:
- Ant's JUnit task
- NUnit
- Surefire
- PMD
- FindBugs
- Checkstyle
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.
Plugin Development
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!
User Authentication
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.