Sign up for the TeamCity Cloud beta

1600x800

We are happy to announce that we’re building TeamCity Cloud – a CI/CD service that will be completely hosted and supervised by JetBrains. If you’re interested in participating in the beta, please fill out the form on the Sign up for TeamCity Cloud beta page. We will add your email to the beta list, and get in touch with you early next year.

Posted in News & Events | Tagged | Leave a comment

TeamCity 2019.2 is here with new clean-up rules, EC2 launch templates, a build chain DSL, and more

TeamCity 2019.2 gives you great new ways to manage the clean-up of your builds and to monitor your server’s performance. It supports EC2 launch templates, and features a new DSL syntax for defining build chains. It also provides an easy way to run personal builds with Git patches, and adds many improvements to the experimental UI.

blog_teamcity-2019.2

Power up your clean-up

TeamCity 2019.2 opens new dimensions of control over the historical data and artifacts created by your builds. A reworked clean-up engine allows you to set up different clean-up policies with a wide spectrum of filters: for example, you may choose to keep all builds from specific branches, or with specific tags.

We believe that new clean-up rules will be particularly useful for companies that have a lot of projects, and for teams that use feature branches during development.

blog_clean-up@2x

Bird’s eye of your CI

Pros love tools that help them monitor how mission-critical systems are behaving and performing. Starting with 2019.2, TeamCity exposes its metrics via an HTTP endpoint, so they can be scraped by Prometheus and then visualized via the Prometheus web interface, or in a Grafana dashboard.

The metrics include the server performance information, as well as various details on agents, projects, and build configurations.

metrics@2x

Scalability, taken further

For many large organizations, a high-performance CI is critical to their workflows. TeamCity takes another step toward a multi-node setup allowing you to add builds to the build queue, manage build problems and investigations, and perform other user-level actions – now on a secondary server.

More ways to be productive with experimental UI

Developers often open TeamCity many times a day, which is why we want it to be a place where they can quickly find what they need, regardless of the size and complexity of their projects. Following the TeamCity UI roadmap, we are introducing a new build page that gives you an easy way to browse build history, investigate problems, and discover any misconfigurations or bottlenecks in your build chains.

Check out the experimental UI – we’re proud of how it now looks and feels.

build-page@2x

EC2 launch templates. Builds taken to new heights

We want TeamCity to have everything you need in a modern workflow. Version 2019.2 adds support for EC2 launch templates, and lets you run cloud build agents using the launch parameters from your AWS account. With the launch templates, updating and installing new software on build agents becomes a very simple and straightforward task – you no longer need to change anything in the TeamCity project configuration.

ec2-launch-templates@2x

Level up your DSL

Build chains, built easily

Goodbye clicking, hello scripting. The Kotlin DSL now provides a simple and very straightforward syntax for defining build chains. Set up sequential and parallel builds, configure failure conditions and dependencies – and store everything as code.

Many parameters. One template.

Project configuration just got easier. Starting with 2019.2, your Kotlin DSL configurations may include custom parameters, which you can define later when importing the project in the UI.

Run more. Wait less. Start builds with Git patches.

Quickly test your changes by creating a Git patch, uploading it to TeamCity, and running a personal build – without creating any branches or committing anything.

create-patch@2x

For the full list of changes in version 2019.2, see the TeamCity documentation.

Download TeamCity 2019.2

Please check through the upgrade notes before you install the new version, and do not hesitate to report any issues in our tracker or ask questions in the forum.

Posted in Features, Release | Tagged , | Leave a comment

TeamCity 2019.2 RC is out

TeamCity 2019.2 release candidate is already here.

This build fixes over 180 issues and gives a first look at several notable release features:

  • New flexible clean-up rules that allow you to fine-tune what types of data to preserve during the clean-up.
  • Portable Kotlin DSL now can be parametrized.
  • Secondary nodes now allow performing the most common user actions on builds, such as adding builds to the queue or assigning investigations.
  • The experimental TeamCity UI is available for Tests and Changes tabs of Build Details. We are also presenting a redesigned version of the Agents page:
    Experimental Agents pageNote that the experimental UI is a work in progress and an optional alternative to the classic UI. Based on your feedback, we will make sure to optimize it and migrate all the important classic features in the future releases.

Read more about all features and fixes in our release notes and download Kanpur 2019.2 RC build.

Remember that TeamCity RC builds come without the EAP license, but the license for the previous EAP release is valid for this RC version as well. It is important that you install it on a trial server as the new version will modify the data format, but downgrading is not supported.

