TeamCity Blog

Until now the build configuration used VCS roots that were defined in the project. Numerous TeamCity users asked for more flexibility when setting up the VCS roots, so we decided to make a number of refinements in this area. You asked, and we listened.
First and foremost is that in TeamCity 3.0 you can define VCS roots for any build configuration of your project, and the build configuration’s VCS roots settings are independent of the project. Specify any number of VCS roots when you create a new build configuration or edit the existing ones:

Another neat feature is shareable VCS roots. Once you decide to use the same VCS root for a group of your projects, you eliminate a bunch of redundant operations. This option is set when you specify the general settings of a build configuration:

Technorati tags:  TeamCity, VCS, VCS roots, JetBrains, IntelliJ IDEA,continuous integration, build management, agile development

TeamCity has multiple ways to monitor a projects health. First and foremost is, of course, the user dashboard. Then come the plugins for the IDE’s that TeamCity currently integrates with (IntelliJ IDEA, MS Visual Studio, and Eclipse), standard e-mails, Jabber/XMPP protocol instant messages, and the Tray Notifier. But all these methods require either a TeamCity login, or some installation and customization procedures.

We decided to make it easy for software development teams to let their customers and other outsiders (who are not interested in the build process) monitor the builds’ status. No special magic - just insert a small HTML fragment into any web page:

• company’s website,
• blog,
• Wiki,
• Confluence.

And get an overview of the current project status: the latest build results, its ID, date and a link to the latest build artifacts:

This “version” of the projects dashboard does not require a login of any kind and of course the builds’ status is being constantly updated.

To start using this feature you have to either create a new build configuration or edit the general properties of an already existing one and select the Enable status widget option. The cues on the HTML sources to paste into your web pages are, as usual, in the TeamCity online reference.

Technorati tags: TeamCity, external status widget, JetBrains, IntelliJ IDEA, Eclipse, MS Visual Studio,continuous integration, build management, agile development, monitoring

TeamCity’s Build Agents run the software builds and altogether make the company’s Build Grid. To be able to run some build, the Build Agents must meet the requirements of the build configuration. If there is a free build agent matching the build configuration requirements is found when triggering the build, the build is started. Otherwise the build enters the Queue and is processed when a compatible build agent becomes free.

In TeamCity 3.0 you can establish a run policy for different build configurations selecting to run:

• only specific build configurations
• all build configurations compatible with the build agent

Such approach as we believe will allow to manage the build agents’ workload more effectively. Lets look at a quite common situation: if performance tests (as a rule taking much time) are run, the build agents which have low hardware resources may slow down, more builds will enter the build queue, and the feedback is not so quick as you would like it to be. To avoid such situation, define the run policy for the build configurations which can be run on the build agent. Do it when setting up the project or build configuration and any moment you need:

1. Click the Agents tab.
2. Navigate to the desired build agent.
3. Click the Compatible Configurations tab.
4. Select Run selected configurations only and tick the desired build configurations names to run on the build agent.

The changes are applied on the fly as usual.

And vice versa: you can make the build agent name or property a must-have requirement for the build configuration. As a result, TeamCity will create builds of the build configuration only on specific build agents.

More details on this are available in TeamCity online reference.

Technorati tags: TeamCity,build agent, build queue, JetBrains, IntelliJ IDEA, continuous integration, build management,agile development

The most essential steps for the software developers of their daily chores are modifying the code, integrating the changes, and waiting for feedback on changes integration. Depending on the project scale it may take a significant amount time. And if the developer’s changes break the code base, fixing the problem and verifying the changes always takes time. Meanwhile the development process can simply freeze, time is wasted, and deadlines are missed.

We decided to change the situation for the better: compared with the standard scenario - edit the code, commit, and verify the code quality - TeamCity’s pre-tested commit allows you to remotely verify your changes before committing them to the version control system. Thus, the project code base is always clean.

You may have noticed a new page has recently appeared on TeamCity’s web site providing the visual description of pre-tested commit.

In the nearest future we plan to publish a big article with pre-tested commit description: feature history, workflow, peculiarities in different IDE’s, and more.

Good news for the .NET platform developers: in TeamCity 3.0 you can perform pre-tested commit from within Microsoft Visual Studio 2008 Beta 2. The EAP build is already available for download.

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