JetBrains TeamCity Blog

This post describes one of the new features in the upcoming TeamCity 8.0

Using TeamCity, we can easily set up a build farm using a central TeamCity server and several connected build agents. By having multiple build agents, we can run builds and build configurations in parallel. Different branches of the same project can build simultaneously on different build agents,  personal builds can be run on one build agent while the nightly build is running on another agent and so on.

But what if we have multiple build agents and we want to constrain parallelism for some projects? What if we do want to have parallelism but want to provide different build variables to each build? Good questions, and the Shared Resources plugin is the answer!

The Shared Resources plugin comes bundled with TeamCity 8.0 EAP. In TeamCity 7.1.x it has to be installed separately. Sources for this plugin are available on GitHub.

Limiting concurrent builds with simple named resources

The Shared Resources plugin works at the project level. Per project, we can specify one or more shared resources which we can use to decide on the number of concurrent builds for a given project and build configuration.

In the Project Home under the Shared Resources tab, we can specify the resources we want to be able to lock. A shared resource should be given a name which can be used later on in our builds. The resource type can be infinite (effectively not limiting build concurrency), a resource with quota and a resource with custom values. Let’s go with resource with quota.

The resource quota is the number of concurrent read locks that can be acquired on the resource. Or in other words: the maximum number of concurrent builds we want to run. Let’s be restrictive and set the quota to 1.

None of the Build Configurations will obey these quota: we have to add a Shared Resources Build Feature to every Build Configuration we want to subject to these quota. This can be done in the Build Configuration. Under Build Features, we can add a Shared Resources build feature which acquires a read or write lock on the shared resource created earlier.

Once added, the build configuration will only be run on one build agent at a time. Personal builds as well as regular builds will all be enqueued and wait for the lock on the shared resource to be released, even if one of the build agents is idle.

Note that it is possible to await multiple locks in a build configuration.

Working with custom resource values

While working with simple named resources may be useful, it may be worth having a custom resource value for every lock acquired. Imagine we have a build which has a custom build step running load tests on a server. Wouldn’t it be nice if we could limit the number of concurrent build based on the number of load test targets available and be able to get the URL to one of these servers in our build? We can using a set of custom resource values.

When creating a new Shared Resource, we can specify the type as a resource with custom values:

In our build, we have several options available to acquire a lock on this shared resource. We can lock on any value that is not locked, we can lock on all values or on a specific value. For our purpose of needing a dedicated load testing machine, we can opt to lock on any available value.

Once added, we will not be able to run more builds concurrently than the number of available values in our custom shared resource. If we need the value of the locked value during our build, we can read it using the %teamcity.locks.<lockType>.<lockName>% variable, %teamcity.locks.readLock.RunTestsAgainstServer% in our case. For example when working with build parameters, we can use the lock value as a custom parameter:

Where can I manage shared resources?

So far we’ve seen that shared resources can be added for every project separately and used in that project’s build configurations. With TeamCity 8.0, we’ve introduced project groups which allows us to group several projects under a project group. Shared resources can be added to both the project group as well as the individual projects. Locks can be acquired for every build configuration in a project and/or project group, making it possible to have shared resources across projects as well.

Do let us know your thoughts via the comments below. Dive in, experiment and… happy building!

BlazeMeter 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.

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!

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

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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

With the rise of Distributed Version Control Systems (DVCS) like Git and Mercurial, the concept of Feature Branching gained a lot of momentum. The basic idea is that whenever you start working on a feature, you take a branch of the repository and commit all changes for the feature onto that branch. Once the feature is ready changes are merged back into the repository.

Working with feature branches comes with great advantages for your team. Each developer can work on their own feature and be isolated from changes going on elsewhere in the project. They can pull in changes from the main repository at their own pace, ensuring they don’t break the flow of building their feature.

But how does this work in a Continuous Integration environment? If your CI server does not support this workflow a number of problems arise, like constant build configurations duplication, poor visibility and in the end loss of control of the process.

With TeamCity 7.1 we’ve introduced dedicated support for feature branches and the workflow around it. All you have to do is to push your branch to a Git or Mercurial repository and TeamCity would detect a new branch in it and start a build on your changes. Without having to duplicate build configurations and so on. Let’s see how we can work with it…

