TeamCity Blog

Here, at JetBrains, we use TeamCity to build all our projects - commercial, open-source, and internal solutions. This is why we understand the value and importance of information that will be kept “inside” TeamCity server as well as the burden of setup, adoption, and maintenance of “yet another server” for your company.This is why we support four major industry-wide databases:

• MySQL (5.0.40+)
• PostreSQL (8+)
• Oracle (10+)
• Microsoft SQL 2005

to back end your TeamCity server, so you can reuse your existing IT infrastructure in the most efficient way. 

To ease the evaluation process, TeamCity comes with a built-in pure Java database (HSQLDB) that works out of the box under any environment without any additional configuration. When you evaluate TeamCity to see whether it suits your needs and which benefits it brings, it collects information on the build results and preserves it in this simple built-in database. But because of its simplicity, the database does not scale well and is not targeted on a real production.

Once you decide to handle the software building process to TeamCity and use it for production purposes, you need to switch to one of the supported databases most suitable for your environment and infrastructure. Please note that after initial setup the external database does not require any kind of special maintenance - TeamCity server does everything automatically using the database you have selected, and you control performance, scalability, and safety.

The database switching process is rather simple and straightforward:

1. Stop TeamCity server.
2. Back up the TeamCity data directory.
3. Follow an extensive explanation of this procedure in the Setting up an External Database and Migrating to an External Database sections of our online reference.

We strive to make both adoption and production usage as easy as possible, and if you have any questions, comments or suggestions, please don’t hesitate to drop us a line - either here or at teamcity-feedback at jetbrains dot com.

Technorati tags: TeamCity, JetBrains, IntelliJ IDEA, Eclipse, EAP, roadmap, continuous integration, build management, database, MySQL, PostgreSQL, oracle, MS SQL 2005, 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

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

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

TeamCity users can get notifications on different events of the projects they are watching, such as build start and failure, notifications on successfully completed builds or changing of the person responsible for the build failure. TeamCity has a number of means of notifying users on such events:

• standard e-mail:



• Windows Tray Notifier for receiving notifications and monitoring the building process in the system tray:



• Jabber/XMPP protocol
• In IntelliJ IDEA: IDEtalk plugin and IntelliJ IDEA plugin for TeamCity:



• Eclipse plugin

In the latest EAP build, we have also implemented the RSS feed notification on finished builds of the particular build configuration.

All notifications have a standard layout but the administrators can customize the notification templates to better suit the needs of a particular project or the company’s typical workflow. You can access and modify these templates in a dedicated notifier configuration file (not in TeamCity web UI).

The notifier templates are stored in the notifier configuration file of TeamCity Data Directory. The syntax of the notifier configuration files is described in the *.dtd files and contains two customizable sections:

• <templates/> - specific templates with notification messages
• <events/> - the list of events to be notified on and referenced with the associated templates

All additional templates you want to be used are placed into the <templates> section, and each notifier type template must have a specific tag or sub-element or the notification text is put within the <template/> tag. All templates are attached to specific events such as build start, failure and others. Each notification event supports a specific set of substitution patterns. These are:

• “build_started”
• “build_successful”, “build_failed”, “build_failing”
• “responsible_changed”

After you have modified the notifiers templates, TeamCity server applies changes on-the-fly.

One more notification event (also customizable) - the build is probably hanging - has appeared in one of the latest TeamCity 3.0 EAP builds.

The concrete examples of customizing the notifier templates are available in TeamCity online reference.

Technorati tags: TeamCity, JetBrains, Java, .NET, IntelliJ IDEA, jabber, tray notifier, e-mail, continuous integration, build management, agile development, MS Visual Studio 2003

Builds in TeamCity can be initiated by a variety of different triggers. These can be, for example, a change in the VCS, the successful build of another build configuration, or a schedule-based or manual trigger. Developers can also start personal builds with a pre-tested commit from their IDE. As soon as the software build has been initiated, it is added to the build queue, which you can monitor in the dedicated Build Queue tab.

Since we released TeamCity 2.1 we have polished the interface of the Build Queue tab, which now provides more detailed information on a pending build status including:

• the expected build start time
• the expected build finish time with the estimated build duration available in the tooltip
• the build agent where TeamCity plans to run a build
• what triggered a build
• a list of build agents which can run the build (additionally the current agent status is available in a pop-up window)

This information makes it easier to better manage and monitor the process of creating builds on TeamCity’s build grid:

If there are several compatible agents TeamCity tries to run the particular build on the agent with the shortest estimated build duration. Time estimates are calculated based on the builds history and the build agent on which the build is scheduled to run.

It has been possible to reorder the build queue by dragging and dropping or removing the desired build from the queue since the first version of TeamCity. With introduction of project-based user roles in the upcoming version of TeamCity, only users with the necessary rights (as defined by the TeamCity Administrator) will be able see the project’s build configurations on the Build Queue tab.

We hope you’ll find these feature improvements helpful and look forward for your feedback at our forum.

Technorati tags: TeamCity, build queue, JetBrains, IntelliJ IDEA, Eclipse, MS Visual Studio, Java, .NET,continuous integration, build management, agile development

As we mentioned in our previous blog post, TeamCity has a number of ways to verify the code quality. Searching for repetitive blocks of code - known as code duplicates - is one of them.

The redundant and seemingly harmless pieces of code may eventually lead to an unmanageable project code base. Our own team is a really good example: searching for code duplicates in the IntelliJ IDEA project locally took about 40 minutes, and it was almost impossible to constantly monitor the state of the code base. But as soon as we implemented the server-side search for code duplicates:

• all of the team members had access to the duplicates report and could make the code base better structured and controlled;
• unnecessary pieces of code were removed, thus reducing the overall size of the code base;
• the code base became much more manageable;
• the developers were able keep on coding as usual because the duplicates were searched for on the server, and their own machines resources were not used.

TeamCity has supported searching for Java code duplicates for quite some time. Support for finding C# duplicate code will be available in TeamCity 3.0. We are working on the possibility of configuring the Java duplicates finder to work not only via an IntelliJ IDEA project file, but also by using the Eclipse project file or a Maven POM file. Setting up a build configuration with the Duplicates finder runner ensures that all of the integrated code is constantly checked for duplicates.

When specifying this runner settings for Java projects, you need to point TeamCity to the project .ipr file and set a number of options, in particular:

• searching or ignoring the duplicates in the test sources of your project if it does not make much sense to verify tests for duplicates
• whether to regard usages of different variables, fields, methods, types, or literals in otherwise structurally similar code as duplicate
• the minimum relative size/complexity of a code piece that will be regarded as a duplicate

The duplicates search is, as usual, performed on one of the available build agents, and when a build is finished, a detailed report is available in the web UI. Working with code duplicates results is similar to working with the server-side inspection results: after the build is finished, you can browse the duplicates list (build results page, Duplicates tab) and opt to show all or only the newly discovered duplicates.

The top left panel displays a list of found duplicates and their instances with the file names. Use the arrows to examine the selected duplicate in one of the lower panes.

From the duplicates report page you can jump to the source code in your IDE (IntelliJ IDEA, Eclipse or Microsoft Visual Studio). Click the Open in active IDE button, and you will navigate directly to the file containing the duplicate instance and be able to quickly revise the issues found. In IntelliJ IDEA you can work with found duplicates either in the editor or in a tool window.

Keep an eye on our Early Access Program!

View the example of a server-side duplicates search at our demo site.

Technorati tags: TeamCity, JetBrains, IntelliJ IDEA, Eclipse, MS Visual Studio, Java, C#, continuous integration, build management, agile development