TeamCity 8.0.5 is Out

We are happy to announce TeamCity 8.0.5! It comes packed with more than 60 bug fixes, among which there are a few performance improvements that should benefit many users and a fix for a bug in TFS support which caused connections leak on the server in some cases. So, if you are using TeamCity 8.0.x, it is highly recommended to upgrade to the new version as soon as possible.

All the more reason to upgrade for .Net developers working with TeamCity is the fact that this release comes with the support for MS Build Tools 2013 in the MSBuild and VS Solution runners. As for test runners, the NUnit runner now works with framework version 2.6.3. .Net code coverage is further enhanced with the bundled JetBrains dotCover 2.5.

Support for Visual Studio 2013 in TeamCity VS Addin and .NET Inspections runner is not yet here, but we plan to provide it in the nearest future. Please watch for these issues:
TW-31731 and TW-33398.

For the complete list of fixes, refer to the Release Notes and download the new build now!

Happy building!

Posted in Features, How-To's, News & Events, Tips&Tricks | 2 Comments

TeamCity Torrent Plugin

Today we have some interesting news for you – the Torrent plugin for TeamCity!

With this plugin, users and build agents can download TeamCity build artifacts faster, especially in a distributed environment.

A bit of the BitTorrent protocol details

For those of you who are not familiar with BitTorrent – this is a peer-to-peer protocol. It means there is no single server for shared files. Instead, the files can be downloaded from peers that already have these files or parts of them.

Still, a server is required to find peers. This server is called a torrent tracker. To download a file, a peer must have a torrent file describing the required file. With this torrent file, the peer goes to the torrent tracker, and the tracker provides addresses of other peers in the network sharing the file.

A peer that does not have the file yet but wants to download it is called a leech. A peer that has the file and wants to share it is called a seeder.

Applying it to TeamCity

So what TeamCity Torrent plugin does – it turns TeamCity into a torrent tracker for all published artifacts greater than the specific size: by default, the artifacts of size less than 10 megabytes are not available via the BitTorrent protocol as it is not very efficient for small files. Additionally, the TeamCity server becomes a seeder for these artifacts. So for every artifact there is always one seeder in the network.

On top of that, when an agent decides to download an artifact dependency, it can choose to use the BitTorrent protocol instead of HTTP if there is more than one seeder available. Once the agent downloads the file, the agent itself automatically becomes a seeder for this file. When the agent publishes the artifact to the TeamCity server, both the server and agent start seeding it. So if you use TeamCity artifacts a lot, eventually you’ll end up with quite a number of agents seeding artifacts. Not only does this increase the speed of the artifacts delivery to agents, but it also reduces the load on the TeamCity server.

Finally, the users who have Torrent clients installed can also download files from TeamCity via the BitTorrent protocol.

Setting up the plugin

The plugin is compatible with version 8.1, so to try it, you need to install the latest TeamCity EAP build. Grab the plugin here and install it as usual.

Once you restart the server, a new link, Torrent Settings, will appear in the Administration area. The plugin is disabled by default. You can enable it on this page:

Verifying the plugin works

If the plugin works correctly and you checked both options on the Torrent settings page, then once a large enough artifact is published, you should see the following icon near the artifact name:

Clicking this icon should start your favorite torrent client. And this is what it looks like for some of the widely used artifacts on our server:

If a build has an artifact dependency on some artifact, you should see the attempts to download the artifact via torrents in the build log:

Please try this plugin and let us know what needs to be improved!
Happy building!

Posted in EAP, Features, FYI, How-To's, News & Events | Tagged , , | 3 Comments

Automatic Merge

Dear DVCS users, TeamCity 8.1 brings you automatic merging! Please give it a try and let us know what you think!

Now you can merge the sources of a build into a specified branch using the automatic merge build feature. It handles the case when you create a branch to fix some issue and push the branch only once when the work is complete and ready to be merged.

Remote runs

Those of you who use remote-runs from IDE know that the great thing about them is that IDE will submit your changes automatically once the build finishes successfully. However, as it happens with every technology, remote runs have some shortcomings.

