Here’s a post I wrote for the Techtown blog a while back. The original is here. Techtown also offers a course about using TeamCity for Continuous Integration. I am a big fan of Jetbrain’s products, especially this one.


TeamCity is a continuous integration server that supports building and deploying a variety of different project formats, including those from IntelliJ Idea and Visual Studio. Developers can verify check-ins before committing them to version control, customize build parameters and track version control and build history in one place.

In this tutorial, we’ll learn the basic of how to use TeamCity by configuring a Java project on TeamCity, building it, view unit test results, break the build with a code check-in, and then fix it again.

Let’s get to work.

Create a New Project

First, go to your TeamCity’s URL and log in. If this is your first time logging in, you will need to get a username and password from your server administrator.

Next, click Administration on the upper right-hand side of the overview page. This will take you to the administration area where you can create a new project.

TeamCity Create Project
Click the Create Project button.
TeamCity Add Project VCS
For this example, add the new project with a repository URL. Enter the URL and the authentication information for the source repository and click Proceed.

Even though TeamCity has specific support for GitHub, we are inputting a GitHub URL as if it were any Got system. We’ll cover GitHub support in a later unit.

Next, TeamCity prompts for a project and build name. Accept the defaults and click Proceed.

TeamCity will check the project out and analyze the build script to determine how to build it. TeamCity supports Maven, Ant, or Gradle for Java. It works with MSBuild or NAnt for .Net.  It can also manage Ruby projects with Rake, as well as a variety of other build tools with other languages.

This is a simple Gradle project, so after a few moments, TeamCity offers two different build steps.
TeamCity Select Build Steps
The first is to call Gradle with “clean build,” which is what we want. Click on Use Selected.

And we have a project that is ready to be run.

TeamCity Created Project

Add Project to Overview Page

Before we run the first build, let’s add the project to the overview page so it’s easier to get to it. Click on the TeamCity logo on the upper left-hand corner of the page.

This brings up an almost empty page. Click on the configure visible projects link.


TeamCity Add Project OverviewUse the accumulator to add TeamCity Project to the list of visible projects and then save the results. This will make the project easier to access as we work.

Click on TeamCity Project. This takes us to the project view page.

Above the project information, we see that this server has one build agent and zero builds in the build queue. Agents execute the builds, and if there aren’t enough agents to run all of the pending builds, TeamCity queues them on a first-in-first-out basis.

Let’s take a quick look at our project code too.

We have a single Java class below:

public class TeamCity {
    public boolean getStatus() {
        return true;

And a single test:

import org.junit.Test;
import static org.junit.Assert.*;

public class TeamCityTest {

    private TeamCity teamCity = new TeamCity();
    public void getStatus() {

Run an Initial Build

Let’s start a build. Click the Run button on the upper right-hand side of the project page.
TeamCity Build Results
After a few seconds, the build completes, and we see that it has passed.  One test was successfully run.

From the build results page, we can view our test.
TeamCity Test Results
TeamCity lists the test class name and the test method(s), along with the results.

We can also click the Build Log tag for a record of the build.
TeamCity Build logs The log viewer collapses some log entries. Clicking on the + icon expands them.

Build Configuration

TeamCity build behavior is configurable. Click on Edit Configuration Settings. 

On the build configuration screen, click on Show advanced options.
TeamCity Build Config
Change the Build number format.

Build Number Format TeamCity
TeamCity defines variables that can be used to create build numbers. The default is a counter that increments with each build. Prefix the build number with Tutorial.

Let’s take a look at the Artifact paths too.


Artifact paths TeamCitySimilar to build numbers, TeamCity offers a mechanism for creating build output locations using variables. These variables can be used to move the build results to different paths and different file names.

Finally, click on Triggers in the left-hand side menu.

TeamCity build triggers
TeamCity is watching all branches of the Git project for changes. If we click the Add Trigger button, we see a selector to add different trigger types.

TeamCity trigger select


For now, watching the Git repository is all we need.

Pre-Stage a Commit

One of TeamCity’s more powerful features is the ability to pre-stage a commit. We can modify our code and test it in a build on the server without committing it to the remote repository. Let’s give it a try.

Open the Java project in IntelliJ.

First, add the TeamCity plugin in IntelliJ if it is not already installed.


IntelliJ TeamCity PlugingNext, go to the TeamCity menu and authenticate to the TeamCity server.


TeamCity plugin loginNow we can modify the code. Open the TeamCity class and change getStatus() return value to false.

public class TeamCity {
    public boolean getStatus() {
        return false;

Commit the change but do not push it.

Next, select Remote Run Outgoing Changes… in the TeamCity menu.

Remote run

Select the project name and click OK to run the build. After a few moments, IntelliJ will notify you that the build has failed.

The TeamCity tool window displays the test that failed

Remote Run test failed

And the test output alongside it.

Remote test output TeamCity

We see what we expect. Our one-and-only test has failed.

Go to the TeamCity server, and view the list of builds for TeamCity Project.

TeamCity Personal Build


The pre-staged commit, in the form of a Personal Build, is at the top of the build list. The build has put out new build number scheme; it’s called Tutorial #2.

Personal builds are only visible to the users that create them. They can be triggered as pre-staged commits, or from the TeamCity server by viewing the drop-down control under the Run button.

Breaking and Fixing a Build

Let’s ignore TeamCity and push the broken change to Git.

After a few minutes, TeamCity will pick up the change in git, and run a build.

Build running


The build fails.

TeamCity Build Failed

Click on the build to see details.

Failed Build Detail


We see the test that failed.

Click the Changes tab under the build name.

TeamCity Changes


This displays the commit that triggered the build.

Go back to the build detail. Click Assign Investigation in the red banner near the top.


We can assign responsibility for fixing the build to a user. Assign the investigation to yourself. User profiles have a list of open Investigations. TeamCity will close this investigation automatically when a build runs successfully.

Go back to the code and change the return value of getStatus back to true. Check-in and push the change.

A new build will be triggered soon.

TeamCity new build


And it passes.

TeamCity Build List


The Investigation is closed. We can view the log for this successful build and also view the changes that fixed it.


In this tutorial, we imported a Java project to TeamCity. We built the project, examined build and test logs, and then used TeamCity pre-staged commits to check a code change before committing it. We also broke the build and reviewed how to manage build issues with TeamCity.

TeamCity is a powerful CI system that will improve how you and your team manage builds and deployments. Get started with it today!


Photo credit: Randy Fath.