JetBrains TeamCity Blog

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!

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.

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!

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.

Read the rest of this entry »

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:

• Webinar Q&A - http://goo.gl/eBifS
• Octopus Deploy – http://www.octopusdeploy.com
• NuGet – http://nuget.org
• Octopus TeamCity add-in – https://github.com/OctopusDeploy/Octopus-TeamCity
• TeamCity sample application – https://github.com/PaulStovell/SilverSardine

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!

While we’re working on TeamCity 8.0 we do not forget to fix bugs in TeamCity 7.1 too. So here comes another bugfix release: 7.1.4. It has about 70 fixes and improvements and is recommended for upgrade to everyone.

It is worth to mention that with this release TeamCity should work correctly with tfspreview.com. The long standing issue with Perforce jobs lost during pre-tested commit in Visual Studio add-in has been fixed too (TW-11196). Finally there were a couple of performance improvements and a bunch of other fixes.

Release notes
Download page

Happy building!

Scenario

You’re running an OSS project* and someone makes a pull request. You’ve got two choices:

• Merge and Pray
• Pull to local branch, build, run tests and merge if all OK

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

Automatically Building All Pull Requests

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.

Configuring TeamCity

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:

Seeing notifications on the Pull Request

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.

Summary

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.

Hello everyone! Today we’re opening EAP for TeamCity 8.0 (code name Gaya) in order to give you some fresh stuff, to play with during weekend.

Let me briefly describe what we’ve done already and share some of our plans for TeamCity 8.0 (we expect it to be released in Spring 2013).

The major feature of TeamCity 8.0 is sub projects, or project groups (see TW-705, yes, a rather old and rather popular request). We hope it will make TeamCity more scalable in terms of information presentation and the notion of project in TeamCity will become a better match to a real life project (what we call a project right now is rather a VCS branch). While moving in this direction in this EAP we’ve changed how project configuration files are stored on the disk and introduced “root project” (a parent for all of the projects in the system), read more.

Another important feature which we’d like to address in 8.0 is import/export of projects and build configurations (TW-4124). It can become really handy for those who have to maintain several TeamCity instances. At first we plan to provide editable IDs for a project, build configuration, template and VCS root. This will allow assigning IDs on one server so that they do not intersect with IDs on another one, thus will simplify moving configuration files among servers. In this EAP we’ve made the first step in this direction — editable project IDs.

We’ve heard complaints from our customers about the cleanup process. Highly loaded TeamCity server can produce thousands of builds and gigabytes of data each day. Not all of this data will be used in the future, and there is an ability to configure cleanup rules to remove garbage from disks and from the database. Unfortunately, not only this operation takes significant time but web interface becomes inaccessible while the cleanup is in progress. In this EAP we’ve made several improvements in this area, read more and let us know how it works for you.

Mixed mode authentication is the last important addition in the first TeamCity 8.0 EAP. It simplifies migration from one authentication scheme to another by allowing usage of more than one authentication module at a time, read more.

There is also a couple of IDE integration features (currently only available in IntelliJ IDEA plugin). These are: already mentioned some time ago remote debug on agent and showing of test status (success, fail, muted, investigated) right in the editor, plus some other smaller improvements.

Please see release notes for complete list of changes.
Download EAP build, and share your feedback with us.

Happy building!