When you start a remote run, TeamCity applies your patch on top of the latest revision at the time the build starts. So when you decide to submit your changes, the result of the personal build reflects the final state of your repository more closely, which is great! But if your colleague breaks some tests or, God forbid, a compilation while your remote run is waiting in a queue – your build will fail even though you didn’t break anything.

Another shortcoming is that in order to commit personal changes, TeamCity needs your IDE to be open so that the TeamCity plugin can make a commit on your behalf. Besides, personal builds force you to make all the changes in a single commit which is not always convenient.

Automatic merge

With the automatic merge you get the picture similar to remote runs. When a build finishes successfully in your feature branch, the branch is merged automatically to the default.

As with every merge, the automatic merge works best with short-lived branches. The merge itself doesn’t care about the age of your branch, but the older your branch is, the higher the probability of failure due to conflicts is. Actually, not only files can be moved around, but also semantics can change over time. Things get worse when you, for example, extend some java class while your colleague removed it in the default branch. The merge succeeds but your compiler won’t be happy with the result.

Still, comparing to remote runs, the automatic merge can get you the best of 2 worlds: the isolation of feature branches and the ability to integrate your changes automatically. As a bonus, you can finally turn off your computer when you go home – the merge is performed on the server, so no open IDE is required.

Configuring automatic merge

First, configure feature branches. Then add the Automatic Merge build feature to your build configuration. Specify a pattern for branches to merge, e.g. ‘+:issue-*’; a destination branch, e.g. ‘master’; and a merge commit message to use. By default, the merge is performed only for green builds, but you can also choose to run a merge if no new tests failed. If there are any conflicts during a merge, TeamCity fails the build.

You can specify the merge commit author in VCS root settings:

What if you want to merge only when several conditions are met? For example, do the merge only when tests on Linux, Windows and Mac OS pass. You can achieve that using snapshot dependencies:

  • create a build configuration with a VCS root to merge and configure the auto merge build feature
  • add a snapshot dependency to every build you want to succeed before a merge occurs.

As a result, the merge at the top of the chain will be performed only if all builds in its snapshot dependencies were successful.

Double-distilled merge

To handle semantic conflicts, like the use of a removed class, you can create a separate ‘integration’ branch and use it as a destination for an automatic merge, and then configure another merge from the ‘integration’ to the default branch. The integration branch will sometimes be red due to uncoordinated changes in the parallel branches but the default branch will always be green and safe to deploy*.

Manual merge

The asterisk in the previous sentence means it was a lie . The automatic merge cannot guarantee green builds. If you run your build on multiple platforms or there is a lot of concurrency in your system, some tests may fail even if the previous build on the same revision was green.

So you have a build where some tests failed, but you know that the build is fine and its sources should be merged. To deal with such cases, you can merge the build sources manually. We added the Merge this build sources action on the Changes tab of a build. It allows you to choose a destination branch and do the merge. A manual merge is also useful if the push-only-when-complete workflow isn’t suitable for you, so you can merge the branch when it is ready from the TeamCity UI.

Posted in Features | 3 Comments

TeamCity 8.1 EAP1 is Out!

TeamCity 8.1 EAP1 is now available for you to try!

Among the valuable additions of this build is the ability to automatically merge feature branches to the master if you are working with Git and Mercurial. The feature is extremely handy when you create a branch to fix an issue and push the branch only once when the work is complete and ready to be merged.

To provide greater visibility and control over projects to Project Administrators, we have moved Maven settings and configuration of build results report tabs to the project level.

We have also reworked VCS labeling as a Build Feature instead of options in the VCS Settings section: not to worry, your existing settings are converted automatically to the new format allowing more flexible configuration.

This new build introduces a few improvements enabling you to simplify the configuration of your build process. On creating new build steps TeamCity can now scan the VCS repository and automatically determine the build runner to use. At the moment, auto discovery is available for Ant, Maven, Xcode, Visual Studio solution, MSBuild runners and IntelliJ IDEA based projects. We are sure you’ll appreciate a few other improvements aimed at reducing the complexity of the configuration UI.

We constantly work on improving TeamCity, so our MSBuild and Visual Studio Solution build runners now have full support for Microsoft® Visual Studio 2013 and Microsoft® Build Tools 2013.
Code coverage tools spectrum is further expanded with JaCoCo as a coverage engine for Ant, Maven, Gradle and IDEA Project builds.

