TeamCity Roadmap

This page contains a list of new features that we’re actively developing or designing for TeamCity. This should give you a sneak peek of the announcements you can expect to see over the coming year.

The information on this page is updated on a regular basis. Current status of the roadmap features:

7
developing
14
designing
7
exploring
0
Available in EAP
TeamCity Cloud

TeamCity Cloud

To empower developers to create great software without the pain of installing and maintaining build infrastructure, we have recently released TeamCity Cloud – a fully managed CI/CD solution that is completely hosted and supervised by JetBrains.

Learn more

Multi-server scalability

Multiserver setup

Running multiple TeamCity servers and making them work together can elevate your CI/CD to a whole new level of performance and reliability. We are improving how TeamCity works in a clustering environment by extending the capabilities of secondary servers.

Learn more

Core CI improvements

Core CI improvements

To give you greater control over your CI, we are working on a variety of new features that will make it easier to automate your DevOps pipelines and also help you to organize your development process in a more efficient way.

Learn more

Kotlin DSL

Configuration as code

We are happy that more and more users are getting into storing their CI/CD configurations as code. In the near future we are going to make the Kotlin DSL even more expressive, and add more ways to get started with it.

Learn more

Build runners and integrations

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 support them in the best possible way. In this section you can read about new integrations that we are planning to add.

Learn more

Cloud features

Cloud features

We want TeamCity to have everything you need in a modern workflow. That’s why we are working on a range of features that will let you more easily set up and run your builds in the cloud.

Learn more

New 'Sakura' UI

New “Sakura” UI

We’re continuing our quest to create a new UI that will be fast and easy to use, and will let us deliver new features faster. Our current focus is on making the Sakura UI support all main use cases of the classic UI.

Learn more

TeamCity Cloud

Designing

TeamCity Cloud is a managed version of TeamCity that is hosted by JetBrains. It has the same functionality as the on-premises version, except for several administrative features that are not needed in the cloud installation.

While everything we develop appears in both versions, TeamCity Cloud has a number of additional features on its own roadmap:

  • JetBrains-hosted macOS build agents
  • Integration with other JetBrains products
  • Monthly reserved build agents
  • Open source–friendly licensing
  • Migration from other CI tools
  • Free plan Exploring
  • Enterprise plan Exploring
  • Plugin support Exploring

Sign up for TeamCity Cloud

Multi-server setup

Running multiple TeamCity servers and making them work together can elevate your CI/CD to a whole new level of performance and reliability. We are improving how TeamCity works in a clustered environment by extending the capabilities of multinode setups with new features.

High availability

Designing Exploring
Server maintenance should not block developers from running their builds. We are planning to invest more in high-availability features, including automated conversion of a secondary node to a primary node, transparent routing of some users to secondary nodes, and removing the requirement of having a shared Data Directory in the multinode setup.

Plugin support

Developing
Plugins are great for extending the functionality of TeamCity and customizing its user interface. To make sure that switching between primary and secondary nodes goes smoothly for end-users, we will allow plugin developers to adapt their plugins for secondary servers.

Cloud features

Persistent caches for cloud agents

Designing

Teams using TeamCity in the cloud must have the opportunity to complete their builds as quickly as if they were using local installations. Persistent cloud caches will allow cloud build agents to quickly transfer build dependencies such as Maven artifacts and NPM packages to one another, saving time and networking costs.

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

Migration of artifacts to cloud storage

Designing

More and more of our customers are moving their CI to the cloud because it lets them quickly increase the capacity of their delivery pipelines when needed. To improve the migration experience, we are working on a new feature that will allow transferring build artifacts, logs, and other data from local hard disk to cloud storage locations, such as Amazon S3.

Launching Docker wrapper on Kubernetes build agents

Designing

Kubernetes allows you to launch build agents for a limited time, and then shut them down after the build is completed. To support even more workflows, we are improving Kubernetes build agents by allowing them to run Docker wrappers for containerized builds.

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 are continuing to improve it, and here are the main changes that we have planned for the near future:

Viewing project configuration as DSL

Designing

The View DSL button provides a great way to learn how to describe your build configuration in Kotlin code. Right now it is available only for build configurations, which is not very helpful if you want to write configurations for complete projects or if you are looking for the right piece of code to configure one particular thing. We are going to add similar buttons to other sections of TeamCity, so you will always be able to find the correct way to configure your VCS roots, clean-up settings, or entire projects as Kotlin code.

Branching project settings

Designing

Having the freedom to use different project settings in different branches can make a big difference. Right now, TeamCity requires that your feature branches use the same set of build configurations and build chains as the default branch. Many users report that this limitation is very restrictive. For example, if your new feature requires you to build a new microservice, you cannot do it in the same build chain, and you have to find a workaround.