Your feedback is always welcome in our forum or issue tracker.

The new version of TeamCity is on its way – follow our updates, and

Happy building!

Posted in EAP, Features, Release | Leave a comment

Going to AWS re:Invent? Let’s meet!

Are you attending AWS re:Invent in Las Vegas on December 2–6? So are we! And we would love to meet you!

reInvent19_Partner_Banner_728x90

Schedule a one-on-one meeting with our team to talk about how TeamCity can help streamline your CI/CD pipelines. Did you know it can save you 30% of your build time and resources? We can also arrange a personal demo tailored to your requirements and discuss any questions you may have about your current setup.

Book your time with our experts right now – pick a time slot while they still last.

While at AWS re:Invent, do stop by the JetBrains booth at the Venetian Expo Center to pick up some swag, see live demos, and talk about how our IDEs can help you develop for the cloud and in the cloud. We look forward to meeting you!

Schedule a TeamCity meeting

Posted in News & Events | Tagged | Leave a comment

TeamCity 2019.1.5 is available

The new bugfix release for TeamCity 2019.1 is ready to download.

We recommend you upgrade to 2019.1.5 to get fixes for several security problems and other important issues, including:

  • the problem with the incomplete publication of NuGet packages to the NuGet feed
  • unavailability of the “Default credential provider chain” option in the Amazon ECR connection settings

The full list of resolved problems is available in our release notes.

Like any bugfix update, 2019.1.5 has the same data format as all 2019.1.x versions, which allows you to easily upgrade/downgrade within these builds.

Remember to check our Upgrade Notes and use one of these options to upgrade:

Your feedback is welcome in our forum or tracker.

Happy building!

Posted in Bugfix, Release | Leave a comment

TeamCity 2019.2 EAP3 is here

Today we are presenting the final Early Access Program build of TeamCity 2019.2.

Take a first look of the following features:

  • Redesigned Build Details page
    buildpage
    Switch to the experimental UI and try our new approach to displaying build information: a build timeline, structured build log, chart of dependencies, and more.
  • Personal builds based on unified diffs
    To run a personal build without committing changes, upload a patch with changes in a unified diff format directly to the server, via the TeamCity UI or REST API.
  • Pipeline DSL
    Try an alternative approach to describing build chains via Kotlin DSL.
  • Branch filter for artifact dependency
    Set a branch filter so the build uses artifacts from the latest build with the specified tag only from a matching branch (or all branches).

The full list of over 80 new features and bug fixes is available in our release notes.

Remember that the new release changes the TeamCity data format and downgrading to the previous production version is not supported. We recommend installing this EAP version on a trial server. If you installed the previous TeamCity EAP version, you can easily upgrade with our automatic update. In other cases, you can download the EAP build or pull the Docker image with the eap tag.

As with any EAP version, this one comes with a 60-day Enterprise evaluation license for an unlimited number of agents and build configurations.

We encourage you to try the new features and share your feedback with us, in our forum or issue tracker.

Happy building!

Posted in EAP, Features | 2 Comments

TeamCity 2019.1.4 is released

Today we are presenting 2019.1.4 update, which resolves over 40 issues in the recent version of TeamCity.

Among other improvements, it brings performance optimizations in the Pull Requests plugin and few important fixes in the .NET Core support. The full list of fixed issues is available in our release notes.

We highly recommend you install this update since it addresses several security problems.

Like any bugfix update, 2019.1.4 has the same data format as all 2019.1.x versions, allowing you to easily upgrade/downgrade within these builds.

Remember to check our Upgrade Notes and use one of these options to upgrade:

Your feedback is welcome in our forum or tracker.

Happy building!

Posted in Bugfix, Release | Leave a comment

Stop Bad Code from Being Promoted in TeamCity Build Chains, with OverOps

This guest blog post is brought to you by Alex Zhitnitsky, Director of Product Marketing at OverOps.

It’s no secret that 100% test code coverage ≠ 100% of critical issues identified. Developers, build engineers, and managers are throwing everything they have at this problem – rigorous code reviews, static analysis, and every possible type of automated test they can think of, but the facts of the matter stay the same – code still breaks.

The reason for this is that testing requires foresight. You can’t predict the future with absolute certainty, and the level of foresight that’s required to prevent code from breaking in production is close to impossible. It’s a fact of life that we’ve grown to accept, and even the best engineering teams out there can’t avoid it.

Every engineer worries that the new code they deployed is going to cause issues in production, but there’s only so much they can test.

