TeamCity Digest #2

We’ve decided to continue posting such digests every now and then, so that you could also benefit from the interesting content shared with us via twitter or other media.

Here is the list of articles, videos, and other materials that caught our attention. Hope they will be of interest to you as well.

Pivotal blogs about setting up a continuous deployment process for iOS apps which implies running unit tests on each commit pushed to master, and being able to deploy the latest successful build to staging at any time: iOS Continuous Deployment with TeamCity and HockeyApp.

Our colleague Hadi Hariri has released a Rundeck plugin for TeamCity:

We have also stumbled upon two online courses about CI and CD practices with TeamCity as a tool of choice:

An article by Rouan Wilsenach of ThoughtWorks walks you through the process of setting up a deployment pipeline in three steps: Running the gauntlet: Setting up your first deployment pipeline.

For those of you who are interested in running TeamCity in Azure, here are two interesting articles which describe how it can be done.

How running unit tests for Windows Store is different from running standard .NET framework unit tests: Running Windows Store Tests in TeamCity.

A comparison of TeamCity and Bamboo as a CI server for a project with 10k lines of puppet code: Continuous Integration of Puppet Code.

A blog post from Nordeus about bringing automation to Unity builds with TeamCity as their core build server: Automated Unity Builds.

These are just a few publications that we came across recently. Let us know if you have something to share, or if you think your own blog post, article, video, etc. might be valuable to the readers of TeamCity blog. Follow us on twitter @teamcity and feel free to ping us if you find something interesting.

You can read the previous TeamCity digest here.

Posted in Blogroll, Digest, FYI | Leave a comment

TeamCity and NUnit 3: on the Same Wavelength

For the last couple of months we, the TeamCity team, have been working really hard together with the NUnit team, and today we are happy to announce NUnit 3 has been released and is fully integrated with TeamCity out of the box.

Imagine any way to run NUnit tests, and all your wildest solutions will most likely work perfectly in TeamCity: you could run NUnit tests just from the command line, or using the MSBuild task, or via the NAnt project, or you may prefer to run tests using the NUnit step and would like to take advantage of the the full power of TeamCity – everything is possible now. TeamCity helps you to do it on all operating systems and at any time of day or night.

You will see real-time progress during the tests’ session. After completing the build, the Tests view allows you to analyse the build results via the user friendly UI, where you are able not only to see the test results, but also to manage them: mark an investigation as fixed, give up the investigation, re-assign it, or mute a test failure.

For a long time it was necessary to use different tricks to achieve a similar result and while most of the tricks worked fine for simple cases, it was difficult to understand how to make it work when something goes wrong. For example, you had to use the special NUnit JetBrains task, that is very similar to the NUnit task from MSBuild Community Tasks project, to run NUnit tests under the MSBuild project in TeamCity. Now you are free to use NUnit in TeamCity without any additional tweaks: just use the TeamCity command line runner to achieve your goals:

NUnit 3 in the TeamCity sample

Don’t hesitate to take advantage of this integration: download NUnit 3 and to run tests under TeamCity!

We are working on the the Getting Started guide to enable you to begin using NUnit 3 in TeamCity instantly: we hope it will  save your valuable time, because it is our mission to make your work fun and easy.

Happy building and testing!

Posted in Case study, Features, FYI, Tips&Tricks, Uncategorized | Leave a comment

Automating Deployments with TeamCity and Octopus Deploy

This guest post is brought to you by Paul Stovell, creator of Octopus Deploy.

octopusdeploy_logoOctopus is a deployment automation server for .NET developers. Octopus takes over where your build server finishes. The build server builds the code and runs tests, while Octopus takes care of deployment.​

TeamCity is a powerful continuous integration and build automation tool. Scroll through the list of built-in build runners and build features in TeamCity, and you’ll find almost any activity that you could want to perform during a build. It can restore NuGet packages, compile solutions, run unit tests, patch AssemblyInfo files, inspect code quality, and capture code coverage metrics, just to name a few. You can also combine multiple builds together to form a chain of builds, which is a powerful way to orchestrate an entire continuous delivery solution.

