TeamCity 2020 Roadmap (Part 2 of 2)

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 following issue: https://youtrack.jetbrains.com/issue/TW-25141

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.

JIRA Software Cloud

TeamCity already has an elegant integration with JIRA, which automatically replaces issue codes in commit messages with links to the respective JIRA issues. To support even more workflows, we are planning to extend the integration and send the status of your builds and deployments to Jira Software Cloud. This will give you the ability to look into your CI/CD pipelines and release history right in your issue tracker, so you can know which issues are associated with failing builds.

Azure DevOps

We are extending the list of Git hosting services supported by the Pull Requests build feature, and we’re adding support for the Azure DevOps pull requests. The new option will allow you to automatically run builds on pull request branches of the Azure DevOps, very similarly to how you can now work with GitHub and GitLab.

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:

1. Implement support for pull requests made in one specific repository (not forks).
2. 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 at https://youtrack.jetbrains.com/issue/TW-57468.

Cloud features

Kubernetes

Kubernetes gives you an efficient way to implement a scalable CI/CD architecture on top of a Kubernetes cluster. Using Kubernetes, you can launch build agents automatically when you need them, let them do their job, and then remove them after the build is completed.

In 2020.1, we are improving and bundling our Kubernetes plugin with TeamCity, so you can use it right out of the box with minimal fuss.

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

Pre-packaged build agents

We are improving the procedure for creating cloud images of build agents by adding a new option to download a pre-packaged agent distribution from the TeamCity server. Pre-packaged build agents will not need to update themselves upon connection to the TeamCity server, and this will make creating and updating cloud images faster and more straightforward.

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 following issue: https://youtrack.jetbrains.com/issue/TW-48045.

Team and project level notifications

Continuous integration is all about getting feedback quickly. To take TeamCity’s notification capabilities to new heights, we are implementing a new build feature that will allow project administrators to set up automatic alerts to an entire team via Slack, Microsoft Teams, email, or JetBrains Space. New notifications will be configured on the build configuration level, so you can edit, reuse, and share them using the Kotlin DSL.

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
• Sidebar
• 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.

See TeamCity 2020 Roadmap Part 1