So what can be done to address this gap?

Today, most teams approach code quality only through the lens of pass/fail test results and static analysis. The complexity of what’s happening underneath the surface – the exceptions, HTTP errors, logged errors, and warnings – is not addressed, letting preventable issues slip into production.

The ability to optimize all of this operational data and serve it to developers in a form they can easily consume is what sets OverOps apart and exactly where our integration with TeamCity fits in.

Introducing runtime code quality gates for TeamCity

At OverOps, we’ve created a new way to ensure code changes don’t impact customer experience in Java and .NET based applications. By learning and mapping code at runtime, we optimize live application data and make it accessible to the entire team. This enables our users to identify code-level anomalies, prevent them from being promoted, and resolve them with the required context. Fully automated, and with no reliance on logs.

Using OverOps with TeamCity Build Chains introduces a brand new way to avoid deploying bad code to production, which takes into account caught and uncaught exceptions (including those not logged), and events like logged errors, warnings, and HTTP errors.

Normally, analyzing all these events would be extremely difficult. There’s just so much noise out there that it’s close to impossible to find the issues that matter.

This is where our machine learning algorithms kick in.

OverOps is not only aware of these events, but also deduplicates them and classifies anomalies in real-time, selectively capturing the required context to understand what happened.

The way this data meets you is through 6 new levels of runtime code quality gates:

  1. New Errors – did the release introduce any errors that hadn’t happened before?
  2. Critical Exceptions – did the release introduce any severe/showstopping errors?
  3. Increasing Error Rates – did the rate of a known error increase dramatically in this release?
  4. Resurfaced Issues – did an error that was previously resolved appear again in the current release?
  5. Total Errors Volume – did this release introduce a dangerous spike in the total volume of errors?
  6. Unique Errors Volume – did the release introduce an unusually high number of many unique (i.e. discrete) errors?

How to integrate OverOps with TeamCity

To get started with our first runtime code quality analysis, follow these 3 steps:

  1. First, let’s install the plugin. If you’re new to OverOps, check us out on overops.com by signing up and connecting your application. Once your environment is set up, you’ll be ready to get started by installing the Runtime Quality Report plugin with one click from the TeamCity UI.
  2. Now that your plugin is installed, it’s time to connect it with OverOps. Add the OverOps Runner build step from the Runner type drop down in your build configurations:
    1
  3. Fill in your OverOps environment ID and API token (accessible via OverOps), and test the connection:
  4. 2

All right! Now we’re ready to get started. You can now also name your application and deployment in the same configuration screen, and review some of the more fine-grained options. These will come in handy when you’ll want to customize how each runtime quality gate is defined and what conditions will make it block your build.

The complete documentation is available on our GitHub page.

Now that we’re set up, let’s walk through an example

Your team just ran its automated test suite on a new build, and looks like everything passed. Normally, the build would be considered stable and moved to the next step in your pipeline. However, OverOps will mark a build as unstable if it identifies code-level issues that triggered the runtime code quality gates you’ve set up:

3

We can see that in this case, build v4.41.0 was marked as unstable because OverOps identified 24 new errors that didn’t exist in the previous version, and 1 resurfaced error that was previously resolved. Now, the team will be alerted to review the new errors that were identified.

We can see each error’s rate, which represents the number of times it happened out of the overall number of times the method it’s in has been called. This is a great way to have an even more fine-grained ability to focus on the most critical issues.

But that’s not all.

To quickly triage what’s going on, clicking into each error leads you to the data you need to resolve it. This includes the complete source code and variable state for the issue at hand, the state of the environment, and more, taking into account the 7 key components of true root cause analysis.

4

For each error, you get the following types of data in this error analysis screen:

  • Type and location in the code, server, application, and deployment.
  • Times and error rate, including a time-series chart of occurrences since it was first seen.
  • Full stack trace and source code with complete variable state.
  • The last 250 logging statements, including DEBUG and INFO, regardless of logging verbosity.
  • The state of the environment, including threads, memory, and CPU stats.

In this case, we can see that a NullPointerException occurred because customer is null. Using this analysis, we can trace back the steps of how we got there and understand what needs to be done to stop it from happening again.

Does this look interesting? Then check out this 3-minute overview of OverOps to learn more, or request a demo with one of our engineers.

Posted in Guest post | Tagged | Leave a comment

Build Chains: TeamCity’s Blend of Pipelines. Part 2 – Running Builds in Parallel

