TeamCity 9.0.2 is here

Greetings, everyone!

Today we are announcing the release of TeamCity 9.0.2!

This bugfix is rather important as it addresses about 100 issues. The fixes affect:

  • backup performance (TW-39612)
  • LDAP synchronization (TW-39589)
  • mechanism of applying changes in versioned settings (TW-39519, TW-39553)
  • recognition of Visual Studio Online URLs on the “create project from URL” page (TW-39730)

In addition, we updated the bundled JetBrains dotCover to version 3.0, and added the ability to reorder custom charts on the “Project Statistics” page. See our Release Notes for the full list of fixes.

As usual, bugfix releases do not change data format, so do not hesitate to upgrade if you are already running TeamCity 9.0!

Download the build and follow the upgrade instructions!

Your feedback will be greatly appreciated!

Happy building!

Posted in EAP, Features, News & Events, Tips&Tricks, Uncategorized | 2 Comments

What’s New in TeamCity 9, Webinar recording

The recording of our January 21st webinar with Wes Higbee, What’s New in TeamCity 9, is available on JetBrains YouTube channel.

In this webinar, Wes goes over the new features of TeamCity 9, namely: rearranging projects with Project Import; storing settings in VCS; creating and editing Custom Charts; running builds in Cloud Agents; as well as some other improvements.

We were glad to see tons of questions from the attendees. Below are select Q&A from the webinar.

Continue reading

Posted in Features, How-To's, Webinar | Comments Off

How Groovy uses TeamCity

This guest post is brought to you by Cédric Champeau, a Senior Software Engineer working on the Groovy language at SpringSource/Pivotal.

NB: starting today Groovy is looking for a new home.

Upgrading the continuous integration chain

For several months now, the Groovy language has been building a new continuous integration architecture based on TeamCity. We’re running it on a dedicated server sponsored by Jetbrains. One of the key reasons for moving to a dedicated server was the long feedback loop that we had on the Codehaus infrastructure and that classic open-source project CI infrastructures like Travis, based on slow cloud based instances offer: as an example, a minimal build on Travis took as much as 45 minutes. It may sound reasonable for a language like Groovy, but considering that the same build takes around 5 minutes on a recent laptop, there’s something very wrong. And there’s more than a single build to do:

The Groovy project has for example very strict requirements in terms of compatibility with several JDKs. We are testing Groovy against multiple versions of the JDK:

  • OpenJDK 5, for any Groovy version before 2.2
  • OpenJDK 6, the minimal JDK version for Groovy 2.2+
  • OpenJDK 7, with two different runtime versions: legacy and invoke dynamic
  • OpenJDK 8, with the same runtime versions as JDK 7

In addition, we test Groovy against early release versions of OpenJDK 7, 8 and even 9! We do that to report bugs to the OpenJDK team before new versions of the JDK go out in the wild. It has become more and more important lately since JDK 7 and the advent of invokedynamic: we have seen many buggy releases of the JDK breaking Groovy, so we really had to find a solution to avoid this as much as possible.


In addition to the combination of JDKs to be tested, Groovy is a widely used language, meaning that we have to support multiple versions. In particular, bugfixes are often backported on multiple branches. This means that we have more than one branch alive. Those days, we maintain Groovy 2.2.x, Groovy 2.3.x, Groovy 2.4.x and 2.5 is coming.

Last but not least, pull requests from the team or the community need to be pre-tested, increasing the combination of builds that we need.

For all those reasons, running TeamCity on a dedicated server looked like the best solution we found. It was also in particular important because TeamCity has the concept of a build agent. Build agents are important because they allow increasing the build capabilities externally. We haven’t done it yet, but one of the key aspects that made us lean towards TeamCity was the ability to build a group of “community driven” agents that would let us test Groovy on a wider variety of environments. In particular, the current builds are all based on a Linux x64 box, but Groovy needs to run on more than that: Windows, Mac OS, …​ All those environments need to be tested, but are not, because of the lack of build resources for that. This means that in the current architecture, we only rely on some community members who build on Windows or Mac OS to tell us if a build works or not. But we know that with TeamCity, we have a way to improve the situation in the future.


So imagine that each commit on the Groovy project needs to be tested on a combination of JDK, branch, environment, plus pull requests. This requires a lot of work, but TeamCity greatly simplifies this. In particular, the branch combination is reduced to simple configuration : on a build plan for JDK 7 for example, we can choose which branches need to be built. That dramatically reduces the effort needed to have a proper CI toolchain working.

