Cloud features
We want TeamCity to have everything you need to make your CI/CD pipelines fast and cost efficient. This is why we are working on a range of features that will let you set up and run your builds in the cloud more easily.
Persistent caches for cloud agents
Teams using TeamCity in the cloud should be able to complete their builds as quickly as they would if they were using local installations. Persistent cloud caches will allow cloud build agents to transfer build dependencies such as Maven artifacts and NPM packages to one another, saving you time and networking costs.
Additionally, needing fewer downloads is good for the planet. It saves electricity and reduces your carbon footprint. So this feature will help you go green even as your builds go green faster.
Reorganized AWS credential management
We recently released a new credential management system – AWS Connection – that provides TeamCity’s build features and cloud integrations with temporary AWS security credentials that only have the rights needed to do a specific job. Our next step is to implement support for AWS Connection within all the plugins available in TeamCity. This will take the burden of manually configuring access to EC2, ECR, S3, and other resources off your team’s shoulders.
Out-of-the-box Microsoft Azure support
More and more of our customers are willing to run build agents in the cloud because it lets them quickly increase the capacity of their delivery pipelines when needed. To support users migrating to Microsoft Azure, we are planning to improve and bundle the TeamCity Azure plugin.
Build agent image builder
With TeamCity’s image builder, you will be able to build custom VM images of TeamCity build agents for various environments. This will help to speed up your builds using pre-baked VCS repositories, build dependencies, Docker images, and so on.
Executor mode
We would like to support a common scheduler like Kubernetes, HashiCorp Nomad, AWS ECS, or similar in order to run simple build tasks without the requirement to specify and maintain a build agent.
This will allow you to start setting up project build configurations without thinking about what workers will run your builds.
Such an approach will be handy for small and simple tasks that do not require local caches of VCS roots, dependencies, and such. It will also increase resource utilization using schedulers. The schedulers can run multiple tasks in parallel on the same cluster node out of the box.
JetBrains-hosted agents
We’re looking into adding more options for JetBrains-hosted agents for TeamCity Cloud. This will include recreating per-minute macOS agents and providing ARM-based Linux agents.
Multi-tenant TeamCity
Currently, TeamCity Cloud provides a separate server for every customer. We’re looking into the possibility of hosting multiple projects on the same server. This will help us to reduce costs and maybe even allow us to provide a free version of TeamCity Cloud.
Build runners and integrations
Developers all over the world love TeamCity’s tight integrations with build tools and external services, and we take great care to provide them with the best possible support. Below is a list of the new integration features that we are planning to add.
Pull Requests build feature to control triggering
Currently, the Pull Requests build feature extends branch specifications of a VCS root to include branches of open pull requests that match certain filtering criteria.
We want to extend this functionality so that you can automatically trigger builds for a subset of pull requests while also being able to trigger builds for other branches manually.
Consolidation of project and build features related to integrations
This feature will allow you to to configure a connection (for example, to GitHub) at the project level. You’ll be able to indicate whether you need TeamCity to collect any pull requests and issue tracker information directly within the connection settings, and you’ll be able to indicate which build configurations must publish statuses.
This feature will save you significant amounts of time, as you’ll be able to configure the settings at the project level once and for all.
Token management UI
OAuth tokens issued via Connections are stored in an internal TeamCity token storage. Currently, they are extracted from the storage when certain settings (for example, a VCS root or a build feature) are configured via the admin UI.
We want to introduce a UI for token management. This allow you to check your token usage and scopes, in addition to:
- Seeing token IDs and connections, the accounts used to issue the token, etc.
- Issuing new tokens so they can be referred to by ID (for example, from DSL code).
- Deleting tokens from storage.
- Seeing and editing the project scopes of tokens.
- Viewing actual usages of tokens from within various settings.
Automated setup of new projects from the VCS
Large companies love TeamCity’s ability to scale to thousands of build agents and tens of thousands of projects. However, at some point, adding new projects stops being fun and becomes a necessary burden that you have to repeat for every new endeavor.
With this feature, we’re looking into the ability to automatically create a project in TeamCity when a new .teamcity repository is created.
Pull request support in UI
TeamCity has dedicated support for Github pull requests. From the TeamCity point of view, pull requests are a special branch. We’re going to mark these branches in the UI so that they’re clearly recognizable.
Implement GitHub Checks support
With GitHub Checks support, we’re going to provide users with more informative reports of what happened during the build, based on the data coming from GitHub.
The main benefits of this feature include:
- Extended hypertext reports instead of plain statuses.
- The possibility to annotate specific places in the source code (e.g., for inspections).
Additional filtering criteria for the Pull Requests build feature
Currently, there is only a target branch filter present in TeamCity’s Pull Requests build feature. We’re looking into adding new filters such as review statuses, labels, author roles, and more.
For game development
TeamCity combines the capabilities and versatility that no other CI tool has. No wonder it’s one of the most popular CI solutions used in game development. We are starting to explore the contributions it can make in this industry in three main areas:
- Unity support.
- Unreal engine support.
- General CI/CD workflows in game development.
Interested in using TeamCity to build your games? We welcome you to sign up here to participate in our research.
Perforce integration improvements
TeamCity offers native integration with Perforce Helix Core , one of the most commonly used version control systems in game development. Here’s what we have planned for the Perforce support.
Automatic deletion of Perforce workspaces created by TeamCity
Using Perforce agent-side checkout creates Perforce workspaces. When a TeamCity agent is no longer in use, the workspaces are left on the Perforce server.
To avoid using up server resources, we’re going to introduce automatic deletion of TeamCity-created Perforce workspaces for TeamCity agents that are no longer active.
More control over Helix Swarm review comments from commit status publisher
Currently, the commit status publisher provides information about each stage of the build (queued, started, succeeded/failed, etc.), which can get overwhelming.
We’re going to give you more control over which comments are sent and which states trigger them.
Custom Perforce workspace name for agent-side checkout
Currently, TeamCity auto-generates the Perforce workspace name during agent-side checkout. We’re planning to add the option to specify a custom pattern for the workspace name. This pattern will allow for the use of:
- Project ID and configuration ID.
- VCS root external ID.
- Name of the checkout directory.
Unreal Engine support
Unreal Engine is one of the most popular game engines used for game development. We’re working on a new Unreal Engine plugin that will provide TeamCity users with the following features:
- Unreal Engine installations detection on build agents.
- Dedicated Unreal Engine runner.
- Automatic discovery of Unreal Engine build steps.
- Structured build logs with problems highlighting.
- Test reporting.
Multi-node setup
Running multiple TeamCity nodes and making them work together can elevate your CI/CD to a whole new level of performance and reliability. We’re improving how TeamCity works in a clustered environment by implementing new features for multi-node setups.
Improved availability
Server maintenance should not block developers from running their builds. We’re planning to invest more in features that increase TeamCity’s availability, including the automated conversion of secondary nodes to main ones, and we’ll continue removing the dependency on the shared data directory in a multi-node setup.
Improved propagation of changes in configuration files
We’re planning to start storing all configuration files in a local Git repository. This repository can be used to share configuration files between TeamCity nodes in a multi-node setup.
This will allow us to set up transaction notifications about any changes in these files, ensuring the atomicity of these modifications as well as the atomicity of secondary node notifications about them.
Standalone build log service
In the multi-node setup, all nodes work with build log files stored in a shared data directory. Most of the time one node “owns” the log file corresponding to some build. This node writes to the file while other nodes can only read it.
In case a TeamCity node decides that the node that “owns” the log file crashed (while in fact it’s working fine), another node might start writing to the same log file and corrupt it.
We’d like to implement a standalone build log service that can be accessed by HTTPS from every node. The new approach will help us to eliminate the possibility of log files getting corrupted as a result of two nodes writing to the same file.
Commit all configuration changes in a Git repository
The idea behind this feature is to commit and push every change (both project-related and global) to a specified Git repository. This repository can then be used to share configuration files between TeamCity nodes in the multi-node setup.
This repository can also be used as an audit of all changes made in TeamCity settings (made through UI, Rest API, or Versioned Settings).
Security
Continuous integration is at the heart of the development process and is critical to maintaining a workflow that minimizes the risk of exposing data to third parties or falling victim to cyber attacks. In addition to our continuous work on security-related improvements in the product, we’re going to introduce the following features:
Integration with remote secret storages
This feature allows TeamCity to fetch the value of a parameter located in an external parameter storage right before running a build. You can go to TeamCity’s Parameters UI and add a parameter referencing the external one. This feature will come in handy for teams that store parameters in an external storage like AWS Parameter Store, HashiCorp Vault, Azure App Configuration, Azure Key Vault, etc.
This repository can also be used as an audit of all changes made in TeamCity settings (made through UI, Rest API, or Versioned Settings).
Handling unsafe builds
We’re developing functionality that will detect pull and merge requests from forks for all supported VCS hostings. To improve security, we’re also going to implement mandatory manual approval for builds triggered in this manner.
Configuration as code
Thanks to the expressiveness of the Kotlin DSL, our users are really getting into storing their CI/CD configurations as code. We want to improve this feature, and these are the main changes that we have planned for the near future.
Simplified user experience
Using the Kotlin DSL allows more experienced TeamCity users to reuse build configuration settings more naturally, saving teams time and effort. Since the Kotlin DSL is statically typed, using it in an IDE also makes discovering available APIs much simpler.
At the same time, we understand that knowledge of Kotlin or the need to work with a specific IDE shouldn’t be an obstacle to configuring pipelines in TeamCity. That’s why we’re researching ways to simplify the user experience and make working with TeamCity even easier.
Freedom from imports in IDEs
To simplify editing Kotlin files in non-IDEs code editors, we’re going to remove the necessity to explicitly specify DSL-related package imports in .kt files. Imports will be handled on the TeamCity server side automatically.
This will allow you to compile code in any code editor. TeamCity will ensure that it actually works.
Simplified basic DSL for small projects
While the Kotlin DSL provides you with the ability to configure pipelines exactly how you need them to run, smaller projects might not need all the complexity that the Kotlin DSL entails. In this regard, we’re going to simplify basic DSL for smaller projects so you can easily copy-paste examples of DSL code from the documentation. This will help speed up the configuration process dramatically.
Experimenting with YAML
While the Kotlin DSL provides you with a powerful way to configure your CI/CD projects, some people might feel more comfortable with using YAML for pipeline configuration.
We’re looking into the opportunity to add YAML as an option for configuring projects as code.
Allow opening Versioned Settings repository in an external system
If you use the Kotlin DSL for configuring your versioned settings and need to make some changes, TeamCity will be able to take you to the corresponding file in the repository in an external system where the relevant code is stored. That means there’s no more browsing around looking for that one file in the repo!
Core CI improvements
JBA login and the new license format
We want to allow you to manage your Server and Agent licenses transparently and flexibly via JetBrains Account. We further want TeamCity to be able to pick up those licenses in real time, without having to generate and download offline license keys.
We are planning to:
- Simplify license management for TeamCity On-Premises customers by allowing them to manage their Server and Build Agent licenses through their JetBrains Accounts without having to deal with numerous offline license keys.
- Introduce JetBrains Account login for TeamCity installations (including TeamCity Professional).
Matrix builds
We’re planning to add a new feature that will allow TeamCity to take a set of parameters and run a build for each combination of them – Matrix builds. This feature is especially useful when you need to run the same build or test in various environments, for example, different operating systems, Java/.NET versions, different browsers, and so on.
Matrix builds will significantly reduce time and effort, allowing you to establish one set of specified parameters (for example, OS and environment) once and then run the same set in parallel on other build configurations.
Deployment dashboards
We're going to make it possible to save a history of deployed builds.
Thanks to this new functionality, you’ll be able to check the current state of all deployments, such as which version is deployed on prod and which one is deployed on staging.
You’ll also be able to access deployment history reports on all instances. On the deployment dashboard, you will find a list of instances, their current states (In progress, Success, Failed) and relevant build details (timing, agent, who triggered the build, etc.)
Schedule a build to run at a specified time
Have you ever wished you’d be able to schedule a build not to run immediately but at a specified time?
We’re developing a functionality that will allow you to schedule the build to run at a specified time (including time zone) or time from now (e.g., two hours from now).
The build will be immediately added to the queue and will wait until the specified scheduled time.
Using shared resources in composite builds
We’re looking into the possibility of passing a value locked in a composite build to its dependency builds. In the future, we’d also like to provide TeamCity users with the ability to lock resources for a set of builds linked with snapshot dependencies.
TeamCity’s UI
Because developers use their CI/CD solutions every day, we want TeamCity to feel like home.
The Sakura UI tab migration
As of version 2022.10, the Sakura UI is default in TeamCity. We’re now working on moving towards full feature parity between the Classic and Sakura UIs. To do so, we will reimplement pages from the Classic UI and polish the plugin subsystem to integrate plugin tabs in the Sakura UI.
TeamCity onboarding improvements
TeamCity is a powerful CI/CD system with a great number of advanced features. To help users familiarize themselves with TeamCity and configure the software exactly how they want it to run, we’re going to provide onboarding guides within the solution. The interactive guides and hints will teach newcomers how to use TeamCity effectively and help established customers migrate from the Classic to the Sakura UI.
Interactive guides and template projects
To improve user onboarding, we’re going to introduce template demo projects to TeamCity. With the help of these template projects, you’ll be able to try TeamCity without connecting your own codebase to the CI/CD tool and get to your first green build faster.
Interactive guides will help you to get an overview of TeamCity’s core features right within the UI. The guides will present different scenarios and use cases to get you acquainted with TeamCity faster.
Sakura UI performance
We are working to improve performance for the bigger TeamCity installations. Our primary focus is on agents and the project pages. Our goal is to decrease the time to first byte, cumulative layout shift, and time to interactive metrics, as well as other web vitals. TeamCity users can expect to have application pages render and load faster in all browsers.
Sakura UI: Problems tab
TeamCity provides an overview of current problems and investigations on the project and build level. Users can review build configuration errors, failed tests, problems that are being investigated, check their assignee and status.
We’re reworking the UI to give our users a better overview of all the issues and their status in a selected project. They can now be found under the common tab – Problems.
Here, users will be able to filter problems by type (failed tests, build problems, and build configuration problems), status (muted/unmuted), and investigator (assignee).
With this update, we’re striving to provide our users with a more convenient and concise way of reviewing existing build issues and their statuses.
TeamCity Pipelines
TeamCity Pipelines will provide a simple and intuitive experience for building CI/CD pipelines, powered by the signature intelligence of JetBrains products.
With TeamCity Pipelines, our plan is to shift our focus from individual steps of the process of automating builds and tests to the overall experience of setting up delivery pipelines. TeamCity Pipelines will provide a simple and intuitive experience for building CI/CD pipelines, powered by the signature intelligence of JetBrains products.
The brand new visual pipeline editor in TeamCity Pipelines makes working with CI/CD pipelines of any complexity simple, powered by TeamCity’s CI/CD engine, which can handle enterprise-level workloads. The intelligent configuration assistance built into TeamCity Pipelines will guide you through all of the steps of pipeline configuration and automatically suggest optimizations along the way.
Here are some of the new features that we’re working on for TeamCity Pipelines:
YAML for configuration as code
The Kotlin DSL is a powerful way to configure your pipelines as code. However, some users might find it easier to start configuring their CI/CD projects using YAML, which is the language widely used in the CI/CD industry.
TeamCity Pipelines will provide users with an opportunity to use YAML to store build settings and define jobs and their dependencies.
Test parallelization
TeamCity can automatically parallelize test suites using a smart algorithm, without any additional input from the user. The user will only have to choose how many build agents their tests should run on in parallel. This will help to significantly reduce build times on the next run.
Agent playground
Sometimes, it might be difficult for users to understand what software is installed on TeamCity build agents, which OS specifically the agents are using, and how users can modify JetBrains-hosted build agents.
We’d like to develop a sort of an agent playground that will give people the ability to run their scripts on the agent without running the pipeline. This way, users will be able to connect to playground agents for investigation and debugging purposes after the build has finished.
We’ll also provide users with the ability to open agent terminals directly from the TeamCity Pipelines UI in order to quickly check the agent environment and debug a specific agent’s issues.
Enhanced Docker integration
If the software you need for your pipelines configuration is not available on an agent, you can choose to run your builds in a Docker container.
The enhanced Docker integration in TeamCity Pipelines will allow you to use the autocomplete feature to find the correct Docker image from https://hub.docker.com/. It will also display a list of previously used Docker images and provide a link for each Docker image result found. This will make it easier and faster to find a necessary Docker image.
We’re investigating the possibility of providing a user-friendly solution for when a specific image doesn’t exist in Docker Hub. Users might be able to reference a Docker file from their current VCS repository.
Showing applied and recommended optimizations
Thanks to its intelligent test parallelization, build re-use, caching, and other features, TeamCity can help organizations significantly reduce their build time. Currently, TeamCity shows the total optimized (saved) time for each build run.
To expand this functionality, we’re going to provide a more comprehensive view of which optimizations were applied to the build run. We also strive to provide a list of potential optimizations that could be applied to further reduce the build time.
You can sign up for early access to TeamCity Pipelines here.
TeamCity Cloud
We want our users to be able to develop without the hassle of installing and maintaining build infrastructure. To this end, we provide TeamCity Cloud – a fully managed CI/CD solution that is completely hosted and managed by JetBrains. It has the same functionality as the on-premises version, with the exception of several administrative features that are not needed in the cloud installation.
While everything we develop appears in both the on-premises and cloud versions of the product, TeamCity Cloud has a number of additional features on its own roadmap:
- macOS agents with Apple Silicon (M1 chips) Developing
- Integration with other JetBrains products Designing
- Open source–friendly licensing Designing
- New pricing tiers. Developing