TeamCity Blog

As soon as you have implemented continuous building and testing practice in your company, TeamCity starts accumulating the building process’ data such as developers’ code modifications, artifacts and so on. To help you get rid of redundant data and keep server disk space reasonable, we have a clean-up policy for the projects and build configurations.

A clean-up policy is in fact a set of rules which defines which data will be removed and from particular builds. It includes:

• a number of successful builds of the particular build configuration to be kept,
• builds’ data to be removed from history,
• a time period the builds to be preserved in history.

You can also specify the so-called default rule which will be applied to all configurations and projects and override it with more appropriate rule in specific configurations. To keep some build away from the cleanup process you can use the pin build feature.

To set the clean-up policy, navigate to Administration and click the link:

On the page that opens, click the Add clean-up rule button and select the build configuration for which you want to apply the rule:

Then you can specify:

• the data to be removed (available since the last TC 3.1 EAP build),
• the types of builds the rule will be applied to.

In TeamCity 3.0 both the build and its artifacts were removed from history. Now you can choose between three new options and specify the data to be cleaned for each build configuration more precisely:

• remove artifacts only (keep history and statistics)
• remove build from history but keep statistics (build will still be shown on the TeamCity statistical charts but you won’t be able to browse build results)
• remove everything

Use two other options to specify the age of the builds the rule is going to be applied to and the number of successful builds to be kept in history. If you can select both options, and the builds meeting both conditions will be cleaned.

We are sure this feature will allow you to optimize the server space usage on a long run.

Technorati tags: TeamCity, JetBrains, Java, clean-up, .NET, IntelliJ IDEA, continuous integration, build management, agile development, best practices, MS Visual Studio 2003, Eclipse

In TeamCity 3.1 we are going to provide more visual metrics, namely, statistics for TeamCity’s Build Agents’ activity and their usage during a particular period of time.

Click the Agents tab and then go to the Agent Statistics tab to get an overview of the Agents’ workload:

When you mouse over the fancy-looking stripes, you can see the builds-related info such as their number, duration, and results in a popup.

Of course, the page view is customizable and you can specify the time range and sort the Build Agents display by their name and workload.

We hope you’ll find this feature helpful in:

• your daily administration activities for leveraging your company’s Build Grid
• bridging the gap between the most frequently used computers and those which are often idle and, finally,
• lowering the cost of your hardware resources ownership.

Technorati tags: TeamCity, JetBrains, , Build Grid, , Build Agent, IntelliJ IDEA, Eclipse, continuous integration, build management, agile development, MS Visual Studio 2005, MS Visual Studio 2008

Even though the software development team many comprise of highly-motivated professionals, they can still introduce inconsistencies in their code, and both the builds and the project code base can break from time to time. When it happens, it may take a while to figure out what the problem is and whose code is the cause of the build failure. Precious time is lost while trying to find out what is wrong. The team members can also assume someone else is on top of things but in reality nothing is done.

TeamCity’s take responsibility feature can help in such situations. When a build fails and the team members don’t take any actions, it is visible on TeamCity’s web interface, and team members can be notified on the fact setting up flexible notification rules.
A developer who broke the build can take responsibility either on the web and from within the IDE:

As soon as the fix is done, TeamCity automatically informs on that.

If the developer discovers that his code is OK and it’s somebody else’s fault, he or she can give up the responsibility and, again, the fact becomes evident to others. As soon as someone else states that it’s his fault, the team is notified on that via different notification means:

A result? Face-to-face communication but the team organizes itself, and nobody from the outside dictates what to do. Moreover, you get rid of the “broken window” syndrome, and the builds’ problems are not your team’s morale breakers anymore.

Technorati tags: TeamCity, JetBrains, IntelliJ IDEA, Eclipse, continuous integration, build management, agile development, MS Visual Studio 2005, MS Visual Studio 2008

When we just started developing TeamCity, we decided to make it as open and easy-to-contribute as possible and allow anyone to develop and deploy custom server-side and build agent’s plugins and extend it in different areas to fit the needs of a project and team.

Let’s dig into adding custom reports into the most frequently accessed place in TeamCity’s UI – Build Results page. This can be easily done by:

1. specifying a report as a build artifact
2. modifying the build configuration so that TeamCity displays a report when a new artifact