In the previous blog post, we learned about snapshot dependencies and how they can be applied to create build chains in TeamCity. In this blog post, we describe how snapshot dependencies enable parallel builds.

More snapshot dependencies

Previously, we started creating the build chain for the demo application. We created two build configurations: one builds the application and the other builds the Docker image. What about tests?

Suppose there are a lot of tests and running those tests sequentially takes a lot of time. It would be nice to execute the groups of tests in parallel. We can create two build configurations, Test1 and Test2, which will execute the different groups of the tests. Both Test1 and Test2 have a snapshot dependency on TodoImage build configuration.

12-tc-pipelines-todo-tests

Since Test1 and Test2 do not depend on each other, TeamCity can execute these build configurations in parallel if there are build agents available.

Now the new aspect of snapshot dependencies is revealed. Using the snapshot dependencies, we created a build chain which is actually a DAG – Directed Acyclic Graph. The independent branches of the graph can be processed in parallel given that there are enough processing resources, i.e. build agents.

This leads us to the next question: how can we trigger such a build chain? Previously, we added the trigger to TodoImage as it was the last build configuration in the chain. Now there are two build configurations. Should we add two triggers – one to Test1 and the other to Test2? While it is certainly an option, there is a more idiomatic way to do that – with the Composite type of build configuration.

Composite build configuration

The purpose of the composite build configuration is to aggregate results from several other builds combined by snapshot dependencies, and present them in a single place. One very interesting property of this kind of build configuration is that it does not occupy a build agent during the execution.

In our example, we can create a composite build configuration that depends on Test1 and Test2 via a snapshot dependency. The new configuration will be the last one in the build chain. Now it’s possible to add a VCS trigger to that build configuration. As a result, there will be just one VCS trigger for the whole build chain.

14-tc-pipelines-concurrent-tests-annotated

Notice on the screenshot above that the two build configurations, Test1 and Test2, are running in parallel. The TestReport build configuration is also running, but it doesn’t occupy the build agent and will be marked as finished as soon as all the builds complete.

The nice feature of the composite build configuration is that it also aggregates the test results from the dependencies. In our example, if we navigate to the Tests tab of the TestReport build configuration, we will observe the list of tests that were executed in all the previous build configurations that belong to the same build chain.

14-tc-pipelines-concurrent-tests-composite

Summary

At first sight, snapshot dependency looks like a simple concept. However, it enables a lot of features in TeamCity. In the previous blog post, we saw how we can re-use the results of the builds to save build time and resources. In this blog post, we have learned that snapshot dependencies also enable better use of resources when builds are executed in parallel. Next, we will learn how to orchestrate the deployment process with the TeamCity build chains.

If you are interested in trying out the demo project on your local TeamCity instance, we have uploaded the configuration to a GitHub repository. The .teamcity/ directory contains Kotlin DSL settings for the build chain that we have described in this blog post. To import these settings, create a project from repository URL. TeamCity will detect .teamcity/ directory in the repository and will suggest creating the project using these settings.

Posted in Features, How-To's | Tagged , , | Leave a comment

Build Chains: TeamCity’s Blend of Pipelines. Part 1 – Getting Started

In TeamCity, when we need to build something, we create a build configuration. A build configuration consists of the build steps and is executed in one run on the build agent. You can define as many build steps as you like in one build configuration. However, if the number of steps grows too large, it makes sense to examine what the build configuration is doing – maybe it does too many things!

We can split the steps into multiple build configurations and use TeamCity snapshot dependencies to link the configurations into a build chain. The way TeamCity works with build chains enables quite a few interesting features, including parallel execution of the builds, re-using the build results, and synchronization for multiple source control repositories. But most of all, it makes the overall maintenance significantly easier.

In this blog post, we will explain how to create a build chain in TeamCity by configuring the snapshot dependencies for the build configurations.

The minimal build chain

To create a simple build chain, it is enough to create two build configurations and configure a snapshot dependency from one configuration to another.

For this example, we are using a GitHub repository. The repository includes a Gradle project that builds a Spring Boot application. In addition, there is a Dockerfile for building a Docker image.

We are going to build this project in two steps. First, we will build the application, and then build the Docker image with the binary produced in the first step.

01-tc-pipelines-todo-backend

First the build configuration, TodoApp, builds the Spring Boot application and publishes an artifact as a result. The second build configuration, TodoImage, depends on the TodoApp build configuration and builds a Docker image.

02-tc-pipelines-todoapp-config

