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 are working on TeamCity Cloud – a fully managed CI/CD solution that will be completely hosted and supervised by JetBrains.
Multi-server scalability
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.
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
Developers must have the power to create great software without having to deal with the pain of installing and maintaining build infrastructure. That’s why we are working on TeamCity Cloud – a fully managed CI/CD solution that will be completely hosted and supervised by JetBrains. It will have everything you love about the original TeamCity, and it will run your builds and tests on dedicated instances in the cloud, fully isolated from other users. For current users, we will provide a way to migrate local installations to the cloud solution.
TeamCity Cloud is currently in public beta, and we expect the public release to happen before the end of 2020.
Multi-server scalability
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 with new features.
Full-featured UI
Build queue processing
Core CI improvements
Trigger-defined parameters
Another popular feature request that we are going to implement is trigger-defined parameters. This will give you greater control over your builds and tests, and allow you to run them differently based on what triggered them. A typical use case for this feature could be the automatic publishing of a nightly build when it is triggered by a schedule (but not by other triggers).
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.
Agentless builds
TeamCity build agents combine the capabilities and versatility that no other CI has. But when they employ external tools, all of that power remains unused because they have to wait for an external job to finish. To optimize the way TeamCity works in these situations, we want to implement a new “agentless build” API that will make it possible to use external tools without relying on TeamCity build agents. All jobs made through this API will be seen as common builds in TeamCity, with their own reports, status, and history.
A good example of a case where this feature could be very useful is the use of an external deployment service. Imagine using a deployment service with a manual approval step in a release pipeline. If you call it from a TeamCity agent, you could spend hours, or even days, just waiting for somebody to approve the release. If this didn’t require a build agent, your CI setup would be so much more efficient! The new API will help you avoid situations like this.
Your voice is welcome! Please describe your own use cases for how you would want to use agentless builds described above in the respective YouTrack issue.
Interpreting flaky tests within one build
Failed tests don’t always mean broken code. Often if your test passes at least once over several runs, this means that the code works correctly. For example, your UI test may fail due to a network problem but succeed on the second try, and you may want it to be marked as successful because there were no rendering problems.
TeamCity has always had a strict policy about failed tests: any test failure resulted in a failed build step. But this was not convenient in some testing scenarios. To support more workflows, we will allow you to choose how to deal with these situations, so you can keep your build green even if some tests appear flaky within the same build.
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 can always find the correct way to configure your VCS roots, clean-up settings, or entire projects – as Kotlin code.
Omitting imports in DSL code
We want the Kotlin DSL to be as brief and expressive as possible. To make it easier for you to describe your build configurations in Kotlin, we will allow you to omit the imports section in the beginning of the settings.kts file. This means that settings.kts can start directly with the project {...} section and will not require you to explicitly specify imports that are required to compile the script.
Disabling UI editing
TeamCity lets you set up CI/CD pipelines in a variety of ways based on your preferred workflow. Your projects can be configured through the DSL, through the UI, or through a mix of both. However, mixing manual edits with DSL changes may lead to a lot of confusion and versioning problems. To ensure that your configurations stay predictable and easy to manage, we will add a new option that will allow administrators to prohibit editing project configurations through the UI if they are set up using the Kotlin DSL.
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.
.NET 5
Many of our users are excited about Microsoft’s plans to release .NET 5 – a new platform that will unite .NET Core and .NET Framework. .NET 5 will eliminate the differences between developing for different platforms, and we are planning to follow the same path in TeamCity. The all-new .NET build runner will unite all 5 runners that we currently have and allow you to build any type of app, with all available runtime options.
We are not planning to remove the old build runners in the next few releases, but our general goal is to implement new features and bug fixes only in the new one.
Python
Over the past several years, Python has seen immense growth, and we have seen a lot of interest in CI/CD solutions for Python, as well. We are planning to implement a new Python runner that will support most of the popular development and testing frameworks for Python and give you a consistent experience across every facet of your CI workflow.
We already have a general idea of what a Python integration should include, but you are welcome to contribute your own suggestions in the respective YouTrack issue.
JetBrains Space
Our company has recently introduced a new product, Space – an integrated team environment that comes with a complete set of tools for modern software development. Space provides so many opportunities for integration with TeamCity:
- Building pull requests and publishing build statuses
- Sending notifications to chats and generating todo-list items
- Syncing with a team directory and inheriting project permissions from Space
- And much, much more
We are working closely with the Space team to figure out the most useful ways to integrate the two products, and we’re planning to start rolling some of those integrations out this year.
Bitbucket Cloud
We are exploring ways to add support for the Bitbucket Cloud pull requests. At the moment, it is not very clear to what extent it is possible to integrate with Bitbucket Cloud, so our plan is as follows:
- Implement support for pull requests made in one specific repository (not forks).
- Gather the feedback if the initial implementation meets the needs of our users, and investigate more scenarios if it doesn’t.
You can vote for this issue in the respective YouTrack issue.
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 source code, build artifacts, and various packages to one another, saving a lot of time and networking costs.
(Fewer downloads is good for the planet: it saves electricity and reduces your carbon footprint. So this feature allows you to go green even as your builds go green faster.)
New licensing options
More and more of our customers are willing to run build agents in the cloud because it lets them quickly increase capacity of their delivery pipelines when needed. However, the current licensing policy of TeamCity is restrictive for them because it requires having yearly licenses for build agents that they use only during peak times. To address this, we are going to rethink how we approach TeamCity licensing in cloud installations.
Although we have not yet figured out how to do this, we feel that it is important to announce that we are working in this direction. If you have a relevant use case, you are welcome to share it in the respective YouTrack issue.
New “Sakura” UI
CI/CD is one of the tools that most developers use every day, and we want it to feel like home. Last year we introduced a new experimental UI (codename “Sakura”), and it has really proven itself. It is fast, powerful, and modern, and we’re proud of where it stands after such a short time. The next improvements to the Sakura UI will address the following areas:
- Build queue page
- Header
- Mutes and investigations pages
Many users have asked us whether we are planning to kill the old UI.
The answer is no – Sakura UI will not replace the classic UI anytime soon. Over the next year, we are planning to focus on improving what has already been implemented in the Sakura UI until it reaches feature parity and supports all main use cases of the classic UI. This will allow us to make it a default, but even then we will keep the option to use the classic UI.
We are lucky to have the opportunity to test every small change to the UI within JetBrains. Nightly builds of TeamCity are used by dozens of teams with very different CI/CD practices, from individual developers to huge projects like IntelliJ IDEA and Kotlin. The classic UI didn’t have this opportunity: it grew naturally with the company, and was built using technologies that are now over 10 years old. It reached its limits a long time ago, and we feel that it now restricts us from delivering new features fast enough. That’s why we’re building Sakura UI, and we truly believe that it will bring a bright new future to TeamCity and to all our users.