Maximize Power and Efficiency with Integration of TeamCity and Issue Tracker

This guest post is brought to you by StiltSoft.

stiltsoft_logoStiltSoft is a small team of Atlassian Experts and avid fans of JIRA and Confluence. StiltSoft is the Atlassian Verified vendor that develops TeamCity Integration for JIRA add-on. This add-on allows you to fetch commit data from a TeamCity server and show the relevant information for each associated JIRA task.

The 21st century is being driven by digital data streams that bring gigabytes of data to some processing server that combines, aggregates, and transforms them into user-friendly forms. Nowadays global systems receive data from multiple systems, and this cannot be imagined without complex integrations, data conversion, optimization, and adaptation to the central processing data storage.

Software development is one of the most data-consuming spheres, which also tries to bring order to these data streams and set the right direction for them. Software development requires the continuous tracking of all changes made in the program code, instant real-time update of the relevant information, and easy-to-use interface.

Software development cannot exist without a continuous integration server and an issue tracking platform. TeamCity is one of the most popular continuous integration servers that offers out-of-the-box integration with multiple issue tracking systems and provides easy instructions for establishing integration with other systems or applications.

Basic Principles of Integration

TeamCity server can be quickly and easily integrated with the following issue tracking systems:

The integration is established on the basis of the tracker connection, and the administrator has to select the appropriate issue tracking system:


The configuration of the connection to the issue tracker is quite simple and does not require much time or experience. The set of parameters differs a little bit because of the target system specifics.

Integration with issue tracking systems requires the following:

  • Server URL – the URL address of the issue tracker
  • Username and Password – the account credentials for data transfer and retrieval
  • Project Keys/IDs – the unique keys/IDs of projects that will be used for matching issues to TeamCity builds


If integrating with YouTrack or JIRA, you can automatically fetch all project keys or IDs from the issue trackers. This is quite convenient as you don’t need to enter all project keys but instantly fetch them from the issue tracker.

When a developer commits code changes he can leave a VCS comment, which will be further shown in TeamCity.


Issue IDs or keys can be left in VCS comments and are used during integration for matching builds to issues and showing the corresponding information.


You can view the issue log for the whole branch. It shows the list of issues from the issue tracking system and the status of each issue. If needed, you can instantly proceed to the issue tracking system by clicking the issue link.


TeamCity and YouTrack: Out-of-the-box Integration

Output of build data in issues of issue tracking system is even more valuable and useful than showing issues in TeamCity. Display of this data allows multiple teams of developers and quality assurance engineers to better collaborate and interact during the project development.


In YouTrack, the following data is available:

  • User who committed a piece of code
  • Date of commit
  • Related issue from VCS comment
  • Modified files

If a build was run with a special command, the corresponding information will be displayed.

But before the TeamCity build data is shown in YouTrack, the administrator needs to configure access to the TeamCity Server, which includes the server address, user credentials, and connection timeouts.

Once the connection is established, the administrator has to define the project mapping in TeamCity and YouTrack, as follows:


Once this is done, the administrator needs to manually run the synchronization and then the TeamCity data will appear in YouTrack.

If integrating TeamCity with YouTrack, you can also use special commands to automatically perform basic operations on the referenced issues once you have committed changes. For example, you can add into the VCS the ‘#ID-2544 Fixed‘ comment, so the current issue will be changed to the Fixed status. You can add a comment for multiple issues, as follows ‘(#TST-12, #TST-324, #TST-433) Fixed Reviewed by john.d Revision ${revision}‘ or log work for the issue ‘ID-2544 Fixed work 3h‘.

This native integration is developed by JetBrains, so they added as many as possible features for profound interaction between TeamCity and YouTrack. Besides the retrieval of build data and its display in YouTrack, you can trigger remote actions that can simplify the overall experience and automatically initiate specific remote actions in the issue tracking system. A capability to quickly switch between TeamCity and YouTrack will also positively influence performance of developers.

Integration between YouTrack and TeamCity provides you with a seamless way to interact with TeamCity and continuously get updated data. This solution is ideal for experienced bearded developers digging through tons of code as they will reveal all its capabilities and will use them in their everyday work.

TeamCity and JIRA: Integration with Ease

Integration of TeamCity and JIRA can be done by means of StiltSoft’s add-on – TeamCity Integration for JIRA.

The add-on adds a dedicated tab on the Issue View screen and allows you to find out the following information:

  • builds associated with the current issue
  • unique build number
  • build start time
  • build duration
  • status of tests run after build completion
  • the user who committed files
  • commit log

If needed, the user can click the appropriate link and seamlessly proceed to the TeamCity section containing details about the specific item. If having multiple commits associated with the current issue, you can filter them by status, build period, agent, and project.


In the dedicated section for each project, you can view the current build activity for your projects and quickly find which modifications have been already completed.

Optionally, you can add two gadgets to JIRA dashboard. The first gadget allows you to output the activity stream from TeamCity server, the other one shows the list of available build agents so you can easily monitor what agents are available at the moment and launch tasks for the current agents.


The add-on supports integration with multiple TeamCity servers and with JIRA Data Center. The administrator needs to configure an application link to fetch data from one or multiple TeamCity servers. While configuring an application link, the administrator needs also to enter the address of TeamCity server and enter credentials of the user account having access to this server. The configuration process is quite quick and intuitive.


This integration differs a bit from the native integration between TeamCity and YouTrack. Intuitive setup of the add-on and its flexible configuration allow you to adjust data indexation and its performance. The output of build data, as well as availability of TeamCity agents, positively influences the development process.

This solution will be ideal for developers, project managers, and software test engineers as each of them will use specific features needed in their everyday work. So PMs can monitor the status of projects with the gadgets shown on the dashboard, the software test engineers can find details on the changes added in each commit and check the status of run tests, and developers will be able to seamlessly transition to TeamCity to view details if needed.

TeamCity and BugZilla: One Way Ticket

Unlike YouTrack and JIRA, BugZilla does not support two-way integration between TeamCity and the issue tracker. So you cannot view the TeamCity build data in BugZilla in the same way as you can in YouTrack and JIRA.

Anyway, the data from BugZilla can simplify your experience with the continuous integration server, as you can quickly and easily get data about the issues mapped to the current build and commit.  This solution is the least convenient and user-friendly, so you’d better start with it once you have tried the two solutions mentioned above… just to return to them after 5 minutes spent in BugZilla :-)

TeamCity and Issue Tracker Integration: To Be or Not To Be

So is it worth establishing integration between TeamCity and issue tracker? Definitely, yes. And there are several reasons for this:

  • Your data is automatically mapped in your TeamCity and issue tracker.
  • You can easily track all updates and modifications in your projects.
  • You can quickly find out what, when, and by whom was committed to the project repostory.
  • Your development and quality assurance teams can work much more efficiently.

Want more? Try to integrate TeamCity and issue tracker and find out benefits for your company!

Posted in Blogroll, Guest post | Comments Off on Maximize Power and Efficiency with Integration of TeamCity and Issue Tracker

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.

Read all the TeamCity Digests.

Posted in Blogroll, Digest, FYI | Comments Off on TeamCity Digest #2

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 | Comments Off on TeamCity and NUnit 3: on the Same Wavelength

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 on TeamCity 9.1.4 is released

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 on Continuous Integration with JavaScript, December 2nd Webinar

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.

Check all the TeamCity Digests.

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 on TeamCity 9.1.3 hotfix is available