To help project administrators improve the configuration, the Server Health report now detects problems with reusing builds for configurations with snapshot dependencies, notifies you on queued builds sitting in the queue without compatible agents, and reports cloud agent issues.

Besides, we really rolled up our sleeves squashing a number of bugs in this EAP Build!

So, see the release notes, try the build and let us know what you think about the new features!

Happy Building!

Posted in EAP, News & Events | 4 Comments

TeamCity 8.0.4 (27616) is available

Today we are rolling out TeamCity 8.0.4 (build 27616) bugfix release addressing about 80 issues! Several important performance fixes are among them, including faster agent side checkout for TFS 2012.

Everyone is encouraged to upgrade to this version.

We also did several fixes and improvements in Command line remote run tool. If you use this tool, take the latest version compatible with 8.0.x.

Refer to the Release Notes for the full list of issues addressed.
Download the new build now!

Happy building!

Posted in News & Events | Leave a comment

User Interface Tips and Tricks

When working with software daily, every once in a while you discover some little hidden gems that make the experience more user-friendly and/or more fun. In this post we’ll explore some of the lesser-known features available in TeamCity UI that make it easier to navigate projects, builds and so on. Let’s check them out.

Navigating all projects

One of those useful UI gems is the “All Projects” popup. Press the P key to open the popup. In this popup, we can filter the projects that are shown. What’s more, we can navigate to projects and even build configurations by using the arrow keys (up/down to navigate projects, left/right to navigate build configurations). Pressing Enter takes us where we want to go.

By clicking the icon in front of a project or build configuration when exploring builds, we get a similar menu which allows us to navigate to different projects or build configurations.

Changing Run button caption

Many people use TeamCity to trigger deployments or do other actions different from just running a build configuration. Why not change the Run button caption? Wouldn’t it make more sense to label that button Push! or Prod when that build configuration pushes artifacts to a production system? There’s a workaround: by adding the configuration parameter named teamcity.ui.runButton.caption, that caption can be changed.

What’s that build doing?

While a build is running, we can get an overview of the build log or use any other tabs available on the build details page to see what’s going on. By hovering over the arrow next to the build number, we can get a summary in one glimpse, including its status, progress, currently running step, build agent name and so on.

Also, when we hover over the build status icon, a small popup will open listing the build status description and the build agent which is in use or has been used during the build.

Build agent

In-browser diff

From the build result page, we can compare files that have been changed in source control right in the browser. On the Changes tab, in the build changes details, click any changed file to get a diff against the previous version.

What’s nice is that we can also diff images in GIF, PNG or JPG file formats.

Happy building!

Posted in Features, Tips&Tricks | Tagged , , | 2 Comments

NuGet Package Restore with TeamCity

When working with NuGet we can make use of package restore. The concept is simple: instead of committing packages that we depend on to source control, we only commit the list of dependencies we need and download the assemblies during build.

In TeamCity, package restore is supported in various ways. We can use the NuGet.targets file (NuGet v2.6 and earlier) or run nuget restore from the command line (v2.7). TeamCity has a build runner which makes setting up package restore a breeze: the NuGet Installer.

NuGet Installer

The NuGet Installer build runner will make sure all package dependencies are satisfied during build. It provides several options:

We can specify the package sources that will be used to satisfy dependencies. By default, restoring will be done using NuGet.org but we can also make use of a private NuGet feed hosted on MyGet, ProGet or our own NuGet Gallery installation. When the current build depends on NuGet packages created by another build, we can also make use of the TeamCity NuGet feed (if enabled), for which the feed URLs are available from the %teamcity.nuget.feed.server% and %teamcity.nuget.feed.auth.server% parameters.

Other available options are disabling the local NuGet cache, forcing a fresh download of packages during every build. We can also enable auto-updating of NuGet packages if needed.

Which packages are we using?

The NuGet Installer runner also adds an additional tab on the build results page, showing the list of all packages used.

Package restore and feed authentication

When consuming NuGet packages from an authenticated feed during a build, the last thing you want to do is add credentials for connecting to that authenticated feed to source control. TeamCity has a much more elegant solution for this: the NuGet Feed Credentials Build Feature. We can add it to any build configuration, one for every feed that requires authentication.

