TeamCity Blog

Yes, we admit that every so often TeamCity like any other application can misbehave or slow down for some reason you cannot understand, and traditional “close and open” method (or “shutdown and start” in TeamCity terms) does not always help to get rid of the headache…

Now you don’t need to spend ages when trying to diagnose the problem. We have created a utility for taking the CPU profiling snapshots of the TeamCity server right from the web UI. Download the latest version of this plugin and see the installation instructions for details.
And please note that it is compatible with TeamCity 3.1 and higher.

Have an untroubled building!

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

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

A flexible system of different build triggers in TeamCity allows to start the builds when it’s really necessary rather then use your company’s hardware resources at their most - running multiple builds at the same time and making you wait for the feedback on changes’ integration results.

Let’s now take a look at how TeamCity can help to “tame” builds clutter.

The most common case of firing a new build - changes committed to the version control system - can be altered by specifying a “quiet period” - time to pass with no changes in the build configuration VCS roots before TC starts a new build. In addition, you can use wildcards and operators to exclude parts of the VCS roots and ignore commits of particular users.

It’s quite common for many companies to create new builds periodically. In this case TeamCity can still limit the builds number if there are no changes pending to be built.

In TeamCity 3.1 which we plan to release soon, we’ve implemented more flexible build triggering options using Cron Expressions for more precise schedule tuning:

You can also specify to start a new build when a successful build of a dependent build configuration appears or when the previous build has failed.

In-depth build triggering options are, as usual, explained in online reference.

Technorati tags: TeamCity, pre-tested commit JetBrains, IntelliJ IDEA, Eclipse, continuous integration, build management, agile development, Cron, 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

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 TeamCity 3.0 we implemented one small but useful feature assisting you with builds’ state troubleshooting: discovering builds which are probably “hanging” at the moment and displaying this information on the Projects and Build Configuration’s homepage:

Of course you don’t always watch and have to watch the project’s health at the projects’ dashboard or the build configuration’ homepage and prefer to stay tuned to your workflow but be informed of hanging builds so your precious time is not wasted and the feedback loop stays reasonable. Nothing more simpler, just customize the notification rule:

1. Navigate to My Settings and Tools | Watched builds and Notifications area.
2. Click the Edit button near the desired notification means (e-mail, Windows Tray Notifier, e-mail, Jabber or IDE notifier).
3. If you already have some notification rules, click the edit link and select The build is probably hanging option. Otherwise create a new notification rule and enable this option.



4. Click Save.
   

Now you can stay tuned to the development or builds management process but you won’t miss the hanging builds situation which may be even dangerous if the changes need to be incorporated quickly and build must be delivered within a very tough timeframe.

Technorati tags: TeamCity, teamware,hanging build, New version, StarTeam, Subversion, search, tag, thread dump, 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