TeamCity can also be used to deploy your application during the build. This is useful if you want to deploy it to a test environment for users to test, or even automate deployments straight to production. You can even chain builds in TeamCity to make promoting between Test and Production environments possible. You can do this by telling TeamCity to call your script or command-line deployment tool during the build:

octopus_post1 Unfortunately, while TeamCity provides some high-level build activities like compiling with MSBuild or running NUnit tests, it doesn’t provide any high level deployment related tasks (“Configure IIS”, “Install a Windows Service”, “Update this configuration file”, etc.). “Run a script” is where TeamCity begins and ends; it’s up to you to write that script. Most teams solve these problems themselves, by writing their own deployment automation scripts, by combining tools like WebDeploy and PowerShell Remoting. Along the deployment automation journey, teams often encounter similar problems:

Problems/stumbling blocks
Possible solutions
Binary distribution
Many files are needed to deploy an application. Binaries (DLLs, EXEs), CSS and JavaScript files, images and other assets, configuration files, and so on. How do we distribute these files to remote machines? How do we do this securely and ensure no tampering when transmitting over insecure networks?
FTP(S); rsync; file shares; WebDeploy
Remote execution
Some tasks must execute directly on the remote machine (e.g., configuring IIS sites and Windows Services, installing COM components, making registry changes). How will we invoke these tasks? Is it easy to read the output? How will we detect failures? How do we deal with authentication?
SSH; PowerShell Remoting; WinRM; WebDeploy; PSEXEC; Remote Desktop
Configuration differences
Each environment is different. Different connection strings, different network paths, different credentials, etc. How will configuration files be modified?
Multiple copies of files renamed during deployment; XPath transforms; .NET Configuration transform files; PowerShell
Deployments often involve many machines. How do we distribute files and install applications in parallel to keep downtime to a minimum? What if each server has different settings?
Custom logic in scripts. Be careful to maintain it and not treat it like throwaway code.
Visibility and security
If different steps in the deployment run on different machines, how will we handle authentication/authorization? Can we allow testers to deploy to Test but restrict who can deploy to Production? Are changes audited and easy to roll back? Can anyone on the team easily see what is deployed where?
TeamCity dashboards; chained builds; build permissions

Four years ago, these were the kinds of problems we faced when it came to writing our own deployment scripts for client projects. We wanted something that elegantly solved the problems above, and which could work in the most secure environments, and yet would be as easy to use as the high-level build runner tasks in TeamCity. That’s why we built Octopus Deploy. Where TeamCity is a build automation server, Octopus is a deployment automation server. Like TeamCity, Octopus is free for small teams. When you use TeamCity and Octopus together, the goal is to let TeamCity do what it does best – build – and let Octopus take care of deployments. octopus_post2 TeamCity is responsible for:

  • Detecting source control changes
  • Compiling the solution
  • Running unit tests
  • Inspecting code, gathering build metrics, etc.
  • Packaging the application ready for deployment
  • Using our TeamCity plugin, notify Octopus that a new release is available

While Octopus is responsible for:

  • Distributing the packaged applications to the remote web/application servers, all in a secure way
  • Extracting and installing them
  • Modifying configuration files with environment-specific variables
  • Configure IIS, install and update Windows Services, etc.
  • Invoking any custom deployment actions on the remote machines
  • Gathering all the deployment logs into a central place

And just as the dashboard in TeamCity gives you an overview of your builds, the dashboard in Octopus gives an overview of your deployments: octopus_post3 If you have a build pipeline in TeamCity, extending it to deployment can do wonders in giving your team a tighter feedback loop. Writing your own custom scripts and invoking them from TeamCity isn’t the only option; the next time you find yourself automating deployments from TeamCity, have a look at Octopus Deploy.