From building to releasing

Another aspect of choosing TeamCity was the ability to simplify the release process. Before the new CI infrastructure was setup, releasing a new Groovy version was a bit complex. It involved building locally, checking the build, creating a tag, pushing the tags on VCS, uploading the distribution through WebDAV, or even the documentation through WebDAV. Last but not least, we also had to take care of synchronizing with Central through the Codehaus repository. Literally, it took hours. Releasing a Groovy version could take as long as a full day.

Since we migrated to TeamCity, we took advantage of using Gradle and Bintray to simplify the process. Using the Artifactory plugin and some configuration, releasing a new version of Groovy is as easy as filling a form in TeamCity.


Everything is built on the CI server, packaged, uploaded to Bintray and synchronized with Central using a single click. Lately we even added support for GVM directly in the release process on TeamCity, meaning that a new Groovy release is automatically promoted on GVM! There is still some manual process involved (for example, the CI server will not decide for itself if a build is considered a major version or not, nor will it automatically update the website to announce a release, or close JIRA versions for us). But what is interesting is that the overall process can be completed in less than an hour, including building, testing, and uploading. It’s a huge win.


A Groovy plugin for TeamCity

Interestingly, automating the release process soon required capabilities that TeamCity didn’t have out of the box. For example, notifying GVM, cleaning artifacts produced by pull requests, uploading the distribution to Bintray, calling the Artifactory REST API, …​ All those required scripting capabilities. For that reason, we developped a plugin for TeamCity which allows writing a build step as a Groovy script. The plugin gives access to a lot of information available in the build, like the build number, the branch name, etc…​ allowing us to trigger specific behavior based on that contextual information. For example, building all those branches on multiple JDKs is very nice, you soon realize that you are filling the disk with artifacts that you don’t want to keep. Unfortunately TeamCity will not let you have custom cleanup rules based on particular variables of a single build configuration. In our case, we wanted to remove the artifacts only for branches built from pull requests, and that is done through a Groovy script used as a build step.


In conclusion, we can say that we are very happy with the current status of our continous integration toolchain. We went as far as being able to release directly from the CI server, allowing us to dramatically reduce the errors related to a long, unfriendly human process, as well as dramatically improving our feedback loop (multiple JDKs, pull requests, …).

While the process can certainly be improved, for example by adding support for adding community build agents, doing it with TeamCity was very easy, so we’re very happy that we chose it!

Posted in Blogroll, Guest post, Partner | Comments Off

What’s New in TeamCity 9, January 21st Webinar

Join us Wednesday, January 21st, 12:00 PM – 1:00 PM EST (17:00 – 18:00 GMT) for our free live webinar, What’s New in TeamCity 9 with Wes Higbee.

In this webinar, Wesley Higbee will go over some of the new and exciting features of TeamCity 9.0. He will demonstrate rearranging projects among servers with Project Import; working with Versioned Settings; creating and configuring Custom Charts; running builds with Cloud Agents, and other improvements in TeamCity.

Space is limited, please register now. There will be an opportunity to ask questions during the webinar.

About the presenter:

Wes McClureWes Higbee is passionate about helping companies achieve remarkable results with technology and software. He’s had extensive experience developing software and working with teams to improve how software is developed to meet business objectives. Wes launched Full City Tech to leverage his expertise to help companies rapidly deliver high quality software to delight customers. He has a strong background in using Continuous Integration with TeamCity to bring quality to the table.
Posted in Uncategorized | Comments Off

TeamCity 9.0.1 update is out

Greetings everyone!

TeamCity 9.0 is your 24/7 build engineer and our developers are unstoppable as well even during the holiday time! We thought we’d make you a small gift – a new bugfix release just before the New Year’s Day – and here it is: TeamCity 9.0.1 is available!

Thank you for taking time to report issues to us! Build 32116 addresses over 70 problems related to different functionality, including some improvements in project import and the fix for the issue with Groovy plug. For the full list of fixes take a look at the Release Notes.

Download the distribution from the JetBrains site. We recommend upgrading your server to this version: as usual, this update does not modify the data format, so rolling back to 9.0 is possible at any time!

Happy building and happy New Year!

