JetBrains TeamCity Blog

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!

Until today continuous integration for Xcode projects within TeamCity was tedious and error-prone process. All you could do is to configure command line build step in a build configuration, somehow mark agents where Xcode is installed and manually configure agent requirements in build configuration, otherwise your build could go to an agent without Xcode installed and fail. Features like compilation errors recognition and on-the-fly test reporting were not available too.

But today we would like to announce a plugin which should make building Xcode projects much more convenient. The Xcode runner plugin provides dedicated Xcode runner, which brings a lot of goodies:

• user friendly interface
• support for both Xcode 3 and Xcode 4 projects
• automatic on-the-fly reporting of tests started by Xcode build
  
  
  
• automatic detection of Xcode presence on agent
• parsing of Xcode build log and recognition of compilation errors
  
  
  
• hierarchical view for Xcode build log

A couple of notes about user interface. As you can see below, you can select whether you want to build your project with Xcode 3 or Xcode 4. Xcode 3 build is target based, but there is no need to remember exact names of your targets, platforms and SDKs, if you press “Check/Reparse” button, TeamCity will parse Xcode project files and fill in the form with settings from the project, thus making it very easy to configure desired Xcode parameters.

In case of Xcode 4 the process is even simpler, all you need is to specify name of the scheme.

You can download plugin from the plugin page: Xcode runner.
Installation is simple, just put the plugin under <TeamCity data directory>/plugins folder and restart TeamCity server. After that agents will upgrade, and you can start configuring your Xcode build configuration.
The plugin is still in early beta state and can have bugs and usability issues. Feel free to report them to our tracker: http://youtrack.jetbrains.com/issues/TW.
Note that plugin is compatible with TeamCity 7.0, it won’t work with earlier versions.

By the way, as an Objective-C developer you might also be interested to know that JetBrains has recently released a new version of AppCode – a smart IDE for Objective-C developers building native Cocoa apps for MacOS X or iOS with a bunch of new refactorings, enhanced debugger and a lot of other goodies.

Enjoy!

“I see dead code” – .NET developers all over the world know this slogan due to incredible code analysis feature provided by JetBrains ReSharper. One of the most wanted TeamCity features was to have .NET inspections results right on build server. Starting with the latest EAP you have it!

The only thing you need to do to get all the benefits of ReSharper’s analysis right in TeamCity is to add Inspections (.NET) build runner as a build step to your build configuration.

Configuration is quite easy, so let’s just take a look at how the results look when this runner is configured – you can find them at the dedicated “Code Inspections” tab of the build results.

Here we’ve got all the usuall options like exploring overal inspections statistic, opening problematic sources in IDE, viewing inspections description, etc.

Moreover, using this build runner together with another fresh feature – build failure conditions, you can update your builds status based on of inspections results.

What’s next? First of all, in the nearest future it will be possible to share ReSharper inspections settings profile between your team members and use this profile in TeamCity build. More to come, you will be able to ask TeamCity to run custom inspections related to your code base as well.

As always, your comments and feedback are very much welcome. To try it, install TeamCity 7.0 EAP build.

Enjoy!

Previously described Fail build on metric change feature is not the only new way of controlling build status and detecting build failures. In TeamCity 7.0 we introduce one more useful feature that allows to mark build as failed, in case when certain line is met in build log.

Note, that you can instruct TeamCity to look for a line containing or matching a Java Regular Expression regexp text that appears/doesn’t appear during the build. When the condition is set, the interface looks like:

Here’s how a build failure looks when caused by such condition:

The feature is not completed yet, so your comments and feedback are very much welcome. To try it live, install TeamCity 7.0 EAP build, we recommend the next EAP build which is about to be released in the nearest future.

Enjoy!

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 latest TeamCity 6.0 EAP we’ve added new feature to Visual Studio add-in. Now it is tightly integrated with another popular JetBrains product – ReSharper! So if you have both ReSharper 5.0 (or later) and TeamCity add-in installed, you gain the following benefits:

• From the add-in’s Failed Tests tool window you can navigate to source code of a failed test.
• From the same tool window, you can re-run tests failed in a TeamCity build locally with ReSharper.

Note, that by “tests” we mean all kinds of tests supported by TeamCity and ReSharper.

This feature is just the beginning, we plan to greatly improve TeamCity integration with ReSharper, so there’s more features to come. As usual, we’re looking forward to your feedback and all the feature requests are trully appreciated.

Stay tuned!

As you might know, TeamCity comes with such feature as build tags – do not confuse with supported VCS tags, because that’s an entirely different story. You can assign any number of tags for a single build, and then use them to organize your build history, or quickly navigate to the tagged builds. There is nothing tricky about that, but one might ask himself when these tags can be helpful.

Well, here is an example. Suppose, after some time of developing, your project manager decides, that you’ve finally got a stable build that can be considered a release candidate, or eap. He can mark this build with “EAP” tag, and thus, guys from QA won’t need to search through the whole build history to find the build they should carefully look at. They’ll just need to filter the history by this tag, or simply type “EAP” in the search field.


You can also leave a comment on any build, providing some extra notes about it; and just as with the tags, you can later on search for the build by the comment. Hope, you’ll like it.
Feedback is appreciated as usual.

We are glad to announce, that we’ve just opened an Early Access Program for TeamCity 5.1.

Here’s the short list of only some of the improvements and features that today’s EAP brings:

• Customizable email notifications — now you can use FreeMarker templates to create your custom notification messages.
• Several UI improvements, such as collapsible projects on overview page and the most voted one — the ability to specify time zone, which is handy for geographically dispersed teams.
• New Current problems tab is added for a project, that shows which tests are currently failing in this project and which configurations are red.
• Support for .NET 4.0, and not yet released Visual Studio 2010 and TFS 2010.
• Improved support for .NET test frameworks.
• Code coverage support for Maven runner.
• Ability to produce zip and tar.gz artifacts from a bunch of files.
• IDE integration plugins improved.
• read more…

View the detailed release notes, download the build and stay tuned — TeamCity 5.1 won’t take long to appear.

By tradition, we remind you to back up your data before upgrade.

Looking forward to your feedback!

Sincerely,
JetBrains TeamCity team.