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:
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.
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.
Security
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.
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.
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.
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.
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.
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.
TeamCity Cloud
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 Developing
- Integration with other JetBrains products
- Monthly reserved build agents Developing
- Open source–friendly licensing
- Migration from other CI tools
- Free plan Exploring
- Enterprise plan Exploring
- Plugin support Exploring
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
Plugin support
Security
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
- Out-of-the-box HTTPS support
- Integration with Let’s Encrypt
Cloud features
Persistent caches for cloud agents
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
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
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
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
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.
GitHub App
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.
GitHub commit hooks
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
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.
Intelligent test splitting
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
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:
- 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.