Posted in Bugfix, EAP, Features, FYI, News & Events, Tips&Tricks | Comments Off

Case study: TeamCity in Devbridge

This guest post is brought to you by Arunas Paskevicius, Web Developer at Devbridge Group. Based on the original CI with TeamCity Server“ post in the Devbridge blog.


A few years ago, most of our projects were just plain .NET web applications, and using one CI server (CruiseControl.Net) was enough. But as the company grew, so did our client base, and we realized not everyone wanted their projects to be written in C#. We started offering solutions created with PHP, NodeJS, Objective-C, Java and other languages. We also began using other tools for CI. For instance, we used Jenkins, and it ended up causing some problems.

The first problem was that some teams used CC.NET, while others used Jenkins. Sharing reusable build steps was problematic, because they were either “shell scripts” or CI application dependent configurations, not to mention we were dealing with different OS installations (Windows, Linux, OS X) on each of our CI machines.

The second problem was the usage balance between our CI machines. Some machines were used for running development and testing builds, others were used for deployment. For us, development builds occur frequently, so the machine responsible for this was always at max capacity while the production build machine wasn’t used nearly as much.


After a frustrating time, we decided that we needed a single CI environment where we could reuse our existing CI machines. This would allow for a painless transition from other CI software.

We took Jenkins, Go CD, Atlassian Bamboo and JetBrains TeamCity and installed them on our test machine for comparison. Next, we created build configurations for already existing projects and checked for the following:

  • Simplicity of creating a build
    To move everyone from their current CI software to the new one, we wanted it to have a simple and clear way of creating builds so that the learning curve would be as low as possible.
  • Build reusability (templates, etc.)
    A lot of our projects use mostly the same build steps, so we need a way for creating templates and other ways of reusing those configurations.
  • Scalability
    We wanted our CI machines to be easily managed, added and balanced for our builds. The ability to intelligently pick the right machine for the build was necessary.
  • Active Directory support and role management
    At Devbridge Group, we use Active Directory to manage user accounts, groups and permissions. The CI software that we chose had to support authorization and, if possible, groups.
  • Ease of configuration and the overall look and feel
    Using an ugly piece of software should be a thing of the past. We wanted the software to be easy to understand, aesthetically pleasing and responsive.
    We needed the software to have a RESTful API so that we could connect it to our other monitoring software, re-run builds and so on.

Choosing TeamCity over others

The reason we picked TeamCity was because it had the best results for our necessary requirements.

  • Simplicity of creating a build
    Creating builds in TeamCity was a breeze. TeamCity came bundled with most of the tools (runners) we needed for C# and JAVA projects. To create the build steps, we just needed to select a runner in correct order with one or two additional parameters. For PHP we just downloaded “meta runners” from the official JetBrains GitHub repository and created build steps. Additionally, we were pleased that it’s possible to create artifacts from a build and then use it as a Report page. For example, code coverage.
  • Build reusability
    TeamCity has templates that make it possible to copy build configurations from one project to another. It’s possible to create beautiful, reusable templates and add configuration parameters so that when you create a new build from the template, you can specify certain data: build.xml location, GIT tag prefix and so on.
    Another great feature is the meta-runner. It allows the user to create smaller templates for a specific sequence of build steps. For example, you can create a Heroku deployment build step sequence, then extract them all into a single runner, and use it in other templates or even share it with the world (like JetBrains did with the meta-runner power-pack).
  • Scalability
    TeamCity has agents that can be installed on different machines and will then connect to the central CI server software. The central software manages which agent will be used for each build. Additionally, you can define requirements for the agents to use. You can achieve this by using the parameters provided by each agent (you can also add your own).
    If you have more than one agent assigned, then your builds will be intelligently divided among those agents and the agents that don’t meet your requirements will be automatically skipped.
  • Active Directory support and role management
    This was the first thing we actually checked for. We were pleased to find that TeamCity supports both AD user and group synchronization. This made our lives easier because we could assign specific roles for specific groups.
    The overall user and role management is some of the best we’ve seen in CI.
  • Ease of configuration and the overall look and feel
    TeamCity has pretty simple configurations. Most of them, apart from LDAP, were done in a good-looking admin panel on the main CI server, eliminating the need to dig through a pile of XMLs or run through unclear lists of data.
    TeamCity comes with a REST API that is well documented and has a lot of action calls that can be used in your own software: triggering/stopping particular builds, getting build test information and event triggering a whole CI server and backup.

