TeamCity User Guide Courseware

We have created a TeamCity User Guide as a series of screencasts.

TeamCity User Guide

An outline of the table of contents is:

The entire course duration is under an hour. You can view it entirely for free either on JetBrainsTV or on our YouTube Channel. Enjoy!

Posted in How-To's | Leave a comment

Typed Parameters and Continuous Deployment

As I hope you’ve had a chance to see for yourself, TeamCity is an excellent tool for continuous integration used as a core ingredient in the continuous deployment process by many teams and greatly loved for its cool features, flexibility in customization and plugins. This post doesn’t aim at covering all aspects of continuous deployment with TeamCity; today I’d like to focus on a powerful feature and yet not widely known feature: typed parameters.

Many of you have run a custom build at least once. If you’re not sure what a custom build is, you are welcome to visit our documentation for details. In short, a custom build is a build with modified parameters; it can be run from the Custom Build dialog:

Typed parameters is a simple user-friendly approach to customizing the Custom Build dialog behavior. Let’s go over a few scenarios to see how these parameters work.

Scenario 1: Accidental deployments

We’ve all had a few cases when we started a deployment process by mistake, accidentally clicking the Run button. It’s a good thing these deployments didn’t cause any errors or outages, but how do we prevent such behavior in the future? Just follow the steps below:

Go to the Build parameters step:

Click Add new parameter and then the Edit button:

Set Display to prompt. In this case TeamCity will always ask to review the value and choose the Checkbox type.

Next, modify your deployment script to execute only if the value is true and that’s it! No more space for mistakes! Now start a manual build by clicking Run Build.

Scenario 2: Authorization by password

When a third-party provider hosting our service doesn’t provide authentication by key, it means we have to enter the username and password every time we deploy a new version. That’s a pain, since our internal policies allow us to keep the username in the configuration files but not a password. Moreover, we don’t want the password from the server to appear anywhere in the user interface or build logs. Let’s see how we can we handle this.

Add a new parameter – Password, click Edit, choose the Password type:

and click Run.

Problem solved!

Note: TeamCity tries hard not to reveal the actual value of  the password type parameter by filtering it out from the build log and other places. Check our documentation for more details.

Scenario 3: Deployment to different servers

We deploy a new version of our service in three steps:

  1. To internal users
  2. To beta testers
  3. To all users

Our deployment system accepts the stage parameter with the following values: internalbeta and all. If the value is not from the described set, the deployment process will fail. Certainly, a person starting the deployment step can change the parameter’s value in Properties tab, but what if they make a mistake? Or simply forget to change the value? Here is how we can prevent it:

Add a new parameter - stage, click Edit, choose the Select type and add options.

Click Save and start the build.

Select, checkbox and password are not the only possible options: Text field with Regexp pattern validation is also available. Read our documentation to find out the details.

Hopefully, I managed to demonstrate that a custom build backed by typed parameters is indeed a powerful way to set up the process you need. This post is just an introduction which should help you to get to know TeamCity better.

Dig deeper, experiment and … happy building!

Posted in Tips&Tricks | Leave a comment

TeamCity 8.0 EAP (build 27147)

More than a month passed from last TeamCity EAP and we’re glad to disclose what have been done. Multiple improvements were made to the functionality we introduced in previous EAPs.

Project groups

We continue to integrate groups of projects into TeamCity. When new version is out we promise you won’t believe that there was no allusion to the groups in TeamCity just a few months before. Check an incomplete list of the places which are aware of sub-projects now:

  • Project hierarchy is shown on Administration|Projects page;
  • Projects hierarchy is shown in all drop downs where a list of projects or configurations is displayed;
  • Notification rule defined for a project will be effective for sub-projects too;
  • It is possible to define cleanup rules for projects. These cleanup rules are default ones for build configurations from this project and its sub-projects.

Get a full list of changes in release notes.


Meta Runner is a powerful feature providing a promising new way for customizing TeamCity and making it even more people-oriented. To understand it, let’s consider an example.

Imagine you have some repeated task used over and over again across different build configurations. The task is defined as one or more build steps, based on built-in runners, like Ant or command line. Most likely you’d want to reuse this task easily across several build configurations. You can’t do this with templates because template enforces you to share the same settings across different configurations which is not always possible. A solution which we propose is to extract Meta-runner out of these steps, see how it works in release notes.

External IDs and projects transfer

External IDs will help to simplify import/export of projects and build configurations. We introduced them one EAP ago made some improvements from last time:

  • it’s possible to define external ID for build configuration and template;
  • external ID can be used in HTTP and REST requests;
  • external IDs are stored in project configuration files, not internal ones.

Read more about external IDs in release notes.

Disk Usage Report

