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.

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.

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:

• Perforce Shelve Trigger now understands when a shelved changelist is related to a non-default stream and allows the build to be run on it.
• TeamCity now detects changelists that have reviews in Perforce Helix Swarm and adds links to the respective review and change pages in Build Overview and Changes pages, respectively.

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.

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.

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.

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.

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.

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!

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 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.

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.

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:

• Improved commit hooks setup. Now you can set up commit hooks and have your builds automatically triggered by installing only one single script on the Perforce server.
• Perforce workspace cleanup. TeamCity now provides manual and automated clean-up of the Perforce workspaces created by the TeamCity server.
• ChangeView specification support. You can now limit the VCS root scope to particular revisions with the use of the ChangeView specifications. Usage of the @revision syntax in the import statements of Perforce stream definitions is now also supported.

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.

Switching main node responsibility in runtime

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.

Elastic-based search

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.