Posted in Blogroll, Guest post | 6 Comments

TeamCity 9.1.4 is released

Today we’re issuing TeamCity 9.1.4 bugfix release containing over 120 fixes and some feature refinements.

There is a couple of improvements in our Amazon EC2 integration: apart from tagging instances started by TeamCity, Amazon EC2 Spot Instances are now supported.

.Net platform support has also been polished and this TeamCity release includes:

  • the latest NUnit 3.0 compatibility fixes;
  • updates for the bundled tools: ReSharper Command Line Tools and dotCover have been updated to version 10.0;
  • fixes for the issues with .Net inspections when the latest .Net framework versions are targeted.

A number of issues with NuGet feed have been alleviated in this release and TeamCity supports NuGet 3.2, but its automatic distribution to agents is not yet available as Microsoft does not provide new versions of nuget.exe wrapped in NuGet packages. As a workaround, this NuGet.exe v3.2 package can be uploaded to the TeamCity server via the NuGet administration UI.

Apart from this, we’ve tackled a few performance issues and fixed about a hundred other problems: see our Release Notes for the full list of fixes.

Download this release and upgrade your TeamCity to take advantage of the latest improvements. As usual, our bugfix release does not modify the data format and you can easily upgrade/downgrade within TeamCity 9.1.x versions.

Happy building!

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

Continuous Integration with JavaScript, December 2nd Webinar

Join us Wednesday, December 2nd, 10:00 AM – 11:00 AM EDT (15:00 – 16:00 GMT) for our free live webinar Continuous Integration with JavaScript, featuring Wes Higbee.

In this webinar you will learn about building and deploying JavaScript applications with TeamCity. We will cover dependency management, use of module bundlers like Webpack or SystemJS for the ECMAScript 6 code, and unit testing with Karma, and we’ll see how TeamCity can be a safety net for deployments.

We believe that this webinar is going to be interesting for anyone doing front-end development and interested in applying Continuous Integration practices to it.

Space is limited, please register now.

The recording will be available after 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 Blogroll, Webinar | Comments Off

TeamCity Hub plugin

Greetings, everyone!

Today we are releasing the first version of the plugin for TeamCity which provides integration with JetBrains Hub, a single point of entry for user management across all JetBrains team tools.

The first version of the Hub plugin for TeamCity handles authentication via Hub and user details synchronization; so if you are already using Hub, install our plugin to enable single sign-on (SSO) and to automatically update user details from Hub in TeamCity.

The current plugin version is compatible with TeamCity 9.1.x and Hub 1.0.

Download from here and install it on your TeamCity server as usual. After the server restart, the integration can be managed using the Administration | Hub Settings page.

Please refer to the documentation for the usage details.

We keep working on the TeamCity-Hub integration, and your feedback is greatly appreciated!

Happy connecting and building!

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

Make profiling a part of continuous integration (.NET)

If you’re a .NET developer who doesn’t follow our ReSharper Ultimate blog, then you probably missed a couple of blog posts about two new cool features in our dotTrace and dotMemory .NET profilers. Why are we writing about them in the TeamCity blog? Because these features are closely related with TeamCity and CI in general: they allow you to make performance and memory profiling a part of your continuous integration builds. So what is this hype all about?

Performance profiling in CI

Let’s begin with dotTrace and performance profiling. Along with dotTrace 6.2, we released a dotTrace Plugin to TeamCity. It allows you to prevent application performance regression by profiling your integration tests. The workflow is pretty simple:

  1. Write an integration test that runs some performance-critical functionality in your application.
  2. In the plugin, set a performance threshold for this test, which is the execution time value in ms or value taken from previous successful builds.
    Now, if the test exceeds its threshold, the plugin will fail the build and save the collected performance snapshot to build artifacts.
  3. Open the snapshot in dotTrace and find the exact cause of the performance issue.

