TeamCity 2017.2 EAP4 is available

Greetings, everybody!

Today we are happy to announce TeamCity 2017.2 EAP4.

We have fixed about 110 bugs and worked on several new features, including:

  • .NET CLI plugin
  • Deployment type for build configuration
  • REST API / React pages
  • Kotlin DSL improvements

There’s more: details on these and other features, as well as the full list of fixes are available in our release notes.

Try this TeamCity version: either upgrade to the new EAP automatically or download the TeamCity 2017.2 EAP4 build as usual. As with every major TeamCity version, this release changes the TeamCity data format so make sure to install it on a trial server.

Your feedback is welcome here in the comments, on our forum or tracker.

Happy building!

Posted in Bugfix, EAP, Features | Leave a comment

TeamCity Kubernetes Support Plugin

Kubernetes nowadays is quite a popular way to run Docker containers. A number of teams and organizations already have a Kubernetes cluster configured and used in production.

Now with the help of the TeamCity Kubernetes Support plugin, it is possible to use the same infrastructure to run TeamCity build agents.

The plugin is compatible with TeamCity 2017.1.x and later.

First, download the plugin and install it on the TeamCity server as usual.

Then you can start by configuring a cloud profile in a project:


Specify the URL of the Kubernetes API server (aka Kubernetes master), select the appropriate namespace.

Select one of the Kubernetes API authentication options:


The next step after connecting to the Kubernetes API is creating a cloud image.


There are two options available:

  • Simply run single container: good choice for those who don’t know about all the powerful Kubernetes features but want to simply run its container;
  • Use pod template from deployment: will handle all the possible advanced scenarios of configuring workload to a Kubernetes cluster like multi-container pods, node/pod affinity and toleration, etc.

When the “Simply run single container” mode is selected, users can specify the name of the Docker image with the build agent they want to use.

In our setup, we are using the official TeamCity Build Agent image which is supported by the plugin. You can also create your own image.

Other options like Docker command, Docker arguments, and image pull policy, will be useful as well.


Another cloud image option is ‘Use pod template from deployment’.

Here you simply specify a deployment name: remember to check that the deployment belongs to the same namespace you’ve provided in the cloud profile. You can either use the official TeamCity Build Agent image in your deployment like in the example below, or your own image.


There is a small trick here. When given a deployment name, the plugin will not actually use it as deployment, but it will extract the PodTemplateSpec section from its definition and use it to create the plugin’s own pods. The plugin’s own pods means that the pods will not be connected to deployment anyhow. The Kubernetes deployments feature will not be used to manage the pods’ lifecycle. The TeamCity server will take care of those pods on its own. Deployment will be used as a container of PodTemplateSpec which can be referenced by name.

After a cloud profile is created and saved, you will be able to start TeamCity agents running in containers in the scope of the pods on the Kubernetes cluster. TeamCity will mark every started pod with a set of specific labels.


Using those labeled pods, you can always determine which TeamCity server started a particular pod, which cloud profile and cloud image are affected.

Feel free to download the plugin, try it, and share your feedback with us!

Or you can TestDrive it in the cloud.

Happy building with TeamCity!

Posted in Features, FYI, How-To's | 8 Comments

Welcome TeamCity TestDrive – a simple way to try TeamCity in the cloud

For a couple of weeks now, there has been a new button on the TeamCity website:

Screen Shot 2017-10-25 at 13.22.35

Clicking it allows you to access TeamCity in the cloud, hosted by JetBrains. We call it TeamCity TestDrive.

What is TestDrive?

TestDrive is a limited cloud TeamCity offering. It is a way to try TeamCity for 60 days, without the need to download and install it. TestDrive is currently hosted on top of server, and lets users create one TeamCity project. It is free but it has some limitations with regards to the software that’s on the build agents.

Why you should care