To make the whole system more consistent and easier to use, we will improve how TeamCity works with versioned settings and add support for branched project settings.

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 support them in the best possible way. Below is a list of the new features that we are planning to add.

JetBrains Space

JetBrains Space

Developing

Our company has recently introduced a new product, Space – an all-in-one solution for software projects and teams. Space provides many opportunities for integration with TeamCity, such as sending notifications to chats, generating to-do list items, syncing with a team directory, inheriting project permissions, and others. We are working closely with the Space team to figure out the most useful ways to integrate the two products, and the next stop on the roadmap is authentication via Space.

C# script build runner

Developing

Recently we have added the Kotlin script build runner that allows launching scripts written in Kotlin. To provide even more flexibility in configuration, we want to create the new C# script build runner that will allow you to specify build steps in C#, will be cross-platform, and will also support NuGet packages.

Authentication via Azure DevOps

Developing

We are extending the list of authentication modules supported by TeamCity, and we’re adding support for Azure DevOps. The new option will allow you to log in to TeamCity using your Azure DevOps account, very similarly to how you would with GitHub, GitLab, or Bitbucket Cloud.

GitHub App

Exploring

We are looking into the possibility of authorizing TeamCity to work with GitHub as a GitHub App, running various actions and making use of the GitHub API without creating separate service accounts or acting on behalf of a user.

Perforce Swarm

Exploring

Among all the different version control systems, Perforce takes a special place in TeamCity, as it is the de facto standard for CI/CD in many industries. We are exploring ways to add support for Perforce Swarm and integrate it with Pull Requests, Commit Status Publisher, and other TeamCity features.

If you have any feature requests and know important use cases that are not covered by the current integration of TeamCity and Perforce, please share them in our YouTrack project.

GitHub commit hooks

Developing

TeamCity already supports installing a commit hook that allows GitHub to notify TeamCity of repository changes. It works great for small setups, but when your projects include hundreds of repositories, installing and managing webhooks becomes a tedious and time-consuming task. We are working on improving this experience by allowing administrators to install one webhook on the root level, and use it in all projects in your organization.

Core CI improvements

Deployment

Exploring

We are exploring ways to add new continuous deployment features to TeamCity. Here are some main areas we are looking into:

  • Dashboard with an overview of all deployments and environments
  • Deployment environments
  • Deployment runners (Deploy to S3, Deploy to ECS, and others)
  • Manual approvals

Your opinion is welcome! Please don’t hesitate to suggest feature requests in this area in our YouTrack project.

New security features

Designing

Continuous integration stands at the heart of the development process, and it is critical to maintain a workflow that minimizes the risk of exposing data to third parties or falling victim to cyber attacks. To improve the security of your CI/CD, we are working on a number of new features:

  • External secret key storage support
  • Two-factor authentication
  • Out-of-the-box HTTPS support
  • Integration with Let’s Encrypt

Intelligent test splitting

Designing

The more tests you have, the longer it takes for them to be completed. Often you find many of your build agents doing nothing, just waiting for one particular agent to finish its tests. To address this case, we are working on a new feature that will intelligently split tests into several groups of tests with similar durations and then run them on multiple build agents in parallel. This will give you your test results faster, so you can build more and wait less.

New “Sakura” UI

Developing

CI/CD is one of the tools that most developers use every day, and we want it to feel like home. Our new experimental “Sakura” UI has really proven itself over the past two years – it is fast, powerful, and modern, and we’re proud of where it stands after such a short time.

Right now the Sakura UI has almost reached feature parity with the classic UI, and in one of the nearest releases we are planning to make it the default. But before this happens, you can expect improvements in the following areas:

  • Changes
  • Agent pools
  • User profile settings
  • Fixes to already implemented pages (to make sure they support all use cases of the classic UI)
  • Performance improvements

Items postponed or removed from the roadmap

Some of the features that we announced earlier were postponed or removed from the roadmap as we introduced new functionality that rendered them obsolete.

  • Cloud-friendly pricing. The original idea was to come up with a new licensing policy that would allow using cloud build agents without paying for yearly licenses. With the release of TeamCity Cloud, we now have a fully working solution that requires paying for build minutes, so we stopped designing the same for the on-premises version.
  • Omitting imports in DSL code. We were exploring a new approach to configuration as code that would allow you to omit the imports section in the beginning of the settings.kts file. However, it appears to be a big feature that requires too much effort to implement, and we decided to remove it from the roadmap.
  • Build queue processing on secondary servers. In version 2021.1 we introduced the new “Main TeamCity node” responsibility that can be transferred to a secondary node in runtime, and because of this we postponed the development of individual new responsibilities that can be enabled on secondary servers.