And voilà! you get brand-new tab on the Build Results page showing your report.

Besides, it is possible to modify the builds’ status information and the status text.

For the builds’ statistics feature, which appeared in TeamCity 3.0 , you can add custom statistic graphs. Just provide the required data in teamcity-info.xml and describe the new graphs in main-config.xml file and access new statistics charts in the Statistics tab of the build configuration page.

Bluewire Technologies (thank you very much again!) has recently shared their experience on including third-party reports in the Build Results page and publishing custom data from the build i.e. number of unit tests which have passed or failed.

More details on customizing the Build Results page are as usually available in TeamCity online reference.

Technorati tags: TeamCity, pre-tested commit JetBrains, IntelliJ IDEA, Eclispe, continuous integration, build management, agile development, , revision, vcs, MS Visual Studio 2005, MS Visual Studio 2008

We wrote about the pre-tested commit quite a time ago, and we are sure that many developers use the feature though we would still like to point out at some of its pros again and share the feature reviews which appeared recently.
To begin with, let’s state these quite common issues which many developers encounter every day:

• unit tests if run locally can take very long
• when submitted to the project repository, tests can break the build, and the team’s work can slow down

When we developed the concept of pre-tested commit we decided to have the things go its usual way: you code in the IDE but the standard scenario of testing your changes is changed. Pre-tested commit lets you run a full build with tests on some of TeamCity’s Build Agents. Builds created during pre-tested commit are tested across multiple platforms and test suites.

This is an IDE-independent operation that frees your computer’s resources and imitates checking in your changes but does not upload them into the version control until the build is successful. Meanwhile (while your build is created) you can modify the same piece of code, add new tests, and so on.

If some other team member commits changes and they conflict with yours, the IDE shows a warning, and the commit is not performed.

The build may fail, though all tests pass, and you can force commit your changes but still be sure the situation is under control because the integration plugins remember your code state when a pre-tested commit was initiated.
Performing pre-tested commit you always have clean code in the code base and spend less time to discover the integration issues and the project just moves on in its rhythm.
At the moment you can perform pre-tested commit (with slight differences) from three IDE’s:

• Eclipse
• IntelliJ IDEA 7.0
• Microsoft Visual Studio 2005 and 2008

If you are still thinking whether to upgrade to TeamCity 3.0 we want to persuade you to use it as we have expanded the support of the .NET platform developers: Subversion is now supported. IntelliJ IDEA 7.0 users can perform pre-tested commit to StarTeam and IBM Rational ClearCase (Base + UCM). And finally, we have many plans on extending the feature support.

You may also want to take a look at Roy Osherov’s TeamCity review and read the pre-tested commit description by the absolute insider – Kir Maximov – in his blog post.

Technorati tags: TeamCity, pre-tested commit JetBrains, IntelliJ IDEA, Eclispe, continuous integration, build management, agile development, MS Visual Studio 2005, MS Visual Studio 2008

Alex Handy at SD Times, the industry newspaper for software development managers, in the article JetBrains TeamCity 3.0 Provides Visual Build Metrics, pays special attention to the statistic charts that help you evaluate build metrics at a glance. He also appreciates the two editions of TeamCity (free professional and commercial enterprise), and the new possibilities now available for the .NET users: search for duplicates and pretested commit.
Thanks to Alex for the positive feedback
Refer to the online documentation for details about statistic charts, editions and .NET support.

Technorati tags:
TeamCity, teamware,Java, .NET, continuous integration, agile

TeamCity has two ways to label the build’s sources: automatic and manual one. So, let’s start with adding labels into the VCS for the build’s sources.

TeamCity can optionally add a label into the version control system for the sources used for a particular build. This can be useful, for example, when you need to have all the build’s sources to reproduce it. Opt to apply the VCS label for all builds or only for successful ones.

TeamCity supports VCS labeling for VCS roots managed by the following configuration management systems:

• ClearCase,
• CVS,
• Perforce,
• StarTeam,
• Subversion.

The labeling takes place after the build’s finish and doesn’t affect the build status.

To enable the builds labeling:

1. Navigate to Administration section, select the already existing project in the Projects list or start creating a new one.
2. Go the step 2 “Version control settings” definition, select the labeling mode and save your changes.