Have you ever had a project in GitHub, which you’ve always wished could be used with TeamCity, but weren’t sure whether it would be worth it? Or have you wanted to demo TeamCity to your colleagues or your boss, but never had the time or the resources to install it on a server? Or have you simply searched for an easier and faster way to try it? We believe TestDrive will help you with all the above, here is why:

Use TeamCity in the cloud, without installation
TestDrive is a great way to try TeamCity without the hassle of downloading and installing it on a server. It is hosted by JetBrains and runs just like any regular TeamCity would.

Set up and run your project in TeamCity for 60 days
You can set up a single project in TeamCity by simply providing a link to your version control system. After that, you have 60 days to work on it.

Export your project data
After the 60-day period elapses, or any time earlier, you can create a project export, which you can then import into a regular on-premises TeamCity, should you wish to continue working on it.

Invite collaborators
Send invitations to other people to join your TeamCity project.

It’s free
That’s it. We charge nothing for using TeamCity TestDrive.

Try TeamCity TestDrive

Some of the most frequently asked questions:

If I like it, can I continue using TeamCity in the cloud?
There is no hosted TeamCity offering provided publicly yet. The main purpose of TestDrive is to provide you with an opportunity to try TeamCity for 60 days. After that, we encourage you to download TeamCity. The default Professional edition is free.

Will I have dedicated Build Agents for my project?
The Build Agents which run all the TestDrive builds are shared among several projects, so the Build Agent time will be distributed proportionally between them. Depending on the load, there is a chance that build times might increase during peak hours.

Which software is available to me? Can I install my own?
The software on Build Agents is provided by JetBrains. Linux-based agents are currently available. Review the full list of installed software.

Do I have to wait until the end of the 60-day period to export my project data?
You can export your data at any time and use it for a regular on-premises TeamCity. After the 60-day period expires, your data (project and build configuration settings) will be stored on our servers and available for export for another 30 days, and then deleted.

What will be exported?
Exporting from TestDrive works exactly like a regular TeamCity project export. Currently, only project and build configuration settings are exported. Your builds, artifacts, test history, changes, users and groups are not exported.

Got feedback, questions, requests, or just want to reach the team behind TestDrive? Contact us via the feedback form.

Posted in Features, FYI, Release | 4 Comments

The official TeamCity CloudFormation template

As you might have noticed, there was recently an option added to the Get TeamCity page of our website: AWS. This lets you run TeamCity in AWS using the official CloudFormation template.


In this post, we will go over what’s under the hood of the template, and why it may save you some time and effort.

Usually, installing TeamCity on top of AWS is quite a time-consuming task.
It requires the following steps:

  • Setting up an external database,
  • Configuring the EC2 instance to run a TeamCity server,
  • Configuring it to then connect to the database,
  • Installing the TeamCity server,
  • Installing a TeamCity agent.

And then making the whole installation secure requires even more effort.

We have tried to ease this process and created an official CloudFormation template to run the TeamCity stack in AWS. Using this template lets you run all the above steps with just a single click. And should you decide to destroy the stack, CloudFormation also provides a super simple way to do it with just one click.

The template is located in the S3 bucket. The stack can be launched via the ‘Run on AWS’ button available on the TeamCity site.

The template provides several parameters:

It takes about 15 minutes for the template to deploy the whole stack, the most time-consuming task being the RDS Database instance roll up. Once the deployment is ready, you will see the TeamCity server endpoint in the Output section which points you to your TeamCity installation.


Just generate the root account and it’s ready to use.

So what is under the hood?

The TeamCity server runs on an EC2 instance with CoreOS Container Linux. The default agent runs as a separate container on the same instance. The external database is provided by an RDS MySQL instance. We decided not to introduce a custom AMI with TeamCity. Instead, we use the official Docker images with the TeamCity server and build agent.

The server and the database are placed in their own VPC which is completely secure. The DB allows only internal connections within the VPC. It’s only possible to connect to the Server via HTTP(s) or SSH.

How the server is running