Disk Usage is now integrated with Server Health. New report, based on disk usage, show configurations with large build log files which are rarely useful because it’s difficult to analyze them. Read more on this report in release notes.

Queued Build page

Dependencies progress has been added and you can see estimates for all dependencies in one place now.

Please, try new EAP and tell us about your experience. You can find a full list of changes in release notes.

Happy building!

Posted in EAP | 4 Comments

Mercurial bookmarks

First TeamCity 8.0 EAP brought a Mercurial bookmarks support. Let’s see how you can use them with TeamCity.

Mercurial bookmarks are lightweight branches like those you have in Git. While a regular Mercurial branch is a property of a commit and cannot be changed once commit is published, bookmarks can be changed in any way you want: you can add bookmarks to existing commit, you can change the commit a bookmark points to, you can easily delete a bookmark and most importantly you can share them with others. If you are new to bookmarks this tutorial might be useful.

In TeamCity bookmarks can be used in branch and branch specification fields of VCS root settings just like regular branches.

I can see the following uses of bookmarks:

  • feature branches with bookmarks
  • using bookmarks to narrow changes detected by TeamCity

Feature branches with bookmarks

You can share you work with others (and with TeamCity) by pushing bookmarks to a Mercurial server. There is one caveat though. Since every commit still has a branch, this branch becomes multiheaded. It doesn’t make sence to track such a branch in TeamCity since its current revision is the latest pushed head and it constantly changes. It’s better to create a bookmark, e.g. main, which points to the tip of mainline of development, use it in the branch field and exclude the regular branch in which you create bookmarks from branch specification.

Narrowing detected changes

Let’s say you use regular Mercurial branches to share work with your peers and you have several dozens of branches. Let’s also say that you don’t work on a single branch until it is completely finished, but frequently switch between branches. You have +:* in your branch specification and TeamCity detected all of your branches.

The problem is: your complete build chain, which tests the product on different platforms under different environments, takes half a day to run and you don’t want to waste resources by running build on not yet finished work. On the other hand, you want to publish your work so other can use it. Bookmarks to rescue! All you need is to modify your branch specification to something like +:(*)@ci and publish a bookmark with an appropriate name, such as new.feature@ci, that points to the branch tip once the branch is ready for the build. You can continue to share you work using regular branches and TeamCity will detect only changes you want it to detect.

As you can see, bookmarks can help to implement some useful workflows. All you need to try them is Mercurial 2.4 installed on TeamCity server and of course your Mercurial server should support bookmarks. If you have any other interesting workflows – feel free to share them in the comments. Happy branching!

Posted in Tips&Tricks | 1 Comment

TeamCity 7.1.5 is finally available

It took us more than 2 months to prepare one more bugfix release. Most of the team are busy working on TeamCity 8.0 but bugfixing is definitely never ending story :) So here is one more bugfix release in 7.1.x branch: 7.1.5 build #24400. As usual there are a lot of bug fixes and several performance improvements. If you’re using 7.1.x version we recommend to upgrade your server to 7.1.5.

Release notes
Download page

BTW, expect new 8.0 EAP build in a few days with some interesting features!

Happy building!

Posted in Tips&Tricks | Leave a comment

Love TeamCity? Make it better!

Have you ever asked yourself why TeamCity is so cool? We found the answer a long time ago. TeamCity is great because of you, our users. You constantly suggest improvements, report bugs and discuss new functionality. Every time your energy and involvement motivate us to do our job better than we did before.

Documentation is an essential part of any product and TeamCity is not an exception. We constantly improve the documentation and make it more valuable to you. On the other hand, we know there’s a wide field for improvements and some important topics are missed.

With new TeamCity 8.0 on its way we think time for change has come. We start reworking the documentation and we invite you to help us with it again. We’d love to hear what you do not like or miss in current documentation or you missed when you opened it for a first time.

Leave your mark in history by commenting here or in opened issue.

Help us to become better and… happy building!

Posted in News & Events, Uncategorized | 7 Comments

Load Testing with TeamCity and BlazeMeter

imageBlazeMeter is a cloud-based load testing platform for web applications, mobile applications and web services. It can be used to simulate heavy loads on a server and analyze performance under different load types. And since there’s a TeamCity plugin for BlazeMeter available, we can use it to load test or smoke test our application during the build and deployment process.

Installing and configuring the plugin

The BlazeMeter plugin for TeamCity can be downloaded and installed into the plugins folder under TeamCity’s data folder. After restarting the TeamCity server, there is one additional step in order to be able to start using the BlazeMeter plugin for TeamCity: configuring it with our BlazeMeter user key.

Under Administration | Integrations | BlazeMeter, we can enter the user key obtained from the BlazeMeter web site (under user profile).


Adding a BlazeMeter build step to a build configuration