TeamCity package restore from authenticated feed

Happy building!

Posted in Features, How-To's, Tips&Tricks | Tagged , , , | 13 Comments

TeamCity 8.0.3 (build 27540) is ready

Please welcome another bugfix release build with a bunch of improvements.

Let us mention some of the most important:
- The issue with caching server side checkout patches which caused significant performance problems in some installations is now fixed.
- We’ve found and fixed a defect with build triggering , thanks to Niek Bartholomeus.
- Some icons in the web interface were tuned to better suit red/green color-blind people, and we hope TeamCity is friendlier to you now!
- Dependencies of Ant network tasks (FTP, sshexec) are now bundled with TeamCity.

Refer to our release notes for the complete list of fixed issues.

Download page

Happy building!

The TeamCity Team

Posted in News & Events | 2 Comments

The Power of Meta-Runner – Custom runners with ease

TeamCity comes with a series of Runners out of the box which offer support for different functionalities such as MSBuild, Ant, Code Inspections, Gradle support, etc. In addition to these, there are a variety of runners that are supported via plugins, from FTP uploads to Grails and other things.

TeamCityDefaultRunners

What happens when you want to perform some operation that is not supported via a runner? We could use the Command Line runner or build or own plugin. Each have their own benefits and disadvantages. The first one is quite straightforward, but the second offers more flexibility and a better user experience. TeamCity 8 introduced a third option: Meta-Runners.

Meta runners allow us to reuse build steps by representing them as a native TeamCity runner. In other words: we can extract configured build steps into Meta-Runners and reuse them in other build configurations. A good example are the PHP Meta-Runners from the Meta-Runner Power Pack. While TeamCity doesn’t come with PHP-specific runners, we have extracted some build steps into Meta-Runners that do make it easy to do Continuous Integration with PHP.

The following video demonstrates creation of a Meta-Runner:

Voilà! With just some clicks, we’ve created a new runner that we can re-use in other projects and build configurations.

Assumed FAQ

Guessing some of the questions that might come up, let’s try and address them:

1. Do I need a script file to create Meta-Runners?

No. You can base a Meta-Runner off of any existing runner. The UI is defined by the Build Parameters you create. It is important to note however that anything the Meta-Runner uses (for example a specific runtime or executable) should be available on the agent. One way of doing this is adding a step in the build process to prepare the environment, downloading any external dependencies. The Meta-Runner Power Pack contains an example Meta-Runner which uses Ant to download a file from a given URL.

2. Do Meta-Runners belong to the Root Project or a specific Project?

They can belong to either of them. In this example, we created it at the project level, but you can also create it at the root project level.

3. How do I delete them?

They are located on a new tab under the Project Settings.

image

4. Are there any limitations?

Currently:

  • When extracted the runner, via the UI you cannot control which steps to extract. All steps are extracted.
  • Extract meta-runner UI does not allow to re-order the parameters. However, once meta-runner is extracted you can reorder them manually in the resulting xml file.

5. Sounds cool, but which Meta-Runners can I build?

Anything, really. Whenever it feels you’re duplicating build steps across build configurations, they are perfect candidates to extract a Meta-Runner. We already have some Meta-Runners that can be used in the Meta-Runner Power Pack. Feel free to contribute yours if they may be of use for others!

Try this and the other TeamCity 8 features and give us some feedback through the comments below!

Happy building!

Posted in Features, How-To's, Tips&Tricks | Tagged , , , , | 2 Comments

TeamCity 8.0.2 (build 27482) is out

TeamCity 8.0.2 bugfix build is available now. It addresses several important issues and regressions, as well as some performance problems. We strongly recommend that you upgrade to this version, especially if you experienced problems with TFS, email notifications or slow builds finish. Additionally, there are general enhancements increasing the server performance.

If you upgrade from version 8.0, installing 8.0.2 build preserves the data format (this is usually the case with all our bugfix builds). In case you encounter any problems with build 8.0.2, you can safely revert to 8.0.1 or even 8.0 without the need to restore from backup.

Release notes
Download page

Happy building!

Posted in News & Events | Leave a comment