dotTrace Plugin Build Overview

dotTrace Plugin Build Log

More details on the plugin are available in this post.

Memory profiling in CI

Not so long time ago we released dotMemory Unit – an additional unit testing framework that allows you to write tests that check your code for all kinds of memory issues, including memory leaks, high memory traffic, etc. For example, here’s how easy it is to check memory for objects of some Foo type with an NUnit test:

Now the time has come for the dotMemory Unit standalone launcher that can be used in CI. For TeamCity users, we have something even better: a dotMemory Unit plugin. This plugin adds the support for dotMemory Unit to all TeamCity .NET test runner types. This means you can run tests that use dotMemory Unit along with other tests on your CI server.

dotMemory Unit Failed Test

For more information on the dotMemory Unit plugin, please see this blog post.

You’re welcome to give the plugins a try! Note that they are absolutely free, so this won’t cost you anything.

Posted in Features | Tagged , , | 3 Comments

TeamCity Digest

As software builders, we always want to be on top of things, so we monitor the environment for anything new that comes up in the world of continuous integration and continuous delivery. Every now and then we stumble upon articles, blog posts, and tweets about various ways of TeamCity usage, new integrations, plugins, or just news that is relevant.

Here is the list of publications that have recently caught our eye. We found them useful, and we hope you will as well. now provides a community build server based on TeamCity: They’ve recently held a webinar about it, which you can watch in recording: Discovering TeamCity and Build PowerShell org.

This article covers some steps for those who are doing continuous integration on a Xamarin app: What to consider when doing Continuous Integration on a Xamarin app.

There is a new integration for TeamCity and DataDog, a cloud-scale monitoring tool: Track performance impact of code changes with TeamCity and Datadog

Good news for the PHP community using TeamCity:

While there is no out-of-the-box support for Docker in TeamCity, this article explains how the two can be used together with the help of an external plugin: CI with Docker and TeamCity.

This one guides you through preparing your build server to build VS 2015 projects: Getting Your Build Server Ready for VS 2015.

And here the author focuses on xUnit and dotCover meta-runner: Showing the love for and dotCover in Teamcity.

These are just a few links that have come to our attention recently. We are sure there are many more blog posts, news, tutorials, and other materials around, which could be useful for TeamCity users like you.

If you are interested in reading more of such digests, please let us know in the comments. And feel free to share such content with us via twitter @teamcity.

Posted in Blogroll, Digest, FYI | 1 Comment

TeamCity 9.1.3 hotfix is available

Hello, everyone!

We’ve decided to publish 9.1.3 bugfix release with a fix for critical regression which has been reported to us recently:

  • TW-42498 – As of 9.1.2 having a hashbang in a Command Runner script no longer works.

If you already downloaded 9.1.2 and planned upgrade during this weekend, please download 9.1.3 instead.

Release notes
Download page

Sorry for inconvenience and happy building!

Posted in Uncategorized | Comments Off

TeamCity 9.1.2 is here


Greetings, everyone!

Today we’re announcing the arrival of TeamCity 9.1.2, a bugfix to the latest TeamCity version.

Build 37168 addresses over 100 problems, and we are thankful to our careful users for reporting issues and helping us make TeamCity better.

The problem with updating Subversion VCS roots containing parameters, which surfaced after upgrade to TeamCity 9.1.1, has been resolved. There are also several important security-related fixes.

This version also includes updates to the bundled tools, and now TeamCity comes with:
- ReSharper command line tools 9.2
- Visual Studio Addin Web installer from R# Ultimate 9.2 release
- dotCover 3.2.

See the full list of fixed issues in our release notes, download the new build and don’t hesitate to upgrade: this release does not change the data structure, so you can roll back to one of the 9.1. versions easily if required.

Oh, and by the way now TeamCity features new build status icons (.png and .svg) available via a REST API request:

statusIcon (1)



May you have successful builds only and Happy building!

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