Besides automatic build labeling, you can label sources used for a build manually. Navigate to the Build Results page, Changes tab and click Label this build sources link.

See more in TeamCity online reference.

Technorati tags: TeamCity, teamware, new version, StarTeam, Subversion, Perforce, CVS, Clear Case, labeling, Java, .NET, continuous integration, agile

A useful feature helping to troubleshoot hangs and deadlocks in Java and .NET threads, is now available in TeamCity 3.0. You have a possibility to view stacktraces of all threads of all build’s processes on the build agent.

Taking a look at the thread dump can be an effective approach when detecting the leaves threads. The threads can be leaved as side effects of the system function or as a gap in some unit test.

TeamCity supports thread dumps for Microsoft .NET Framework 2.0 processes and Java 1.3 on Windows OS. On all other platforms it supports only Java from 1.5 and later.

To take a thread dump, find a running build on the Projects page, click it to navigate to the build results page and then click View thread dump link:

TeamCity tries to fetch the processes which take place at the moment and shows a window with a tree-like view of processes as well as their command line and stacktraces. Click the process name to investigate the the problem deeper.
Here is an example of how TeamCity represents both Java and .NET processes taking place when running a build.
Java process thread:

.NET process thread:

Note: If a build is running under Windows OS and Java 1.6, it uses a jstack utility to obtain a thread dump. This utility is also used to obtain thread dumps for all other platforms.

Have an untroubled and uninterrupted building!

Technorati tags: TeamCity, teamware, new version, thread dump, stacktrace, jstack,Java, .NET, continuous integration, agile

In the latest TeamCity 3.0 EAP releases we added one more feature helping to keep you up with the status of builds of the certain build configurations – getting reports on their status via syndication feeds.

You can specify the content of your personalized feed selecting from a wide range of settings and subscribe to it, for example, using some external application. Receive new feed entries for:

• all new builds or only successful or failed ones
• builds triggered by changes of all users or a particular user in your company, or only your changes

To create a custom RSS feed and subscribe to it:

1. Navigate to My Settings and Tools page, TeamCity Add-ons area, Syndication Feed and click Customize.
2. On the new page that opens specify a number of options:
   • select Build Configurations (multiple selection is available)
   • determine the Feed Entries you want to be included in the reports (events such as builds, changes of particular users or both, triggering the syndication feed generation)
   • enter the authentication settings if required
3. Copy and paste the resulting URL into your feed reader or click the Subscribe link and then select the desired application for reading the feed.

The resulting feed will be updated as soon as the new build matching the selected requirements completes.

The feed entries contain the summary of results of builds of the certain build configurations and navigatable links to the build changes and the build log:

Besides feed URL generator, it is possible to obtain the information about the finished builds from the home page of a build configuration.

Technorati tags: TeamCity, JetBrains, Java, .NET, IntelliJ IDEA, continuous integration, build management, agile development, best practices, MS Visual Studio 2003, Eclipse, notification, RSS, feed

Since version 2.0 TeamCity allows to specify the dependencies between the results of the builds of the build configurations, i.e. artifact dependencies and provides dependent builds triggering.

When creating new builds, it’s possible to use the artifacts of:

• last pinned build,
• successful build,
• last finished build (can be useful when integrating with changes third-party libraries)
• build with a particular number

In the artifacts paths you can use regular expressions or file patters. One or several artifacts paths can be specified.
It’s also possible to specify the destination directory where the artifacts are downloaded when the build is started and configure whether to clean the catalogue before creating builds and downloading artifacts to avoid artifacts clutter.

The artifact dependencies are set up when you create or edit the build configuration:

Since TeamCity itself acts like an Ivy repository it allows you to download the artifacts using Ivy tasks or Ivy tool from the command line. The dependencies are specified in the ivy.xml configuration file, you can put the file in your CMS repository and safely test changes in this file when running personal builds. You need to download the Ivy Dependency manager from http://ant.apache.org/ivy/ and follow the steps described in TeamCity online reference.

In the latest TeamCity 3.0 EAP versions we provide a possibility to view the info on the build artifacts were used to create the build on the Build Results page:

Technorati tags: TeamCity, JetBrains, Java, .NET, IntelliJ IDEA, continuous integration, build management, agile development, artifact dependency, MS Visual Studio 2003, Ivy