One reason TeamCity is dubbed an "Intelligent CI server" is its approach to integration. When we say we support a tool, we mean it in every way possible. For example, support for Visual Studio projects provides automatic detection of tool versions, testing frameworks support, code coverage, static code analysis, and more. And the best thing is, you get all this support without installing any plugins and with no modifications to build scripts!
- native support for Ant, Maven, Gradle or IntelliJ IDEA based projects
- integrated IntelliJ IDEA code analysis and code coverage
- integrated IntelliJ IDEA compiler with incremental building and support for languages including Scala, Clojure and Kotlin, as well as for Android projects
- native support for JUnit and TestNG, with the ability to reorder tests
- building Visual Studio solutions; native support for MSBuild, Powershell or NAnt
- code analysis for C#, VB.NET, XAML, and many other languages powered by ReSharper
- testing with .NET testing frameworks, including: NUnit, MSTest, MSpec, xUnit and all Gallio-based frameworks
- code coverage with dotCover, NCover or PartCover
- best-in-class NuGet support
- using Rake with RVM, Bundler or Ruby SDK to build projects
- testing with Test::Unit, Test-Spec, Shoulda, RSpec, Cucumber
- building Xcode 3 and Xcode 4 projects
C++, Python, PHP, Node.JS and Others
Other languages like Python, C++ or PHP are supported through numerous plugins.
Learn more about technologies supported in TeamCity.
TeamCity takes advantage of cloud computing by putting build agents on Amazon EC2.
TeamCity accounts for virtual machines in its build scheduling and automatically suspends/resumes them, based on the load and build queue status. Read more »
TeamCity integration with JetBrains YouTrack works both ways:
- TeamCity detects issue IDs mentioned in changes and provides links to YouTrack.
- YouTrack can be configured to import information about a change from TeamCity and add it to the issue. YouTrack can even apply different commands to the issues if they are mentioned in TeamCity changes.
TeamCity also supports Jira and Bugzilla out of the box and can be integrated easily with other systems via plugins.
TeamCity has many features for native Maven support under the hood, including: creation of Maven-based build configurations, sharing of common Maven settings across projects and visualization of the various project data gathered from POM.
TeamCity can also trigger builds when a specified Maven artifact changes.
Read more »
With extensive NuGet integration TeamCity can install and update NuGet packages on agents, create and publish packages to a NuGet feed.
TeamCity can also act as NuGet feed server, and trigger builds on changes in a specified NuGet package.
Do you take continuous integration seriously? Do you want to have a stable trunk and green builds? If so, TeamCity will provide numerous features to support you all the way.
Remote 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.
These features are provided via IDE plugins for IntelliJ IDEA-based products, Microsoft Visual Studio and Eclipse. Read more »
Problem and Test Management
Several persons can be assigned for investigation of problems in one build. For example, Jane researches why the process exited with code 1, while Bill fixes some tests.
When a problem is assigned, notification(s) are sent to the corresponding person(s).
On-the-fly build progress reporting
TeamCity tracks different stages of the build and reports 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.
TeamCity offers multiple ways to instantly notify you about build problems or any other changes in your projects.
Be notified by email, instant messenger, or get notification right in your IDE.
You can set up multiple notification rules on all kinds of events, and also choose the order in which they are processed.
Newly Failed Tests and "Fixed in"
When newly checked-in code fails a test, TeamCity immediately shows it. 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 and what changed in this build.
Risk Group tests reordering
For certain build tools like Ant, Gradle, MSBuild and some others, you can configure TeamCity to change order of tests.
For example, recently failed or new tests can be started before others to provide even faster feedback to the developer.
Good software developers don’t like code duplication; similarly, good build engineers don’t like duplication of settings. TeamCity understands this and provides several ways to reuse settings.
Projects in TeamCity can be nested inside other projects and thus form a tree.
Settings and permissions defined in the parent project propagate to subprojects, which greatly simplifies maintenance of a large installation.
You can create a template with the common (shared) settings, and then inherit any number of build configurations from this template.
With parameters you can generalize version control settings, template or build configuration, making them reusable and easily customizable.
Meta-runner is a great way to reuse a set of build tasks, making you feel like this set of tasks is natively supported by TeamCity.
You can create it from existing build steps in several clicks and then reuse in other build configurations.
Build Failure Conditions
You can use a wide spectrum of different conditions for marking a build as failed.
A build can be marked as failed if coverage drops below the specified threshold, or decreases compared to a previous build; if specific text appears in the build log; if artifacts were not published; and in many other cases.
Build Chains and Build Dependencies
By specifying snapshot and artifact dependencies, you can break down a single build procedure into several parts that can be run on different build agents either in sequence or in parallel.
Sometimes resources external to TeamCity cannot be utilised simultaneously by multiple builds.
TeamCity easily handles this by limiting access to your shared resources with just a few clicks in the UI.
George Santayana once said: "Those who cannot learn from history are doomed to repeat it." We believe that keeping a history of builds, changes and failures is crucial to the success of any software development process.
TeamCity stores a lot of information about a build to help you to identify the roots causes of problems faster and access the related results easily.
TeamCity keeps data about build changes, parameters, produced artifacts, statistics metrics, and much more.
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 create your own statistics graphs based on your own statistics values.
You can run a build with source code corresponding to any past change (not taking later changes).
This helps you identify which change caused build failure and produce a build even if someone has just submitted broken code to the repository.
Build Pins, Tags 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 or pin it to prevent build artifacts from cleaning.
Each test in TeamCity has its own history. This history can be observed and can help find the change that broke the test.
For each test, you can also see a graph which shows how test duration changes from build to build.
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 in various ways.
Imagine a conveyor belt of changes from developers and a bunch of testers taking the changes, verifying them and complementing these changes with verification results. TeamCity is such a conveyor, except that testers are replaced with Build Agents.
Multiple Build Agents
Build Agents are computers with installed TeamCity agent software capable of running different types of build scripts.
As developers integrate their work results into the Version Control System, TeamCity server distributes them to the Build Agents automatically.
Build Agents detect and pass to the server a wide range of software (like language interpreters and testing tools) and hardware (like CPU or disk space) parameters which can be utilized in build scripts.
Upon server upgrade or downgrade, Build Agents upgrade or downgrade themselves automatically.
Different projects have different rates of changes. To prevent projects with a higher rate of changes to occupy most of the agents, agents can be divided into different pools, and projects can be assigned to a specific pool.
Build Agents Statistics
TeamCity provides detailed statistics on how build machines are utilized.
With such data at your fingertips, it’s easy to manage your build farm.
Code Quality Tracking
Helping you achieve better code quality on your project is TeamCity’s ultimate purpose.
Duplicate code analysis for Java and .NET
Duplicated code fragments is what makes our code hard to maintain.
Results of other coverage tools can also be imported.
Static code analysis
If you prefer to use other tools, TeamCity supports FxCop out of the box. It can also import reports produced by PMD, PMD/CPD, FindBugs, Checkstyle or JSLint.
Build failure conditions
Each code quality report provides metrics which can be used in build failure conditions.
To avoid degradation of some metrics over time, build failure condition can be configured to fail a build if its quality metrics decreased compared to a previously finished build, or compared to some build selected as the benchmark.
Code quality reports right in your IDE
We strongly believe code quality improvement is a team's everyday job.
To help you do this job well, there are a TeamCity plugins for popular IDEs. For example, TeamCity IntelliJ IDEA plugin can automatlcally download fresh inspection results, duplicated code results and code coverage from the TeamCity server. These results are then shown right in the editor where we modify our code. TeamCity plugins for Visual Studio and Eclipse can show code coverage from server as well.
Not sure whether it is safe to modify these lines of code in a class? Take a look at the coverage.
Seeing duplicated or dead code in the editor? Eliminate it right away!
TeamCity version controls systems integration is comprehensive. It’s hard to imagine a project whose source code couldn’t be retrieved by TeamCity.
Flexible VCS Configuration
TeamCity supports a broad range of version controls out of the box, from the most popular ones to somewhat deprecated but still used systems.
For a single build TeamCity can take source code from several different VCS repositories. You can even mix different types of VCS.
Suppose the majority of your project sources is located in Perforce while several modules are stored in Subversion. TeamCity allows you to configure your project to use sources from both of them simultaneously.
File Diff and Patches
View file differences in TeamCity’s web interface, or download a patch from TeamCity right in your IDE.
Developing with feature branches in Git and Mercurial with TeamCity is extremely simple. Just tell TeamCity which branch names to monitor.
As soon as you push your branch to Git or Mercurial repository, TeamCity will detect it and start a build on your changes.
Enhanced Mercurial Support
TeamCity fully supports Mercurial’s bookmarks and subrepositories. The former could be used as feature branches. From the latter TeamCity gathers and shows changes.
Advanced VCS build triggering
TeamCity constantly scans all of the build configurations’ VCS roots, and triggers builds if changes are
You can configure multiple options for fine-grained control of triggering rules.
Extensibility and Customization
Service message is a specially formatted line of text in the build output which makes the server perform some actions.
Here are just a few things you can do with their help:
- set the status (build failure or success), and change the build status text;
- publish artifacts during the build;
- report successful, failed or ignored tests and custom statistics values.
REST API is another simple way you can interact with TeamCity.
Manage users, projects, builds or artifacts from your scripts, easily integrating TeamCity into your environment
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.
Over 100 ready to use plugins are already available. If you still want to create a new one to make TeamCity even more powerful, use OpenAPI to implement it.
With Open API you can develop integration with version control systems, issue tracking systems, build tools, IDEs, notification programs and server health reports.
Disk Usage Report
Builds produce logs and artifacts, which occupy disk space on the server.
Disk Usage report gives you a clear view of how much space each project takes up, as well as insights on builds with unusually large build logs or artifacts.
Build History Cleanup
TeamCity keeps a history of builds with their artifacts and other data.
To limit the number of builds kept in the history, you can define a cleanup policy for each project or configuration.
Server Health Reports
TeamCity is equipped with a central place where you can monitor the state of your build server.
There you can easily spot different configuration problems: redundant or unused VCS roots, build configurations with large build logs, critical errors, etc.
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.
TeamCity supports many authentication schemes including Windows domain and LDAP.
Even more: you can easily migrate from one authentication scheme to another or mix these schemes together, using all of them at once.
TeamCity users can be organized into groups and can be assigned privileges. Once included in a certain group, a user gets all the roles assigned to the group.
Groups support hierarchy which simplifies user management for large companies.
Each user plays one or more roles in your company. The same is supported in TeamCity: you can assign different roles to users in different projects.
If necessary, standard roles can be edited or new roles can be created.