Enabling Feature Branches in TeamCity

Our repository may have a lot of branches and naturally not all of them are feature branches. In TeamCity we can tell the server which branches to watch for changes using branch specification. Under the VCS Root settings for our project, we have to specify a Branch Specification.

Branch specifications have a simple syntax:

+:<branch rule>
-:<branch rule>

The branch specification tells TeamCity to include (+) or exclude (-) a given branch as a feature branch. Here are some examples:

+:* treats every branch as a feature branch
+:refs/heads/feature-* treats all branches with a name starting with feature- as feature branches

Once saved, TeamCity will monitor our repository for changes on the mainline of our repository as well as on branches matching the branch specification rules.

Feature Branch Builds

Once a change is detected in a branch, TeamCity will start a build in this branch. For example, after pushing a set of changes to the feature-wp7 branch in our repository, TeamCity automatically builds this branch for us and displays this new branch and its build status on the projects overview as well as on the build configuration’s branches tab:

Notice TeamCity displays a label wp7 instead of the full feature-wp7 branch name. The reason for that is it checks the branch specification and uses only the part of the branch name marked with *. The label for our branch specification +:refs/heads/feature-* hence yields only the last part of the branch name. There are a some other options available for branch labels on a build if you would like to customize this.

Filtering Branch Builds

If you have a large team or a large number of active feature branches, you may want to filter the branches being displayed on various screens in TeamCity. For example, on the projects overview we can filter based on the branches we’re interested in:

Run custom build

Based on our branch specification, TeamCity allows us to run custom builds for a specific branch. On the Changes tab, we can select the branch to build.

Happy building!

TeamCity supports your Continuous Integration (CI) process in many technologies like Java and .NET. It’s not because we don’t provide other technologies out-of-the-box that you can not make use of them! In this post, we’ll put TeamCity to the test and setup a CI process for a PHP project.

We’ll be using the open-source PHP project PHPExcel as a sample project to set up Continuous Integration using TeamCity. This project features a large amount of code, PHPUnit tests and uses Phing to create build artifacts. We’ll use TeamCity to get this process completely automated and ready for immediate feedback once the source code on GitHub changes.

(more…)

When working with TeamCity, we get a lot of feedback on our continuous integration process. We can see when compilation started, which unit tests passed and which failed. But how much memory do we consume while compiling our software? What is the CPU usage percentage while running our unit tests? This is all  important information for optimizing our build process.

TeamCity provides a build feature called Performance Monitor which gives us exactly that information: it gathers the build agent’s hardware usage statistics during the build and presents it on a separate tab of the build results page.

To enable Performance Monitor for a build configuration we have to go to the configuration’s build steps. Under Additional Build Features, we can use the Add build feature button, select Performance Monitor from the list and click Save to enable this feature.

Note that Performance Monitor reports the load of the entire operating system. This means that running more than one build agent on the host, running agent and server on the same host or running other workloads on the server will yield unreliable data.

We can enable Performance Monitor on build agents running Windows, Linux, Solaris and MacOS X operating systems. Once enabled, every new build that is triggered will produce an interactive chart with performance details under the new PerfMon tab for that build.

The data shown consists of 3 key metrics (CPU usage, disk load factor and memory usage) and can be related to an exact point in the build log. When we click on a CPU usage data point for example, we can clearly see what the build agent was executing at that point in time.

The information displayed can be used to find bottlenecks, understand possible hardware upgrade impact, discovering suspicious periods in the build when nothing happens and so on. For example, consider the following performance chart:

When we click on the “25s” next to the Run Tests build stage, a chart overlay appears which visualizes the duration of running unit tests. From the picture it is clear that at some point CPU and disk usage is very low, near zero in fact. This lasts for a number of seconds. It is worth analyzing the unit tests that were running during this period: they are probably blocked on some lock, waiting for an operation to return or something similar.

Consider another performance chart:

We can see from this chart that the CPU usage is 100% almost all the time.  It’s probably worth investigating if the build agent could benefit from a CPU upgrade.

The Performance Monitor build feature can reveal high-level information that may hint an underlying issue in your build process.

Happy building!