JetBrains TeamCity Blog

TeamCity has always provided a number of places and ways for monitoring changes which the team made:

• pop-up on the Projects page showing pending changes or those being built at the moment
• Recent history on the build configuration Overview page
• different types of notifications
• Change Log of the build configuration containing the records of all entries of changes which were committed.

In TeamCity 4.0 we made a number of improvements in the Change Log tab design helping to focus on what is the most important and letting you to:

• specify the range of changes you want to view by providing the range of builds
• show the builds where developers’ changes got into
• view changes which were made by a particular developer – the feature is available since TeamCity 4.1 EAP

Hope you will find these new Change Log features useful in your daily chores.

Before trying TeamCity 4.1 EAP we recommend you to backup your database as usual.

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

With this post we open a series of publications devoted to the description of use cases and peculiarities of dependent builds in TeamCity 4.0.

So first of all, let's dig into the issue of why you may need using dependencies in your software building system. Today's IT companies tend to develop more and more complex software solutions while trying to constantly keep the quality of the product on a high level and move on faster. In a situation like this inter-project dependencies management can become an important factor for delivering successful products within a tough time frame. So, using TeamCity's dependencies can help you:

• run custom environment-specific builds.
• create frequent builds to catch all possible issues earlier.
• optimize your hardware resources spreading the work between several machines (Build agents) running in parallel or in sequence.

In general, when specifying dependencies, you just divide a single build procedure into several parts that can be run on different Build agents setting a subordination of one build configuration on a different one. So, specifying dependencies in TeamCity you simply create rules stating that, for example, builds of the A build configuration depend on the build of the B build configuration.

TeamCity let's you specify two different types of dependencies for your builds; these are snapshot and artifact dependencies.

Snapshot dependency is a dependency of a build configuration on a different one which ensures that both builds use the same sources, and these sources revisions correspond to the same moment of time. If a build is queued and there is no dependent build for the same sources snapshot, the necessary dependent build automatically gets into TeamCity's build queue.

Artifact dependencies provide you with convenient means to use the output (artifacts) of one build in a different one. When your set up the artifact dependency, the required artifacts are downloaded to the agent before a build starts. Any time later you can then take a look at what artifacts were used in a build or what build used artifacts of the current build on a Dependencies tab of the Build Results page.

To specify dependencies in your project, navigate to the Administration, then create/edit build configuration and then select Dependencies.

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

The Search feature has existed in TeamCity for quite a while and in version 4.0 we’ve made a number of improvements in it to provide you with smarter and easier information retrieval experience, say, find the info on particular issues or tests you have fixed recently, learn about the result of integration of a particular revision into the VCS, and much more.

After you have installed and started running TeamCity, it aggregates different projects-related information in the background making it available for search. Employing a power of a well-known Lucene engine TeamCity adds many features to help you save your time and make searching more intuitive, in particular:

• using partial (starts-with) match, so you don’t need to type the whole VeryLongName anymore,
• searching all build information from tags up to concrete file revisions, making simple one-word queries work,
• matching all terms by default, so you can easily narrow your search results,
• adding handy shortcuts and magic patterns to form a concise query.

For more details on what information is available for querying and how to create complex search queries, please refer to TeamCity on-line documentation and watch a short demo which covers some advanced search techniques for finding:

• a group of issues mentioned in commit comments using fuzzy search,
• all builds created during a particular period,
• build configurations that run specific test,
• build of a particular configuration containing an exact file revision.

Please note that some of enhanced search features are available only within EAP of TeamCity 4.0.1 so don’t miss your chance to participate in it.

Technorati tags: TeamCity, search, pre-tested commit, personal build, remote run, JetBrains, IntelliJ IDEA, Eclipse, continuous integration, build management, agile development, MS Visual Studio 2005, MS Visual Studio 2008

After not so short break we are back with the next post of our .NET mini-series, and today we are going to tell you about TeamCity NUnit Launcher — a bundled NUnit test runner. In most cases, if you need to use NUnit, all you have to do is just to run it with this Launcher.

As we said in the previous post, to provide tests state tracking and on-the-fly reporting, TeamCity contains several NUnit builds (different NUnit versions) and provides NUnit Launcher to use particular NUnit build for your tests.

To start the NUnit Launcher from any TeamCity build runner, use either the teamcity.dotnet.nunitlauncher NAnt property, or the environment variable of the same name, or the teamcity_dotnet_nunitlauncher MSBuild property. These properties should have the following mandatory parameters:

• .NET Framework version (both 1.1 and 2.0 versions are supported),
• The platform to run tests (x86, x64, and MSIL),
• The test framework version to use. TeamCity supports the following NUnit versions: 2.2.10, 2.4.1, 2.4.6, 2.4.7, 2.4.8, and 2.5.0 (Alpha 3)
• List of assemblies to test

In addition to the above-mentioned parameters, you can also specify filters by tests category and NUnit addins (for NUnit 2.4 and higher). Filters by tests category allow you to control a set of tests to run, if you use tests grouping by category in your project.

You can find the detailed description of TC NUnit Launcher syntax at TeamCity reference. Here, in this post, we will just illustrate it with the example below.
(more…)

When running your builds, TeamCity selects between the build agents taking into account a whole set of different factors and parameters. First and foremost, it tries to run the build on the fastest available build agent based on builds history of a build configuration on this agent. And since the available build runners depend on environment where the agent is running, TeamCity chooses an agent having required a build runner.

Until recently it was possible to run the build on desired build agent only from the web interface by, for example, clicking the Run button and selecting the desired agent from the list. The Run configuration policy, which we have told you some time ago, allows to make TeamCity create builds of some build configurations only on specific build agents. As a result, TeamCity will create builds of the build configuration only on specific build agents no matter if they are initiated:

• manually (either from the web interface or using the pre-tested commit)
• automatically when the changes appear in the version control system
• periodically (a time-based trigger is enabled)

With TeamCity plugin for IntelliJ IDEA you can now opt to select one or several build agents to run your personal build on. Such approach allows you to test your changes with more granularly under:

• desired platforms,
• operating systems,
• databases,
• environment variables.

which are specified for the build agent available in your company’s build grid:

The latest builds with the updated IntelliJ IDEA plugin are available at our EAP page.

We hope you will greatly enjoy the feature and use it on a daily basis.

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

Among many other plans for the forthcoming TeamCity 4.0 release, we want to extend the list of supported version control systems, and this time we bring you the long-waited Mercurial.

At the moment Mercurial support is implemented via a plugin enabling:

• server-mode checkout
• collection of developer’s changes
• checkout rules support and checkout on the server

In our nearest plans are remote run, checkout on the build agent, and bundling the plugin into TeamCity installation package.

The plugin it is compatible with TeamCity 3.1.x and TeamCity 4.0 EAP builds. Meanwhile, you can download plugin files at our public demo server. Look for TeamCity Plugins project, Mercurial SCM Support build configuration and download either mercurial-server.zip or mercurial-src.zip file.

Follow these simple instructions to enable Mercurial support in your TeamCity installation after downloading the mercurial-server.zip:

• for TeamCity 3.1.x server, move the mercurial-server.zip to the WEB-INF/lib directory of the TeamCity server,
• for TeamCity 4.0 EAP builds, put the whole zip archive into the .BuildServer/plugins folder and restart the server.

The mercurial-src.zip contains the plugin sources available under the terms of Apache 2.0 license, and you can also obtain source code of the plugin from the mercurial repository where it actually resides.

We wait for your feedback and suggestions and wish you a happy building!

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

In today’s episode of the NUnit mini-series we’d like to share some information on using TeamCity Addin for NUnit.

As we wrote in our previous post, to provide tests state tracking and on-the-fly reporting, TeamCity bundles NUnit and includes its own NUnit runners. These embedded runners suit most cases perfectly well but there can be situations when you:

• prefer to use particular NUnit instance (not TeamCity’s bundled) for your particular build configuration
• want to pass NUnit project file (.nunit)

For cases like these you can use a recently implemented TeamCity Addin for NUnit available in TeamCity 4.0 EAP; the Addin supports the following versions of NUnit: 2.4.6, 2.4.7, 2.4.8 and 2.5.0 Alpha3.

How does it work?
TeamCity Addin for NUnit is embedded in the system by default and contains .dll and .pdb files for each supported version of NUnit. For every build, the main part of a path to the TeamCity Addin is set to the build property and the environment variable of the same name:

• teamcity.dotnet.nunitaddin for NAnt
• teamcity_dotnet_nunitaddin for MSBuild

To enable on-the-fly tests reporting, all you have to do is to add a task in your build for copying an appropriate Addin’s files to your NUnit’s addins directory. Type your NUnit version at the end of the TeamCity Addin path using the following syntax:

• For NAnt: ${teamcity.dotnet.nunitaddin}-<NUnit version>.dll
• For MSBuild: $(teamcity_dotnet_nunitaddin)-<NUnit version>.dll

In the above filenames, the <NUnit version> parameter can possess the following values: 2.4.6, 2.4.7, 2.4.8, and 2.5.0.

Please note that we recommend to copy TeamCity Addin for NUnit files every time you run the particular build.

The following example for MSBuild shows how to use NUnit console runner with TeamCity Addin for NUnit 2.4.7:

<PropertyGroup>
   <NUnit>Path_to_NUnit_console</NUnit>
   <NUnitAddinsDir>Path_to_NUnit_Addins _Dir</NUnitAddinsDir>
</PropertyGroup>

<ItemGroup>
   <NUnitAddinFiles Include="$(teamcity_dotnet_nunitaddin)-2.4.7.*" />
</ItemGroup>

<Target Name="RunTests">
   <Copy SourceFiles="@(NUnitAddinFiles)" DestinationFolder="$(NUnitAddinsDir)" />
   <Exec Command="$(NUnit) $(NUnitFileName)" />
</Target>

Well, it’s again a time for a break. See you soon!

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

With this overview post we start a blogging mini-series about .NET and NUnit support in TeamCity.

For .NET platform builds TeamCity supports several build runners, in particular:

• NAnt
• MSBuild
• sln2003, sln2005, and sln2008

bundles NUnit testing framework (versions 2.2.10, 2.4.1, 2.4.6, 2.4.7, 2.4.8, 2.5.0 and later), and provides NUnit runner for your tests.

No matter which NUnit version you choose, TeamCity can track the tests and report all the information on-the-fly (both in the web UI and your IDE). You do not have to wait for your build to finish to discover that something went wrong. TeamCity informs you about tests failure immediately and provides details on occurred errors, so you save your time. By the way, in TeamCity web UI for each failed or ignored test you’ll find a direct link to open it in your IDE. With tests tracking feature you get on-the-fly all important information about every test you’ve run within a build: its status, name, package, duration, and statistics.

Besides, we eased a headache with running your tests under x86 process on the x64 machine by introducing an explicit specification of the platform and runtime environment versions. You can define whether you use .NET 1.1 and MSIL, x64 or x86 platform to use for .NET 2.0 version.

We also have good news for those who use NUnit addins. In TeamCity 4.0 EAP we have implemented support of NUnit addins for TeamCity NUnit Runner. Please note that this feature is supported for NUnit 2.4.6 and 2.4.7.

To run tests with NUnit, TeamCity:

• uses its own NUnit launcher
• automatically replaces NUnit calls from NAnt with <nunit2> task
• automatically replaces NUnit calls from MSBuild with <NUnit> task from the MSBuild Community tasks
• provides TeamCity addin for NUnit to enable on-the-fly tests reporting from the existing NUnit (2.4.6 or 2.4.7 versions) instead of using bundled TeamCity NUnit runner.

And last but not least feature we’d like to mention here is the Risk group tests reordering. Recently we’ve published a tip on this feature for the Ant and Ipr build runners, and voila! — since the latest EAP you can instruct TeamCity to run recently failed tests before any others. Using this feature, please remember that tests are reordered within every NUnit tests run instance in your build.

Well, lets have a break for now and dive into details in our future posts.

Technorati tags: TeamCity, JetBrains, IntelliJ IDEA, Eclipse, EAP, continuous integration, build management, NUnit, NAnt, Testing framework, MSBuild, agile development, MS Visual Studio 2005, MS Visual Studio 2008

If you want to investigate the problems of a particular build and find out, for example, the changes which caused the build failure, you can use TeamCity’s Difference Viewer. It allows to review the differences between two versions of a modified file and navigate between these differences.

You can access the Difference Viewer from almost any place in TeamCity’s UI where the changes lists appear, may it be Projects page, Build Configuration Home page, or Build Results > Changes tab and so on. After you click the modified file name, a new window opens:

In the window heading you can see the file modifications summary:

• file name alone with its status,
• changes author,
• comment for the changes list.

To move between changes, use the next and previous change buttons and red and green bars on the versions separator.

If you want to switch to the IDE and digg into the issue deeper, click the Open in the IDE button in the upper-right corner of the window. The file in question opens, and you will navigate to the exact change in your project file. Please note that you need to have a TeamCity IDE plugin installed for this.

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

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