To run a load test using BlazeMeter after building and deploying an application, we can add a new build step to our build configuration. The BlazeMeter plugin for TeamCity adds a new build runner type which we can select.


The BlazeMeter plugin for TeamCity will list all available load tests in the build step configuration. We can select the test to run and specify the error percentage and response time thresholds. The total load test duration should also be specified.


Once saved, we can run a build configuration and see load test results come in.

Inspecting load test results

After running a build configuration in which BlazeMeter is used, we will see a new report tab on the build results page: BlazeMeter Report Tab. Using this, we can analyze results of the load test run during this build.


From this tab, we can analyze the load test results, see errors that occurred in the application during the load test run, see measured page load times and so on. We can also compare with previous load test results if needed.

A short screencast on installing and configuring the BlazeMeter plugin for TeamCity is also available.

Posted in How-To's | Tagged , , , , | 1 Comment

Continuous Integration and Delivery – Professional Courses with Paul Stack

In partnership with JetBrains and Skills Matter, Paul Stack will be running several Continuous Integration and Continuous Delivery courses at Fleet Street – London. Each two-day course consists of a mixture of lectures, hands-on labs and practical exercises.  Registration is open for the following dates:

  • April 9-10, July 3-4, September 2-3, and November 25-26

The cost of a two-day course is £1195.00 but if you book early, the price is discounted to £1075.00.

About the Course:

Continuous Integration is a fundamental pillar of running an Agile project. Knowing whether the latest checkins make or break the project and being able to fix mistakes quickly is important to reduce costs and avoid problems in the long run. In addition, with the recent popularity of continuous delivery and continuous deployment, it is becoming even more common to ship fixes and features to customers more quickly.

However, putting this all in place not only requires knowledge of techniques and tools but also a shift in mindset throughout the team and organization.

Learning how to cope with these changes, understanding how to work efficiently with tools and putting in place good practices for CI/CD can have a drastic improvement on your project, team and organization.

You will:

  • Learn about the CI/CD process and the parts involved
  • Find out how to work efficiently with tools and techniques to minimize setup costs and running operations
  • Discover new techniques being applied to improve CI
  • Understand how to deal with the change in mindset

About Course Author, Paul Stack:

Paul is an advocate of clean, maintainable code and very passionate about what he does. He is absolutely obsessed with Continuous Integration and how it should be used in everyday development scenarios. You can follow him on twitter @stack72 or read more about him on his blog. Paul is also a member of JetBrains Development Academy.

For complete details and registration, visit the official course page Continuous Integration and Delivery, on

Posted in Tips&Tricks | 2 Comments

TeamCity plugin for Visual Studio

When working with TeamCity and Visual Studio, we can do a lot of things right from within our IDE. We can trigger a remote run, fetch dotCover code coverage information from the server, view changes and builds from a tool window, navigate to unit tests and a lot more. In this post, we’ll be looking at some of these features. But first things first: let’s install this nifty tool!

Installing the plugin

Every TeamCity installation ships with several tools for IDE integration (with our IntelliJ IDEA based tools as well as with Visual Studio). We can find the plugin on every TeamCity server under the My Settings & Tools page. We can download the plugin right there!

Finding the TeamCity plugin for Visual Studio

After downloading and installing the plugin, we can find a new menu item in our Visual Studio.

TeamCity plugin for Visual Studio menu entry

From this menu, we can connect to our TeamCity server using the Login… menu item. After entering the URL to our TeamCity server and providing the correct credentials, we can start exploring.

Login to TeamCity

Remote run from Visual Studio

When developing a project in Visual Studio, we can initiate a personal build using the TeamCity plugin for Visual Studio. We call this a “remote run” because the build that is triggered runs on a TeamCity build agent, not on the developer’s machine. The interesting thing here is that this remote build uses the current version control repository sources plus the changed files in the developer’s IDE. All steps from the build configuration are executed for this personal build as well.

After changing some files locally, we can use the TeamCity | Remote Run (Local Changes) menu to trigger a remote build. In the dialog that opens, we can select the changes we made locally that should be included in this personal build. We can select all changes or cherry-pick just the changes we want to verify on the build server.

Note that we’re using Subversion as the source control system here. Remote Run is available for TFS, Subversion and Perforce. When using Git or Mercurial, the workflow is slightly different. Check the documentation on branch remote run for more information.

When we click the Configure personal build… icon in the toolbar, we have to make some other decisions. First of all, we must select the build configuration we want to use for the personal build. Next, we can provide a comment for this personal build. This comment will be shown in the TeamCity web UI afterwards to describe the personal build.

One interesting option is the Pre-tested Commit checkbox and its related commit if setting. Using this, submitted code changes first go through testing. If all tests pass, TeamCity will automatically commit the changes to version control and integrate it in the next build. When tests fail, the code is not committed and the developer who made the change is notified about this. Here’s a chart of the pre-tested commit workflow.