There are two kinds of dependencies that we will need to configure: the snapshot dependency and the artifact dependency.

03-tc-pipelines-todoimg-dependencies

Artifact dependency

The TodoApp build configuration publishes an artifact to the todo.jar file. Any other build configuration can download the file by configuring the corresponding artifact dependency.

On the Dependencies tab, click the “Add new artifact dependency” button. In the dialog, locate the build configuration from which the files should be downloaded and specify the patterns to match the file path(s).

05-tc-pipelines-todo-backend-artifact-dep

The documentation page describes how to configure the artifact rules in more detail.

Snapshot dependency

To configure a snapshot dependency, go to the Dependencies tab in the build configuration settings and click the “Add new snapshot dependency” button. In the dialog, locate the build configuration it will depend on and click Save.

04-tc-pipelines-todoimg-snapshot-dep

There are a number of settings associated with the snapshot dependency. You can read about the various settings in the documentation. For our current example, the default configuration is sufficient.

When the TodoImage build configuration is triggered, TeamCity makes sure all the dependencies for this build configuration are up to date. Consequently, all the dependent build configurations that form a build chain via the snapshot dependencies will be added to a build queue. The result is visible on the Build Chains tab of the project:

06-tc-pipelines-todo-backend-build-chain

Triggering the build chain

There are various kinds of triggers that are possible to set up for a build configuration in TeamCity. The VCS trigger is the one that reacts to the changes in a version control system.

11-tc-pipelines-todo-backend-vcs-trigger

In our example, there are two build configurations but we will only need one VCS trigger. This is because it’s possible to tell the trigger to monitor for the changes in the dependencies. In the configuration dialog, we have to enable “Trigger a build on changes in snapshot dependencies” checkbox.

We can configure a dedicated VCS trigger for each and every build configuration in the chain. However, each trigger creates some overhead: the server has to allocate some cycles to maintain the trigger. Additionally, it’s easier to make changes to the settings if you only have one trigger to configure. Hence, we can just add a single VCS trigger to the very last configuration in the build chain and it will do the job.

Re-using the results

The build chain completed successfully. We can start the build again. However, this time TeamCity will be smarter and skip running the builds for the dependencies where it detects no source changes.

For instance, on the first run, the build number for both our build configurations is 1. Now let’s try running the TodoImage build configuration a couple of times. Since there are no changes to TodoApp’s sources its build is not started and TeamCity re-uses the result of the 1st build. The TodoImage build number is now 3 since it was our intent to execute it.

07-tc-pipelines-todo-backend-build-chain-2

It is also possible to enforce building the dependencies even if there are no source changes. For this, click on the ellipsis next to the Run button of the build configuration. From the dialog, choose the Dependencies tab, and select the dependencies that are required to run.

08-tc-pipelines-todo-backend-enforce-dependcies

Configuring checkout rules

The current setup of our build chain doesn’t really provide us with much value yet. All the sources are located in the same GitHub repository, hence if we configure the trigger to fire on code changes both build configurations will run.

For instance, if we make a change to the Dockerfile we don’t need to run the build for the application. However, with the current setup, TeamCity detects that there’s a change in source control repository for TodoApp as well and both build configurations will execute incrementing the build numbers.

09-tc-pipelines-todo-backend-dockerfile-change

Instead, it would be nice to run the build only when necessary.

In this example, we would like to build TodoApp if there is a change to anything but the Dockerfile. And we only want to build a new image if just the Dockerfile changes – there’s no need to build the application in this case.

It is possible to configure the checkout rules for the VCS root accordingly. The checkout rules affect the actual checkout of the sources on the agent. That said, if we exclude any folders of the repository using the filters in checkout rules, those folders won’t end up in the workspace.

We will exclude the docker/ folder from the checkout in the TodoApp build configuration. And we will only pull the docker/ folder in the TodoImage build configuration, and ignore everything else.

10-tc-pipelines-todo-backend-chckout-rules-docker

Now, if we only change the Dockerfile, only TodoImage should execute and re-use the results from the previous TodoApp run without executing it.

Summary

The concept of snapshot dependencies is essential for configuring the build pipelines, aka build chains in TeamCity. The feature allows implementing incremental builds by re-using the results of the previous executions, thus saving a lot of time. In this article, we have also learned about triggering and VCS root checkout rules – both very useful for working with build chains.

Next, we will look at what else is possible with the features we have described – running the builds in parallel and orchestrating the deployment process.

Posted in Features, How-To's | Tagged , | Leave a comment