TeamCity 2022.10 comes with the Sakura UI enabled by default, introduces many cloud-related features including the AWS credentials management system and out-of-the-box terminal access to AWS EC2-based build agents, and adds important improvements to VCS integrations. Server administrators will love the new streamlined way to implement HTTPS for on-premises TeamCity installations. Also, a new authentication module for using Google accounts and a number of long-requested features have been implemented.
Sakura /sa.ku.ʁa/, or cherry blossom, symbolizes the time of renewal and optimism – and we believe this perfectly describes our feelings as we make the Sakura UI default in TeamCity 2022.10.
The Sakura UI is modern, beautiful and fast. Built with accessibility in mind, it has feature parity with the classic UI, and also brings many new unique capabilities. We’ve been working on the Sakura UI for over four years, and we made sure to make it perfect down to the smallest detail. We had the unique opportunity to test it against thousands of internal and external projects including such giants as IntelliJ IDEA and Kotlin. We believe that you will love it too!
We understand that some of our users may be attached to the old user interface, and for a limited time we will keep it available for them. However, in one of the next versions, we will be deprecating it in favor of the Sakura UI, so if you think that we have missed something, please create an issue in YouTrack.
More and more of our customers are moving their TeamCity installations to the cloud, so we continue to push our cloud capabilities forward.
We have implemented a new AWS credentials management system that issues temporary, short-lived AWS keys and exposes them in a safe way for your builds.
We believe that every development team should have full visibility and control over their delivery pipelines. To improve the debugging experience of cloud CI/CD, we have added the ability to open a secure terminal session to AWS EC2-based build agents directly from the TeamCity UI – without the need to access the cloud provider’s management console or ask a busy DevOps team to set up network access lists and SSH key-pairs.
The availability of the feature is controlled by the “Open an interactive session to the agent” permission that is only enabled for server administrators by default but can be assigned to other users when needed.
If you've ever needed to debug a problem in a CI/CD pipeline that was executed on a cloud instance, you know that it can be tricky. Not only does it require time and effort to identify and spin up the right build agent, but you also need to make sure that it doesn’t launch new builds in the middle of the process.
This is where maintenance mode comes in. In this mode, TeamCity does not automatically terminate cloud agents after the build is finished, and they don’t get allocated for running new builds, allowing you to do the troubleshooting.
Starting with TeamCity 2022.10, secondary nodes of TeamCity can start and stop cloud instances, providing uninterrupted operation of cloud-based CI during maintenance of a primary server.
TeamCity 2022.10 comes with two improvements related to the integration with Perforce tools:
TeamCity 2022.10 now uses short-lived OAuth tokens when working with GitLab, Bitbucket Cloud, and Azure DevOps, allowing you to create VCS roots without having to manually generate access tokens for these services.
Today, CI/CD pipeline security is more important than ever. In version 2022.10, we made it easy to enable HTTPS for your TeamCity server. All you need to do is to upload an HTTPS certificate, or a certificate chain, in PEM format, and TeamCity will do the rest.
You can now create temporary access tokens that will allow other people to log into TeamCity under your account, but with a limited scope of permissions, for example, with view-only access for one specific project. This can be useful in cases where you want someone to help you debug your pipeline, or when making a demo.
To support more workflows and make the experience with TeamCity smoother, we now support authentication using Google accounts. When logging in with Google, TeamCity will instantly match the Google email with an existing TeamCity user, and log them in without having to enter a password. It can also automatically create new profiles when new members join your team, provided that their email addresses belong to one of the domain names you specified.
The Free Disk Space build feature now keeps track of the size of artifacts and automatically calculates the disk space required for resolving artifact dependencies. This makes the use of the build feature more straightforward, as you no longer have to know the size of the artifacts downloaded during the build, and the only thing you need to specify is the amount of disk space required for the build process itself.
Starting with TeamCity 2022.10, you can promote personal builds. Builds that are triggered after the promotion also become personal builds.
These are just the most important highlights of TeamCity 2022.10. For the full list of changes, please see the TeamCity documentation.
TeamCity 2022.04 introduces the new Parallel Testing feature that delivers an extraordinary speed boost when testing your projects. New powerful code analysis features will cut the time you spend on code reviews and increase the maintainability of your projects. Users who run their builds in the cloud will love the improved integration with Amazon S3 and Amazon CloudFront, as well as the new option of managing Cloud Profiles programmatically. There are a number of improvements to VCS integrations, new configuration options, and many great updates to the user interface.
TeamCity is now capable of parallelizing the execution of your tests by intelligently distributing them across multiple build agents, thus minimizing their overall duration. Unlike any other CI/CD solution, this feature takes into account not only the latest run, but also the history of your tests. With that, you can freely refactor your code, break your tests, and do whatever you think is best for your project – without the fear of compromising the parallelization and bogging down your pipelines.
Parallel Tests have made a phenomenal change to the way we develop and test TeamCity. Our own integration tests have become over 10x faster, dropping from 4 hours to about 20 minutes.
Parallelization of test execution can be implemented in a multitude of ways. The easiest way is by using a Maven, Gradle, or .NET build runner, as these build runners support this feature straight out of the box. For other build runners and custom build scripts, TeamCity will save the optimal way to parallelize tests in special instruction files, allowing you to set up parallel testing yourself.
TeamCity helps you eliminate bugs and improve the quality of your software in so many ways – and now there’s one more! Starting with version 2022.04, you can enable advanced code quality inspections and perform a variety of other new actions – all powered by JetBrains Qodana:
Adding code inspections to your build pipelines allows you to cut the time you spend on code reviews, ensures maintainability of your projects, and helps every developer on your team to work more efficiently. We welcome you to check out a live demo.
The world is quickly migrating to the cloud, and we’re seeing an increasing number of our customers following suit. TeamCity 2022.04 takes the cloud experience a step further by enhancing integration with Amazon Web Services and adding new configuration options.
TeamCity has always had powerful integration with Amazon EC2 and Amazon S3 that allowed you to freely scale your build infrastructure, regardless of the size and complexity of your projects. Version 2022.04 allows you to not only store new build artifacts in Amazon S3, but also move existing artifacts from TeamCity’s local storage to Amazon S3. This is particularly useful for teams who are just starting their migration from a self-hosted setup to a cloud platform and want to take full advantage from the outset.
Working with build artifacts stored in Amazon S3 can be slow and expensive depending on the geographical distance between you and the region where the S3 bucket is located. To help you reduce costs, TeamCity 2022.04 adds native support for Amazon CloudFront, which allows you to work with artifacts cached on the nearest edge locations provided by AWS. This works on all levels including build agents, web users, API requests, and others – potentially giving your development process a tremendous speed boost.
Storing CI/CD configuration with your project’s codebase is the best way to ensure that it can always be built, tested and deployed. To provide more flexibility when building software in the cloud, TeamCity 2022.04 extends the Kotlin DSL, giving every project the opportunity to have its own Cloud Profile configuration.
As previously announced in our roadmap, we are starting to explore the area of deployment, and as the first step in this direction we’re releasing build approvals. Now you can create build configurations that will not start immediately after being triggered, but will stay queued until everyone from the approval team gives their green light. This feature will be particularly useful for advanced teams that don’t want to limit developers’ ability to access the production environment, but at the same time need a higher level of control over the deployment procedure.
Your voice is welcome! If you have any feature requests related to deployment, please don’t hesitate to suggest them in our YouTrack project.
We’re continuing to improve the integration with JetBrains Space, adding in support for merge requests. When building an MR, TeamCity will now publish the status to the respective merge request timeline in Space.
We have enriched the list of supported issue trackers by adding GitLab. This works just as you’d expect: when a commit message mentions an issue ID, TeamCity automatically adds a link to the respective issue in GitLab and displays information about it.
Previously, the Commit Status Publisher build feature would not send information to the version control system until TeamCity actually started the build, which was prone to occur long after the commit had been made. Starting with the new version, TeamCity updates the commit status immediately after adding the respective build to the queue, providing you with the most up-to-date information. This feature works with all supported VCS services including GitHub, GitLab, Space, Bitbucket and Azure DevOps.
When running a custom build, you can now specify an exact revision that may not necessarily belong to the list of changes known by the build configuration. This gives you a lot more flexibility in cases where you want to reproduce historical builds, deploy older versions, debug new build configurations, and many other situations.
TeamCity has always allowed you to limit the number of builds running simultaneously for a build configuration. With version 2022.04, you can improve resource allocation and set this limit on the branch level. For example, your main branch may have an unlimited number of builds that can occupy as many build agents as they need while you limit your feature branches to running just one build at a time.
Although TeamCity has not been affected by the Log4Shell vulnerability (CVE-2021-44228), some security scanners wrongly reported it as vulnerable without checking the exact version number of the Log4J framework used in the product. To avoid false-positive scanner reports, we have upgraded Log4J to the latest version.
Similarly to Log4Shell, the Spring4Shell vulnerability (CVE-2022-22965) does not affect TeamCity. However, to avoid false-positive reports from security scanners, we have upgraded the Spring Framework used in TeamCity to the latest version.
Our new Sakura UI is getting closer and closer to feature parity with the classic TeamCity UI. In version 2022.04, we have reimplemented the Agent Pools and Changes pages and vastly improved the overall performance of the new UI. Now we are just a few steps away from making it a default option – something we plan to do in TeamCity 2022.10. Stay tuned!
These are just some of the ways we've improved TeamCity. For upgrade instructions and the full list of changes in version 2022.04, please see the TeamCity documentation.
TeamCity 2021.2 introduces two-factor authentication, brings a variety of updates to the integration with Perforce Helix Core and Perforce Helix Swarm, and further integrates with JetBrains Space. Users of Azure DevOps can now log in to TeamCity using their Azure AD accounts, and C# developers will love the ability to set up build steps using the new C# script build runner. There are also a number of improvements to the Kotlin DSL syntax and multiple updates to the Sakura UI.
CI/CD is a core element of every modern development process, and keeping it well secured is critical. To further strengthen the security of their CI/CD servers, TeamCity administrators can now enable two-factor authentication and require users to enter an additional authentication code to log in.
Of all the different version control systems, Perforce Helix has a special place in our hearts, as the TeamCity+Perforce combo is the de facto CI/CD standard in many industries. TeamCity 2021.2 reinforces the integration with a range of great new features.
The Run custom build feature now allows you to run personal builds with changes from a shelved changelist in Perforce. You can trigger a whole build chain on such a changelist and see the list of shelved files inside the TeamCity UI.
We have added the new Perforce Shelve Trigger, which detects new and modified shelved changelists whose descriptions contain a given keyword and triggers personal builds on them.
We have extended the Commit Status Publisher build feature by adding the new Perforce Swarm publisher. When the publisher is configured, TeamCity will send the information about builds to the Perforce Helix Swarm server, and the respective comments will be added to Swarm reviews on shelved changelists.
The VCS labeling build feature now creates automatic labels in the Helix server. These labels work as aliases for changelist numbers. Compared to the static labels that were used in previous versions of TeamCity, these give you a significant boost in performance.
Perforce connection parameters are now passed to TeamCity as build parameters, allowing you to distinguish between different Perforce VCS roots when a project uses multiple Perforce connections.
If your team uses JetBrains Space – a new all-in-one solution for software teams and projects that was recently released by our company – then you will surely enjoy the new integrations that we’ve added in this version of TeamCity.
Version 2021.2 adds the new JetBrains Space authentication module, which allows you to log in using your Space account, just like you can log in with GitHub or GitLab.
Previously, a configured connection with Space only allowed you to access its repositories and publish the status of your builds. The new version of TeamCity also allows you to add VCS roots, create projects, and create build configurations – all you need to do is add the necessary access rights on the Space side.
We have received a lot of requests from users who use TeamCity and Azure DevOps at the same time to build their software. To make their experience smoother, TeamCity 2021.2 adds the new Azure DevOps OAuth 2.0 authentication module, which allows you to log in to TeamCity with an Azure AD account.
If you are like most C# developers, then you probably find it really annoying to use PowerShell every time you need to set up a build environment, manage Windows processes, or simply move some files. We feel your pain! That’s why we’ve created the new C# Script build runner, which gives you an easy way to write build steps in a real programming language. You no longer have to spend time googling how to write things in PowerShell – you can just use simple C# scripts.
The new build runner is cross-platform, works on any system with Docker, and comes with built-in support for NuGet.
We are continuing to improve the Kotlin DSL, making it even easier to manage CI/CD configurations as code. Starting with TeamCity 2021.2, you can configure elements of your pipelines that were previously not covered by the Kotlin DSL, such as issue trackers, custom charts, or shared resources. For a full list of the Kotlin DSL changes, please refer to this request in YouTrack.
With the Sakura UI, our goal is to make sure that every developer can quickly find what they need, regardless of the size or complexity of their projects. Version 2021.2 adds two views from the classic UI that were absent in the Sakura UI: Pending Changes and Change Details.
Additionally, usernames now display avatars next to them, so you can identify the authors of commits more easily. This was added to both the Sakura UI and the classic UI.
For the full list of changes in version 2021.2, please take a look at the TeamCity documentation.
TeamCity 2021.1 brings brand-new build runners for Kotlin and Node.js, improves integration with Perforce, and enables a whole range of new workflows by allowing build triggers which define parameters to be used inside build scripts. Users with demanding availability requirements will love the new option to transfer main server responsibilities to secondary nodes in the runtime with minimum downtime. There are also multiple updates to the Sakura UI that will make your work with TeamCity easier, faster, and more enjoyable.
Over the past several years, Kotlin has grown immensely. We have seen a lot of interest in using it not only to configure pipelines as code, but also to write build scripts.
The new Kotlin script build runner is a great choice in a huge variety of scenarios. It is cross-platform, supports importing external libraries, and can be used in most places where you currently use the Command Line build runner.
Today, JavaScript is the most popular programming language in the world, and a lot of this is due to Node.js, the world’s leading JavaScript runtime. TeamCity 2021.1 comes with a new Node.js build runner that provides first class support for building your web applications. It supports npm and yarn, can work with public and private registries, and automatically detects build steps based on package.json. Just like with all other build runners in TeamCity, you can run your builds inside a Docker container and set them up using a Kotlin-based configuration.
TeamCity has always allowed viewing thread dumps of processes running on build agents. However, when your build was run in Docker, this was difficult. Version 2021.1 lets you view thread dumps of Java processes running in Docker containers on any operating system. For Linux-based Docker containers, you can also see the list of other running commands and their parameters.
In addition to the new Kotlin and Node.js build runners and thread dump viewing improvements, the new version features improved ReSharper Inspections and Duplicates Finder build runners which are now cross-platform and can run in Docker.
TeamCity has always been famous for its ability to scale to large projects with lots of big files, as well as for its top-notch integration with Perforce. Version 2021.1 brings the Perforce integration to the next level with a number of new great features:
Special care is put into the TeamCity security features, and we keep improving them with every new release.
Version 2021.1 allows you to generate access tokens that are limited in time and scope. Now you can grant scripts that interact with the TeamCity API just enough rights to do their job, without the fear of giving them too much power. You also no longer have to remember to revoke their access after they finish.
TeamCity now has a separate permission for running personal builds with custom patches. This helps you ensure that all code executed on build agents is authored only by trusted users.
TeamCity 2021.1 opens new dimensions of control over your build configurations. Your build triggers can now define custom parameters to enable or disable build steps, or change what happens inside your build scripts. For example, your nightly builds can now be different from the builds triggered by version control check-ins, all within the same build configuration.
Building on cloud agents just got faster. Starting with 2021.1, you can enable Git shallow
cloning and check out the latest version of source code with depth=1
, without
creating local Git mirrors. This will be particularly useful for companies that spin up
clean, short-lived build agents in the cloud for every build.
You are no longer limited to only one VCS trigger per build configuration – TeamCity now allows adding multiple triggers with different rules and with different branch filters. For example, your release branch can be built immediately after the commit, but all other branches will have to wait for their own VCS quiet period.
In TeamCity, you can set up CI/CD pipelines through the UI, through Kotlin configurations, or through a mix of both. However, mixing different methods may lead to a lot of confusion and versioning problems. To ensure that your configurations stay predictable and easy to manage, we have added a new option that will allow administrators to prohibit editing project configurations through the UI if they are set up using Kotlin.
For many large organizations, a highly-available CI is critical to their workflows. TeamCity 2021.1 strengthens multinode setups with three new features.
The larger your CI/CD setup is, the more important it is to regularly perform server maintenance tasks. At the same time, any server downtime directly translates into a lapse in your team’s productivity. To allow for high availability and minimize the downtime during maintenance, TeamCity 2021.1 introduces the new “Main TeamCity node” responsibility that can be transferred to a secondary node in runtime. When you do it, the secondary server becomes the main node and automatically receives all of the main node’s responsibilities, including processing builds and managing build agents.
TeamCity now allows you to define the share of builds that will be processed by its nodes. This helps you make sure that every server takes just the right amount of the build processing load and doesn’t exceed its hardware capabilities.
Previously, every TeamCity node had its own search index that was stored locally. Version 2021.1 provides an alternative search engine based on Elasticsearch. It has a distributed index, consumes less disk space, and works more efficiently in multinode installations.
We are continuing to further improve the Sakura UI, making it faster, easier to use, and supporting all workflows from the classic UI. The new version brings a UI Assistant that shows new users how to navigate around the interface, improvements to the Build Status widget, updates to the Build Overview page, project hierarchy views, and more.
These are just a few of the many great new features in TeamCity 2021.1. For the full list of changes, please refer to the TeamCity documentation.