Personal build configuration and pre-tested commit

We can even customize our build: put it at the top of the queue or add additional build parameters.

After clicking the Run button, TeamCity will run the selected build configuration for the included changes. We can see the results in the TeamCity web UI, consult the build log, check unit test results and so on.

TeamCity web UI personal build

My Changes

Since this post is about the TeamCity plugin for Visual Studio, we can also verify the status of builds triggered because of our changes by using the TeamCity | My Changes menu.

Overview of My Changes

Build log

From the toolbar, we can consult the build log for every personal build listed in the My Changes window. Clicking the Show Build Log icon (or right-clicking the build and selecting the appropriate context menu) will instruct the TeamCity plugin for Visual Studio to download the build log directly from TeamCity.

Build log from TeamCity downloaded in Visual Studio

Open Failed Tests

Did your changes cause a unit test to fail? No worries: we can use the Open Failed Tests context menu from the My Changes window in order to see what is going on. From the window that opens we can re-run the failing tests locally using the ReSharper test runner.

Unit tests

Code Coverage

When you have dotCover installed on your machine, the TeamCity plugin for Visual Studio enables us to view code coverage results. Using the TeamCity | Coverage menu item we can select a code coverage snapshot to open.

TeamCity dotCover code coverage

After selecting and opening a snapshot, we get dotCover’s test runner showing code coverage. We can even double-click a class from the snapshot shown and explore code coverage at the statement level.

dotCover snapshot from TeamCity

Investigate a build

Whenever a build fails, we can volunteer to fix the build by starting an investigation. From the TeamCity | My Investigations menu, we can manage our investigations and take action on open investigations by either fixing it or giving up (when working in developer teams in Belgium, that last option typically results in having to bring pastries for the team).

Investigate a build

Open in IDE

The TeamCity web UI features an Open in IDE button on many places. For example, when inspecting changes that were included in a build, we can open the file that was built in our IDE by clicking the IDE icon.

Open in IDE from TeamCity web UI

We can open tests in the IDE as well, again using the Open in IDE function. When working with tests, this will trigger Visual Studio to open the ReSharper test runner and display the selected test.

Open test in IDE

Give the TeamCity plugin for Visual Studio a go and let us know what you think!

Posted in Features, How-To's, Tips&Tricks | Tagged , , , , | 6 Comments

TeamCity 8.0 EAP (build 26984)

Hello everybody!

New TeamCity 8.0 EAP is waiting for you to try. This build contains several improvements and new features which make TeamCity an ultimate choice for large installations.

Project groups

When this major feature was introduced, there were only a few visible changes such as appearance of “root” project and a new storage scheme for project configuration files. This time we’ve made a big step forward and you can feel the power of this long-awaited functionality. You can create, move sub-projects, organize them into a hierarchy.

Parameters and VCS roots are inherited from parent projects so new configuration variants like definition of global parameter (TW-11202) are easily utilized. It’s also worth mentioning that shared resources plugin is aware of project groups too.

Disk Usage and Server Health pages

TeamCity takes care about all groups of its users, though server administrators, probably, got less attention before than developers or build engineers. This version is called upon to destroy current gap. Mixing authorization mode and improvements in cleanup appeared earlier, now it’s time for server health and disk usage reports. They help you identify many server-related problems faster, including issues with databases, disk, VSC and configuration files.

Disk Usage page

VCS worker (experimental)

TeamCity is a very popular tool for building projects with large source code base which may require hours to checkout. This process could slow down server responsiveness and decrease server reliability due to VCS-specific problems. To resolve these issues, we’ve moved functions responsible for communication with code source repositories to a separate service – VCS worker. The workers give you a lot of flexibility in routing VCS requests and discovering CPU or memory issues related to VCS operations.
This feature is experimental and turned off by default. We’ll be glad to hear your feedback on it. Please, read release notes if you want to know more.

.NET Inspections

After .NET code analysis was introduced more than a year ago, we constantly improved it, making it more precise and useful. New full MSBuild model support removes a bunch of bugs causing wrong errors detections in code which was checked successfully by ReSharper and is absolutely clean.

Support of Mercurial sub-repositories

Sub-repositories in Mercurial is rather popular feature so DVCS support in TeamCity wouldn’t be full without it. From this EAP, TeamCity can retrieve changes from sub-repositories (including embedded ones) and shows them with other code changes.

Other features

  • investigation and muting of build problems ,
  • better shared resources,
  • new queued builds page,
  • ability to remove build
  • and more.

Please, try new EAP and tell us about your experience. You can find a full list of changes in release notes.

Happy building!

Posted in EAP | 4 Comments