There are several systemd services that prepare the LVM on the EBS volume to persist your data, create the file system, and run the latest official TeamCity Server and TeamCity Build Agent from the DockerHub images. Those services are linked to each other and roll the whole system back after an instance reboot or failure.

To connect to the server’s console, you need to use your instance key:
ssh -i instance-key.pem core@[server IP]
To see the logs, just run the docker logs command for the desired container.

Once you have TeamCity up and running, there are a few more steps to consider:

Happy building with TeamCity on AWS!

Posted in Features, FYI, How-To's | 23 Comments

TeamCity 2017.1.5 is released

Today we are announcing another update for the latest version, TeamCity 2017.1.5.

This build fixes about 50 problems, including a few performance and security issues: the full list is available in our release notes.

Don’t hesitate to install the new version: TeamCity 2017.1.5. uses the same data format as the other 2017.1.x releases, so you can freely upgrade/downgrade within these versions.

Download the new version and upgrade your server.

Your feedback on the new version is welcome in our forum and tracker.

We are also cooking another EAP for TeamCity 2017.2, so follow us for the latest news!

Happy building!

The TeamCity Team

Posted in Bugfix, Release | Leave a comment

TeamCity Integration with IntelliJ-based IDEs

Starting from its very first version, TeamCity has provided support for IntelliJ platform-based IDEs; and since they are products from JetBrains, this integration is the most powerful one when compared to other IDE integrations.

The main idea behind the integration is the ability to take advantage of all the features provided by TeamCity as a continuous integration server without leaving the context of the IDE: using the integration, you can configure notifications, run builds and tests, get the build status, view your changes, assign investigations and perform other actions available in TeamCity right from the IntelliJ IDEA. Besides, the integration allows cross navigation between the IDE and build results in TeamCity; for non-DVCS it allows you to test your local changes and see how they integrate with the source code before the commit, which ensures your changes do not break anything.

In this blog post we’ll go over the setup of the TeamCity plugin with IntelliJ IDEA.
TeamCity provides the same level of support for both IntelliJ IDEA editions: the free community edition and the paid ultimate edition. All the IntelliJ platform-based IDEs are also supported: JetBrains RubyMine, JetBrains PyCharm, JetBrains PhpStorm/WebStorm, and AppCode. The versions compatibility information is provided in the TeamCity documentation.

So, first we need to install the TeamCity plugin.

Installing the Plugin

There are two ways to install a plugin.

Installing from the plugins repository

You can install the plugin right from the IDE (connection to the Internet is required) using File | Settings | Plugins. Click Browse JetBrains Plugins and search for TeamCity Integration. Double-click on the listed plugin to download and install it.

Alternatively, you can download the plugin directly from the TeamCity server, which is especially useful if the Internet access is restricted in your organization.

Installing from the TeamCity server

Log in to the TeamCity server, in the right top corner, click the arrow next to your username and select My Settings & Tools on the right of your name. On the right, you will see TeamCity Tools.

  1. Click on the download link near IntelliJ Platform plugin and download to your local machine.
  2. After this, in IDEA, go to File | Settings | Plugins | Install plugin from disk… and in the explorer window, select the downloaded ZIP archive.
  3. Click OK.

Next we’ll restart the IDE is required to activate the plugin.

After the restart, the TeamCity menu is available at the top of the screen.

At the bottom on the left the TeamCity tool window 1aTeamCitybutton is visible, on the right we now have the TeamCity ‘Logged out’ status icon1bNotLogged.
Now we can connect to TeamCity.

Logging in to TeamCity

To log in to the TeamCity server, click TeamCity | Log in… and provide the required credentials:


After you log in, if you installed the plugin from the IDE, you might have to update the plugin to the version corresponding to the TeamCity server you are connected to using the TeamCity | Update plugin menu item.

Now let’s see the integration in action.

Configuring Notifications