Half a Year with TeamCity

Since we started using TeamCity, creating and managing builds became significantly easier. We already have templates and meta-runners for creating new projects, and we are no longer divided by using separate software to achieve the same results. Additionally, we’ve eliminated the problem of having some CI machines idle while others are maxed out.

Overall, we think that TeamCity is a powerhouse that has strong features for JAVA and .NET projects. It also allows simple creation of additional runners and templates for any language and platform you might choose.

devbridgeDevbridge Group is an international software design and development company that builds comprehensive, custom solutions for enterprise mobile and web. Devbridge combines engineering expertise with elegant design aesthetic to deliver exceptional results for leaders in the manufacturing, healthcare, financial services and retail industries.
Devbridge Group produces more than 100,000 engineering hours annually, building custom cloud-based and mobile solutions. Long-term partnerships with Devbridge are built on trust and transparency. The company follows a streamlined agile process, is committed to Responsive Design, and always pursues excellence.
Posted in Guest post, How-To's, Partner | Comments Off

TeamCity 9.0: Best for Pandas

Winter releases of TeamCity are practically a tradition: we lovingly released TeamCity 8.1 this year just before St. Valentine’s day and now we really cannot think of a better way to end the year and celebrate Christmas than to present you with a brand-new TeamCity 9.0! Please give a welcoming round of applause for TeamCity 9.0 which has just been released!

With the server clean-up in background, TeamCity 9.0 finally has zero maintenance downtime which is great news for distributed teams, who no longer need to worry about scheduling the clean-up.

Besides, the new version comes with the ability to move projects between TeamCity servers preserving the project data and changes history as well as user profiles, and all of this is done right from the TeamCity web interface. We hope you’ll love this feature for its clarity and ease of use:

Another significant addition is storing project settings in version control – Git and Mercurial in this release. Keep track of your settings the same way you do with the source code:

There is so much more – see our What’s New and Release Notes!

Download TeamCity 9.0 and start enjoying the benefits of the new version immediately!

Oh, and if you are wondering about the title, find out why TeamCity is best for you and pandas on our web site!

Merry Christmas and happy building!

Posted in Blogroll, Bugfix, EAP, Features, FYI, News & Events, Tips&Tricks | 14 Comments

TeamCity evolution in the past 5 years

Dear TeamCity users!

Every new TeamCity release brings lots of changes, and oftentimes we are not sure how successful they will be, or they might seem minor at the time. This is especially noticeable if we come across an old TeamCity version and, looking back, we realize how accustomed we are to many of the features that once were a novelty. So today we decided to review the evolution of our CI server and remind you of the most significant features brought to you by the releases in the past 5 years.

Now we easily create projects in TeamCity by simply giving it a URL – the feature is barely a year old, it came with TeamCity 8.1 in February of 2014:

When you look at the internal JetBrains TeamCity server with over 300 nicely arranged projects, it’s hard to imagine now that less than two years ago, TeamCity had no projects hierarchy, introduced in version 8.0 in June, 2013:

Version 7.1 came with support of feature branches for Git & Mercurial, which was a huge success with our users. This feature is also used by our internal JetBrains teams so extensively, that it is not clear how we were able to release at all BFBS (before feature branches support):

Build failure conditions, as well as NuGet support were introduced in TeamCity 7.0 in February of 2012! But more astonishing is the fact that this was the time when Agent Pools were introduced for the first time – with over 200 agents and more than 20 agent pools on the TeamCity server here at JetBrains, we see how efficiently our resources are allocated thanks to this feature:

TeamCity 6.5 made all features of the Enterprise Edition available in the free Professional Edition allowing unlimited number of users.

Multiple build steps – an indispensable feature today! – were announced almost 4 years ago, on December 1, 2010 when TeamCity 6.0 was released.

And finally, already 5 years ago, TeamCity 5.0 saw the light with cloud Build Agents on Amazon EC2 and issue trackers integration, which at present are unnoticed, as they are convenient and used every day!

We hope that you enjoyed our short history course. If you come to think of it, it’s pretty amazing actually how much our features have evolved, not to mention the user interface, which is way prettier now!

