TeamCity 2020 Roadmap (Part 1 of 2)
We want to share what we’re actively developing or designing, and give you sneak peek of the announcements you can expect to see over the coming year.
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.
We are going to launch a public beta of TeamCity Cloud in the summer of 2020.
YouTrack project: https://youtrack.jetbrains.com/issues/TCC.
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 the following features:
- Trigger processing. Professionals working with large installations have hundreds, or even thousands, of triggers that fire on changes in VCS, package updates, and new artifacts. To give them the highest possible performance level, we will allow secondary servers to take part in this process and take some of the load off of a primary server.
- Full-featured UI. For greater control over your CI, the current limited UI of the secondary server will be replaced with a full-featured version, making it possible to edit build configurations, manage cloud agents, and perform other actions that were not previously available. This will enable your team to keep working with TeamCity while the primary server is under maintenance.
Our overarching goal is to make the secondary server equal to the primary server in every respect. The next stop on the roadmap will be enabling the secondary server to process the build queue and start builds.
Core CI improvements
Conditional build steps
The collective voice of the community can have a tremendous impact – and we are happy to announce that we are going to implement the most-voted feature request in our issue tracker: conditional build steps. This feature will allow you to enable or disable certain build steps depending on specific conditions. You may want to use this in a variety of situations:
- To deploy changes in different branches to different staging servers
- To run additional tests on a particular build agent
- To execute different command line scripts on different platforms
- And many, many more
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.
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.
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 following issue: https://youtrack.jetbrains.com/issue/TW-30777
Kotlin DSL
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.
Per-branch configurations
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 a full range of different options across different feature branches.
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.
See TeamCity 2020 Roadmap Part 2
Subscribe to TeamCity Blog updates