Next we’ll configure notifications which the TeamCity server will send to our IDE. This can be done using TeamCity | Options | Edit Notification Rules or by clicking a link in the TeamCity tool window asking you the specify the projects you want to watch: either of the options redirects you to the Notification Rules page in the Web UI of the TeamCity server you are connected to. By default, TeamCity sends out IDE notifications to the user if a build containing their changes fails. You can add your own rules here:


TeamCity will track the changes by the username specified in the VCS Usernames section.

Open Files from TeamCity in IDE

When looking at changes in the TeamCity Web UI, you can open changed files from in the IDE:


Clicking the IDE link opens up the specific file in the active IDE, i.e. the IDE we are currently connected to.

You can also work with all changes: in this case the patches are downloaded to the IDE, and they can be applied to the working directory as required.

Working with TeamCity from IDE

At the bottom on the left the TeamCity tool window has the Projects, My Changes, and My Investigations tabs, which correspond to the options available in the TeamCity Web UI.

The Projects tab displays projects and build configurations we decided to monitor. It also allows us to configure more visible projects by redirecting us to the TeamCity Web UI.

Let’s run a build from the IDE: right-clicking the build configuration name (Build in the image below) opens a menu allowing you to add a build to the queue, view pending changes, assign and investigation to any user registered on the TeamCity server you are connected to, mark an investigation as fixed, open the build configuration home page in the browser.3ProjectsBuildOpts

The My Changes tab displays all changes made by you and detected by TeamCity according to the specified username:


You can filter the changes and see only those related to the project you are currently working on:


It is easy to see the details of a specific commit in the IDE or quickly open the TeamCity change details page in the browser by right-clicking on the change and selecting the required option:


If you are assigned to investigate problems (typically build failures caused by your changes) in TeamCity, you will your investigations in the My Investigations tab.
As you can see, the TeamCity plugin enables you to run builds, view change details, assign investigations and perform other actions available in TeamCity without leaving IntelliJ IDEA.

Committing Pre-Tested Changes to Non-DVCS

In our project we are using the most popular version control at the moment – Git, and we use Git branches to test how our changes integrate with the existing code. In this part we’ll talk about the feature that can help if your project uses centralized version controls (like Subversion (SVN) or Perforce).
Using the pre-tested commit feature, you can prevent committing defective code into a build, so the entire team’s process is not affected. First the developer runs a build in TeamCity with the local changes on the developer’s machine and if this remote run is successful, the changes are committed to the version control automatically.

“Remote” means that the build will not run on the developer machine, but on a TeamCity build agent and this build will include the changes on our developer’s machine and the code in the version control: this way we can see how our changes integrate with other changes in the repository and be sure that our changes will not break the code.

If the remote run (also called ‘Personal Build’) fails, we will get a notification and can roll the changes back or fix the issues.
To trigger a remote run, we’ll use the TeamCity | Remote Run menu item. In the dialog that is displayed, select all changes you made locally or cherry-pick just the changes you want to test on the build server like we did. It is possible to select when to commit the changes: our changes will be committed if no builds fail. All whats left is to click the OK button and the remote run starts:8pretestedCommit

Debugging Java Code Remotely

We already mentioned that TeamCity integration supports all IntelliJ-based IDEs: it is programming language agnostic. However, some of its features are limited to a particular technology, and the next feature we’ll talk about is Java-specific.

The TeamCity plugin for IntelliJ IDEA allows you to debug your tests remotely on the TeamCity agent machine from the IDE on the local developer machine. The remote debug feature is useful if the agent environment is unique in some aspect, which causes a test to fail, and it is difficult to reproduce the problem locally.

You can use this feature if the following requirements are met:

  1. an IntelliJ IDEA run configuration (Java application run configuration /JUnit run configuration /JTestNG run configuration) on the local developer machine with the TeamCity plugin for IntelliJ IDEA is installed
  2. a build configuration on the TeamCity Server with the IntelliJ IDEA Project runner as one of the build steps
  3. a remote TeamCity agent to run this build available to the local machine by socket connection