We would like to thank all of our you, our long-term users and supporters as well as newbies for your dedication to TeamCity! The new version is on its way, and we do hope that it will bring more cool features worth trying and remembering, so don’t miss TeamCity 9.0!

Stay tuned and happy building!

Posted in Blogroll, Design decisions, FYI, Uncategorized | Comments Off

TeamCity 9.0 RC is out

Hello everyone!

Winter has finally settled with cold and snow, and our code is frozen too to let us apply the final polishing touches before TeamCity 9.0 release.

We’ve been working our fingers to the bone, and today we are announcing the TeamCity 9.0 Release Candidate containing over 140 bugfixes since the previous EAP! We’ve made some improvements to our project import, REST API, and audit – for the complete list, please see our Release Notes!

Download the TeamCity 9.0 RC build today to keep you busy over the weekend! We can’t wait to see how this build works out for you in the end, so please share your feedback!

TeamCity 9.0 release build is on its way!

Stay tuned and happy building!

Posted in Bugfix, EAP, FYI, News & Events, Uncategorized | Comments Off

TeamCity VMware vSphere plugin

TeamCity always aims at giving your team more build power, and for those of you taking advantage of local cloud capabilities with VMware vSphere, the new TeamCity VMware vSphere plugin will surely be an asset. With this plugin, TeamCity can start and stop TeamCity agents installed on VMware virtual machines on demand, similarly to integrations with Amazon EC2 and Azure .

TeamCity-VMware cloud agent integration requires:

  • the TeamCity VMware vSphere Cloud plugin (compatible with TeamCity 8.1+) installed on the TeamCity server;
  • a configured virtual machine with an installed TeamCity agent in your cloud set up to start the TeamCity agent on boot,
  • a configured cloud profile on the TeamCity server.

Let’s go step-by-step and set up the integration.

Install the plugin and configure the virtual machine

Since the plugin is not bundled with TeamCity, we need to install it on the TeamCity server. Next we need to create a virtual machine where our builds will run.

The virtual machine with the TeamCity agent needs to be prepared as described in our documentation; when configuring the TeamCity build agent, be sure to specify the valid TeamCity server URL in the build agent properties.

After you start the build agent, it connects to the server, and you need to authorize it in the TeamCity Web UI so that the builds can run on the agent. Please ensure that the agent that connected to the server can actually run the builds you want it to run later.

When configuration and testing is complete, power off the virtual machine. If we want TeamCity to clone this virtual machine for us, we need to create a snapshot of this virtual machine.

You can also use the machine you created to make a template, see more information in the VMware vSphere documentation.

Configure the TeamCity VMware profile

Next we need to create an agent cloud profile in TeamCity on the Administration | Agent Cloud page selecting VMware vSphere as the cloud type.

A profile name is required; it is also recommended to configure the Terminate Instance Idle Time setting which will save you the resources: it specifies the period of time for the virtual machine to run without builds after which TeamCity will stop it. You also need to provide the cloud access information, including the vCenter SDK URL and your user credentials.

You can verify your credentials using the Test connection / Fetch options button, which also refreshes the information on the virtual machines, snapshots and resources available in your cloud.
Now we can add images and specify the virtual machines or templates we want TeamCity to use.

The VMware vSphere plugin can either start and stop an existing virtual machine, or clone virtual machines from snapshots deleting the clone after the machine is stopped. For templates only the clone behavior is supported.

Click Add Images and select the virtual machine and the desired behavior. For the clone behavior, select the snapshot to use, the folder for clones and the resource pool where your machine will be allocated. The maximum number of instances will limit the clones created.

In this test set up we are using the clone behavior with 2 being the maximum number of instances: TeamCity will clone a machine from the specified snapshot and will delete the cloned machine after it is stopped:

When the images are added and the profile is saved, a clone is created from the snapshot. It connects to TeamCity and TeamCity processes build configurations-to-agents compatibility.

As with all cloud integrations, you can view and manually start/stop the cloud agents on the dedicated Agents| Cloud page in the Teamcity Web UI:


Our integration is configured. Now when distributing queued builds, TeamCity will start a compatible agent in vSphere if required.

The agent will be authorized automatically and will start running builds. The Agents page will display the builds running on the cloned machines:


Try the plugin and don’t hesitate to share your feedback with us!

Happy building!

Posted in Blogroll, EAP, Features, FYI, How-To's, News & Events, Tips&Tricks | 6 Comments