We have created a TeamCity User Guide as a series of screencasts.
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!
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.
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).
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.
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!
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.
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.
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.
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.
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.
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.
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).
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!
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.
The recording of our February 12th webinar, Deployment Automation with Octopus Deploy and TeamCity, is now available on JetBrains.tv and YouTube. We would like to thank Paul Stovell for the great session and Paul Stack for helping moderate and answer the large volume of questions. To all of the attendees of the webinar, your attention and participation was simply wonderful. Thank you too.
About This Webinar:
You’re probably familiar with building and testing code in TeamCity, but how do you deploy the built artifacts? How do you promote your deployments between development, test, staging and production environments, while keeping the process reliable, automated and secure? Octopus Deploy can help to solve this problem, by integrating with TeamCity to push your changes out into production.
In this session, Paul Stovell walks through the process of building, testing, packaging and deploying an ASP.NET web applications and Windows Services into different environments using Octopus Deploy and TeamCity.
Additional Resources:
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!
You’re running an OSS project* and someone makes a pull request. You’ve got two choices:
What do you do? Well, what is it going to be?
I know what I’d like to do, and GitHub makes it so so tempting:
But unfortunately I go with the second option.
That’s a pain, specially if you do a quick code-review and things look decent. Yet you still need to make sure that it builds and all tests pass.
Well there is a third way. And what’s even nicer, is that it’s also possible with TeamCity.
*This applies to non-OSS too
What I want to do is have TeamCity automatically build all Pull Requests for me of my main repository, and notify me if it is successful. And I want this to happen without me having to configure every single fork as a repository in TeamCity, because like that, it wouldn’t be manageable. Here’s a diagram explaining it:
This will drastically improve the workflow since we no longer have to manually create a local branch of the pull request, check it, build it and only then merge it.
Setting up TeamCity to do this is really simple. It actually only requires one thing: configuring the Branch Specification under the VCS root:
Let’s see what this means and why it works. When a pull request is made, GitHub automatically creates a reference that holds the pull request as well as one that is a merge with the master branch. What we’re saying to TeamCity is to monitor this branch, in addition to the main branch. In this syntax, pull refers to the pull request. The * refers to ANY pull request, and the merge indicates that we’re interested in the pull request merged with the master branch. This means that when TeamCity builds, it will build the branch that was merged. If we want to build the branch, without merging, we could use the following:
+:refs/pull/*/head
So to recap, adding merge builds the result of the merge, and adding head, just the pull request without the merge.
The result of these builds show up in TeamCity like so:
where the number denotes the pull request. Now, we can actually make this a bit nicer by allowing us to see whether the particular request was the result of a merge or just the branch itself. For that, we can specify the following in the Branch Specification
with TeamCity now indicating whether this was a merge or head:
In addition, TeamCity also provides us with a Dropdown, where we can filter all the different pull requests:
As this is a normal build, like any other build, we can configure TeamCity to receive notifications via email, tray icon, etc, both on successful builds as well as failed builds. However, there is one other thing that we can do: see the result of the build on the Pull Request page on GitHub. In order for this to happen, we do need to install a plugin for TeamCity which currently doesn’t ship out of the box. This plugin, written by Eugene Petrenko uses some hooks GitHub provides to add notification information on the Pull Request page.
To install it, download the plugin as a zip file and place it in the plugins folder of the server and restart the server.
Once that’s installed, we can now display build status information on the GitHub pull request by adding a Build Feature to our Build Steps:
and filling in some simple configuration parameters:
And with that, we can see the status on the Pull Request page on GitHub.
* If you’re running your OSS project on TeamCity at CodeBetter, you now have this plugin available.
Although my example was based on TeamCity 8.0 which is currently in EAP, this feature also works with TeamCity 7.1.3+ (and even previously covered by others). The examples are also based on OSS projects, but you can apply the same workflow to private repositories also, hopefully making things a little bit easier.
You’re probably familiar with building and testing code in TeamCity, but how do you deploy the built artifacts? How do you promote your deployments between development, test, staging and production environments, while keeping the process reliable, automated and secure? Octopus Deploy can help to solve this problem, by integrating with TeamCity to push your changes out into production.
In this session, Paul will walk through the process of building, testing, packaging and deploying an ASP.NET web applications and Windows Services into different environments using Octopus Deploy and TeamCity. This free webinar will take place Tuesday, February 12th from 15:00 – 16:00 CET (Central European Time). Space is limited; please register now.
About Paul Stovell
Paul is a .NET developer and founder of Octopus Deploy, an automated release management solution for developers on the .NET stack. Paul built the product in 2011 with a goal of making repeatable, automated deployments easy. Prior to working full time on Octopus, Paul spent years as a developer, consultant and trainer focussed on WPF, ASP.NET MVC and application architecture, working in industries ranging from investment banking to health care to mining. He is a Microsoft MVP for WPF, and has spoken at many user groups, code camps and Microsoft conferences around Australia. Paul recently returned to Australia after a year of working in London.
This isn’t a brand new feature, but one might not yet know that besides email, Jabber, rss, IDE and Windows tray notifications, you can configure TeamCity to sent notifications about builds status via Google Talk instead of Jabber.
The only thing you need to do is to set the following options on the Administration | Server Configuration | Jabber Notifier tab:
talk.google.comNote, that if you use Google Apps for domain, you should specify full username with domain part in the Server user field. Naturally, these settings are available only for System Administrators.
As with the rest notifiers, you can tune up the messages sent: the FreeMarker templates used for generating them are fully customizable (refer to our docs for the details).
Once this is done, a user will need only to specify his account and notification rules at My Settings&Tools | Jabber notifier tab to subscribe to Google Talk notifications.
Enjoy!
It’s quite a typical case when you need to create several more or less similar build configurations in TeamCity, for example, to run builds in different environments, or create a separate build configuration for release builds, etc. Of course, you can simply copy build configurations, but what if you’ll need to change, for example, a VCS root in all of them? Naturally, you’ll have to manually change it in every configuration. Don’t you think it’s too much of routine work? We thought so too, that’s why in TeamCity there are build configuration templates. You can create a template with common (shared) settings and then inherit any number of build configurations from this template, or you can extract a template from any of your existing build configurations. Thus, when you’ll need to change some setting in all template-based configurations, you’ll just change it in the template.
One might ask what to do if you need to override a setting inherited from a template in one of the build configurations. If your template defines a specific value for this setting, every template-based configuration will have the same value and since it’s inherited it’ll be a display-only field. But there’s a trick! You can use a configuration parameter instead of an actual value in the template. Basically, such parameter is used inside TeamCity only, and it is not passed to an actual build, but it provides you with means to make your templates flexible.
Here’s an example to illustrate how it works. Let’s say I need to redefine Maven goals in my build configurations based on the same template. In the template settings, instead of actual goals I’ll introduce a configuration parameter:
Note, the syntax here is elementary – %ParameterName%. Now, if I’ll go to the Properties and Environment Variables section, I’ll see there this configuration parameter.
I can define a default value for goals, or leave it as is – in this case I’ll have to define it in every child configuration manually. Let’s say, the default should be test.
Now, I’ll switch to the build configuration based on this template where I’d like to have deploy goal instead of test, and redefine it there.
In our docs, you’ll find the list of settings that can and cannot be overridden with configuration templates. However that’s not the only use case for the configuration parameters. Now they are also used as some of the agent’s parameters, for example for .NET Framework/SDK/Visual Studio/Mono detected on an agent. These we’ll describe in detail in the next post, so stay tuned!
Twitts about TeamCity