To start debugging, select the TeamCity | Remote Debug menu item. You will be asked to select the run configuration to debug.
(Alternatively, you can right-click tests and select the Debug Remotely on TeamCity Agent option from the context menu.)


Now we click Debug Remotely on TeamCity agent. The build is added to the queue and the standard IntelliJ IDEA debug tool window appears.The debug tool window works in the listening mode, i.e. it waits for the agent to connect to it. Once the agent connects, the Java process on the agent is paused and the Agent Attached notification appears in the IDE. Now we can set some breakpoints, and actually start the debug session by clicking Start either in the notification popup or in the debug tool window.


When the build is finished, you can view failed tests in the IDE:


Once the JVM process exits, another notification popup appears in the IDE:
The debug session is not finished yet, it is possible to either repeat or finish it. Selecting Repeat will rerun the same build step again, which is much faster than starting a new debug session.

Well, we’ve covered some of the most popular features of the TeamCity-IDEA integration and really hope we managed to persuade you to try the integration.

Your feedback is most welcome as usual herehere in the comments or ourissue tracker.

Happy integrating and building!

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

TeamCity Docker Images for Windows

teamcity-docker-windowsSome time ago we’ve published official TeamCity docker images for Linux. Since then Microsoft, together with Docker released support for Windows containers. And now we’re glad to announce official TeamCity Docker images for Windows containers.

TeamCity Windows Docker images are based on windowsservercore and nanoserver images and have corresponding -windowsservercore and -nanoserver suffixes in tags.

For Windows we provide the same set of Docker images as for Linux containers:

For instance, to run a nanoserver based TeamCity server, you can execute the following command:

To connect TeamCity build agent to that server you could execute the following command:

Note: due to limitations of Docker on Windows, you may not be able to access TeamCity server on localhost via http://localhost:%port% address. If this is the case, you should use non localhost IP address of your machine.

Due to some other known issues, we’d not recommend to run a production TeamCity server in Windows containers right now. But it seems fine to run a TeamCity agent inside a Windows container.

Please try these images and let us know what you think.

Happy building!

TeamCity Team


Posted in News & Events | Tagged , , | Leave a comment

Docker integration plugin now available for 2017.1.x

Greetings everyone!

As you might already know, TeamCity 2017.2 EAP builds provide new Docker integration features. They are provided by the Docker Support plugin, which is bundled with TeamCity 2017.2 EAP by default.

Today we are making this plugin available to users of TeamCity 2017.1.x as well. If you are already on 2017.1.x and use Docker, we believe the Docker Support plugin will make your life simpler, and here is why:

  • The “Docker Build” runner helps create your own Docker images.
  • The “Docker Compose” runner allows starting services using Docker Compose during your build process. The TeamCity agent will stop these services automatically when the build finishes.
  • The Command Line, Gradle, and Maven runners are also extended with the ability to execute inside a Docker container. Check this blog post for a usage example.
  • Finally, the “Docker Support” build feature provides more convenience features like:
    • automatic login to a Docker registry before the build starts;
    • the “Docker Info” build tab with information about images published to the Docker registry during the build;
    • the option for automatic deletion of the associated images from the registry when the build is deleted during the TeamCity cleanup procedure.

For details, take a look at the integration documentation.

If you wish to try this plugin, there’s nothing to stop you:

Oh, wait, there is one more option. You can actually TestDrive it in the cloud!

Happy building!
The TeamCity Team


Posted in Uncategorized | 7 Comments

TeamCity 2017.2 EAP3 is released

Greetings everybody!

We continue working on the new TeamCity version and today we are announcing TeamCity 2017.2 EAP3.

This release brings you over 90 fixed issues, as well as a number of new features which we are sure you’ll find useful:

  • TeamCity now supports automatic upgrade which can be initiated from the Administration | Update page.
  • We introduce default templates, that can be defined in a project and used to collectively modify build configurations of this project.
  • Good news for Kotlin fans – now when Kotlin settings are enabled for a project, project and build configuration settings will be available for editing from the web UI.

