TeamCity Blog

This post continues the story of new TeamCity plugins which have just appeared. Today we would like to tell you about two third-party plugins.

The Growl notifier plugin delivers alerts using Growl engine.

Another plugin named Team piazza displays the current state of the build informing the team when the build fails and provides much other useful information on the current build state.

We would like to remind you that anyone can become a member of TeamCity plugin development community and develop plugins for integration with different change management systems, build runners, IDEs, or notification means using TeamCity’s Open API. Get more information in TeamCity online reference.

Thank you very much for your effort!
The JetBrains TeamCity team

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

For the past several weeks we have been working really hard to solve a number of issues after the 3.1 version was released, and voilà - a hot tasty little pie called TeamCity 3.1.1 is right here

The release is mainly targeted on improving the performance, has a number of bugfixes and adds better performance for StarTeam.

You can download the latest version at the official website. And don’t forget to back up your data before upgrading.

And some more good news today. Laurent Kempé, the editor, founder, and primary contributor of Tech Head Brothers, has just published an article on his successful experience of integrating TeamCity with NCover - a tool for measuring the code coverage for .NET platform development. An integration result is possibility to get an overview of the project code coverage in a dedicated Code Coverage Summary tab of the build configuration.

We wish you a happy building with TeamCity 3.1.1 and we are really glad to hear about the concrete TeamCity usage examples!

The JetBrains TeamCity team

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

Here, at JetBrains, we use TeamCity for building all our projects and TeamCity itself and have multiple build configurations for quite different purposes to thoroughly test our tools. All in all - about 700! build per day, 170 build configurations for:

• estimating code quality by discovering code duplicates, bugs, performance issues, and dead code and measure the code coverage with unit tests
• scheduled builds (such as, for example, nightly ones)
• “stress” tests and many other cases

Aaron Jensen has recently praised TeamCity’s possibilities, and now he shares real life examples of TeamCity’s build configurations set up in his company.

First and foremost, come the continuous integration builds triggered by VCS check-in and scheduled nightly builds.

He also uses TeamCity’s ability to specify the dependencies between the results of the builds of the build configurations. You can read more about in a blog post on artifact dependencies and dependent builds triggering.

And, finally, he mentions utility build configurations for revealing duplicate code and getting the Subversion repository statistics via StatSVN.

We are sure that you can make the most of TeamCity’s options when setting up your own build configurations selecting from a variety of triggering options, specifying dependencies between the builds artifacts and other build configurations and many others.

Wish you happy building, and, by the way, stay tuned to our blog Right now we are really busy discussing the next version features pool, so the roadmap is going to be published soon. Meanwhile, you can vote for the feature requests (and, of course, create new requests) at our new issue tracker and online forum.

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

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