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.

As we promised, we continue the configuration parameters story started in the previous post. Today, I’d like to tell you about .NET related properties.
TeamCity .NET plugins provide a bunch of predefined properties indicating that .NET Framework/SDK/Visual Studio/Mono are detected on build agent. Previously you could refer to these properties as to system properties. Now we’ve changed it.

We decided to turn all these properties into configuration parameters, and therefore we’ve converted all refernces to such properties detected in TeamCity to keep builds running. However, it’s not possible to convert references used from a build script. To workaroud the issue you can add system property in build agent configuration or use compatibility mode switch in TeamCity properties:

• teamcity.dotnet.properties.compatibility.mode with value true
• dotNetPropertiesCompatibilityMode configuration parameter with value true in a build configuration settings.

Here is the list of changed parameters:

Note, there will no longer reported .NET Framework configuration parameters without explicit bitness (i.e. x86 or x64).

In the first TeamCity 6.0 EAP you can find the long-awaited feature — build priorities; you asked — we did it. Moreover, since it is implemented as a Build Queue Priorities plugin for TeamCity, it is also available for TeamCity 5.1.x.

Now you can control build priorities by creating so-called Priority Classes — in two words, a priority class is a set of build configurations with a specified priority. Naturally, these classes can be configured from the Build Queue page, but note that only users with System administrator role can access these settings.

You can add as many priority classes as you need, add build configurations to them according to your needs and define the priority in the range -100..100. This setting is taken into account only when a build is added to the queue. The builds with higher priority will have more chances to appear at the top of the queue; however, you shouldn’t worry that the build with lower priority won’t ever run. If a build spent long enough in the queue, it won’t be outrun even by builds with higher priority.

Also note that by default you already have two predefined priority classes — Personal (priority=10) and Default(priority=0).
The first one is used for personal builds (Remote run or Pre-tested commit) only, i.e. any personal build added to the queue will be assigned to this priority class. The Default class simply includes all the builds not associated with any other class. This allows to create a class with priority lower than default and place some builds to the bottom of the queue.

We’ve had a lot of discussions about this feature, because there were many ways to implement it. We picked the one that seems the best, however we encourage you to try it and share your feedback with us. Try it!

The JetBrains TeamCity Team

TeamCity provides several ways of getting notified about your builds’ status, like e-mail notifications, Jabber/XMPP instant messages and more. All the notifiers allow flexible customization to fit your needs.

However, there are other ways to keep track of your projects. For example, Scott Cowan has created TeamCity Twitter Notifier plugin. The installation is easy, and providing that Twitter allows to create private accounts, you can keep project notifications both restrictive and accessible. So if you like to twit, give it a try!

By the way, check the list of the plugins for TeamCity – you may find something interesting for you, or try to create your own.

Sincerely,
The JetBrains TeamCity Team