Please refer to the Release notes for the full list of improvements including those in composite builds, Docker support and more.

Upgrade to the new EAP version either automatically or download TeamCity 2017.2 EAP3 build as usual. Remember to install it on a trial server as it changes the TeamCity data format.

We’ll be happy to get your feedback here in the comments, on our forum or tracker.

Happy building!
The TeamCity Team

Posted in EAP, Features | 2 Comments

TeamCity Plugin for HashiCorp Vault

When performing integration tests and deployments, build scripts need credentials to access external servers and services. Traditionally passwords are stored on the TeamCity server as secure parameters. But although secrets are masked in the UI, encrypted at rest, and protected from being exposed in the build log as plain text, this often does not provide a high enough level of security.

HashiCorp Vault offers a unified approach to managing secrets and credentials, allows auditing access, and helps with password rotation.

Integration with Vault

Today we are presenting a new plugin to help build scripts interact with Vault and obtain credentials dynamically.

The plugin allows connecting TeamCity to Vault, requesting new credentials when a build starts, passing them to the build script, and revoking them immediately when the build finishes.


We expect you have installed and configured:

  • a Vault server. Refer to the Getting Started guide to learn how to launch a testing Vault instance.
  • A TeamCity server. Refer to the Getting Started guide for details.

Perform the following:

  • Download the plugin from the plugin repository, and install it to TeamCity server.
  • Configure secret backends in Vault to obtain secrets, for example AWS credentials, or generic secrets.
  • Create an AppRole in Vault for the TeamCity server to access these backends.
  • Create a connection to Vault in your TeamCity project:1
  • Next in your build configuration declare new build parameters which refer to the Vault secrets to be used in this build:


The parameter value has a special syntax:%vault:PATH!KEY%where PATH is the secret name, and KEY is the specific value inside.
At the moment these values can be used in the build parameter declaration only, and cannot be specified in build steps.

  • Run a build step. Deployment scripts can read credentials from environment variables, and do not need to perform any Vault-related actions:3

Besides AWS, any other Vault backends can be used. In this case:

  • Declare a configuration parameter with a value from generic backend:4
  • In a build step refer to this  parameter explicitly:5

How It Works

  • The TeamCity server stores the AppRole ID and secret, and keeps the secret encrypted at rest. When required, it can be rotated manually in the UI, or via the REST API.
  • When a new build is started, the TeamCity server requests a one-time response wrappingtoken in Vault, and sends it to a build agent.
    The AppRole secret never leaves the TeamCity server machine.
  • The build agent requests the actual secrets from Vault.
    The actual credentials are obtained from Vault by a build agent machine directly, and never transferred to the TeamCity server.
  • The build parameters are resolved and the secrets are passed to environment variables and system properties.
  • The build steps are started, and they refer to these environment variables and system properties.
  • If secret values appear in a build log, they are automatically replaced by asterisks.
  • Right after the build finish, the credentials are explicitly revoked in Vault.

Security Considerations

It is advised that you limit access to TeamCity project settings. If a person can modify build configuration settings in a TeamCity project, they can get access to the secrets. Dynamic credentials are revoked after a build, but for generic secrets this may cause more risks. To minimize the risks, split build configurations for CI and deployments into separate projects with different permissions.

Make sure build agent machines are connected to the TeamCity server via HTTPS. Only one-time tokens are transferred over network, and if they are stolen, credentials will be immediately revoked. However, it is a good practice to encrypt all traffic between the server and agents.

Feedback Wanted

This is an initial release, and we continue to improve features and user experience, and encourage you to give it a try and tell us what do you think!

The plugin is open-sourced, and published on GitHub.

If you are attending HashiConf in Austin, TX, USA next week, visit the JetBrains sponsor booth for the demonstration of this plugin and our other plugins for integrating Packer and Terraform with TeamCity and IntelliJ-based IDEs.

Posted in Features, FYI, How-To's, Tips&Tricks, Uncategorized | 5 Comments