We want TeamCity to have everything you need to make your CI/CD pipelines fast and cost-efficient. This is why we’re working on a range of features that will let you more easily set up and run your builds in the cloud.
Developers all over the world love TeamCity’s tight integrations with build tools and external services, and we take great care to provide them with the best possible support. In this section, you can read about new integrations that we are planning to add.
Running multiple TeamCity servers and making them work together can elevate your CI/CD to a whole new level of performance and reliability. We’re improving how TeamCity works in a clustering environment by extending the capabilities of secondary servers.
Continuous integration stands at the heart of the development process and is critical to maintaining a workflow that minimizes the risk of exposing data to third parties or falling victim to cyber attacks. We are working on a number of new features to improve the security of your CI/CD pipelines.
We are happy that more and more users are 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.
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 help you organize your development process more efficiently.
We’re continuing on our quest to create a user interface that will be fast and easy to use, and will allow the most flexibility for all sorts of workflows and development practices.
TeamCity Cloud is a managed version of TeamCity that is completely hosted and managed by JetBrains. Its own roadmap has a number of additional features.
We want TeamCity to have everything you need to make your CI/CD pipelines fast and cost efficient. This is why we are working on a range of features that will let you set up and run your builds in the cloud more easily.
Teams using TeamCity in the cloud should be able to complete their builds as quickly as they would if they were using local installations. Persistent cloud caches will allow cloud build agents to transfer build dependencies such as Maven artifacts and NPM packages to one another, saving you time and networking costs.
Additionally, needing 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.
Following the recent release of terminal access to AWS EC2-based build agents, we’re planning to provide users with the ability to launch an interactive browser-based shell directly from the TeamCity UI. Users will be able to open the Linux shell or Windows PowerShell via the TeamCity agent. Our goal is to make this feature agent-agnostic, meaning that it will be supported on premises and in any type of cloud.
TeamCity already allows you to transfer build artifacts from local storage to Amazon S3 and move artifacts between different S3-compatible storages. The next improvement that the team is working on is the ability to migrate artifacts between different S3 buckets instantaneously, copying the files within Amazon from one bucket to another. This will significantly increase the transfer speed.
We recently released a new credential management system – AWS Connection – that provides TeamCity’s build features and cloud integrations with temporary AWS security credentials that only have the rights needed to do a specific job. Our next step is to implement support for AWS Connection within all the plugins available in TeamCity. This will take the burden of manually configuring access to EC2, ECR, S3, and other resources off your team’s shoulders.
More and more of our customers are willing to run build agents in the cloud because it lets them quickly increase the capacity of their delivery pipelines when needed. To support users migrating to Microsoft Azure, we are planning to improve and bundle the TeamCity Azure plugin.
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.
With TeamCity’s image builder, you will be able to build custom VM images of TeamCity build agents for various environments. This will help to speed up your builds using pre-baked VCS repositories, build dependencies, Docker images, and so on.
Developers all over the world love TeamCity’s tight integrations with build tools and external services, and we take great care to provide them with the best possible support. Below is a list of the new integration features that we are planning to add.
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 Apps also have the benefit of accessing GitHub under their own credentials with granular permissions assigned by the user, and they can subscribe to various hooks from GitHub.
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 tedious and time consuming. We are working on improving this experience by allowing administrators to install one webhook on the GitHub organization level and use it for all repositories in the project.
TeamCity already offers the ability to integrate with JetBrains Space. We want to further simplify and enhance this integration by adding the ability to connect to Space right from within the TeamCity UI (a Connect to Space button). Similarly, users will be able to connect to TeamCity directly from the Space UI.
We’re also aiming to allow TeamCity to publish build statuses to the Space merge request timeline so that you can always access up-to-date information about the status of your builds right from within Space.
Currently, the Pull Requests build feature extends branch specifications of a VCS root to include branches of open pull requests that match certain filtering criteria.
We want to extend this functionality so that you can automatically trigger builds for a subset of pull requests while also being able to trigger builds for other branches manually.
This feature will allow you to to configure a connection (for example, to GitHub) at the project level. You’ll be able to indicate whether you need TeamCity to collect any pull requests and issue tracker information directly within the connection settings, and you’ll be able to indicate which build configurations must publish statuses.
This feature will save you significant amounts of time, as you’ll be able to configure the settings at the project level once and for all.
OAuth tokens issued via Connections are stored in an internal TeamCity token storage. Currently, they are extracted from the storage when certain settings (for example, a VCS root or a build feature) are configured via the admin UI.
We want to introduce a UI for token management. This allow you to check your token usage and scopes, in addition to:
We want to introduce the ability to add Bitbucket Server as a connection in the Project Settings and allow you to configure VCS roots via such connections. This way, the Bitbucket Server connection will act like other OAuth connections: It will allow you to issue tokens via this connection when you configure credentials.
You’ll also be able to configure the Commit Status Publisher and Pull Requests build features for Bitbucket Server.
Large companies love TeamCity’s ability to scale to thousands of build agents and tens of thousands of projects. However, at some point, adding new projects stops being fun and becomes a necessary burden that you have to repeat for every new endeavor.
TeamCity combines the capabilities and versatility that no other CI tool has. No wonder it’s one of the most popular CI solutions used in game development. We are starting to explore the contributions it can make in this industry in three main areas:
Interested in using TeamCity to build your games? We welcome you to sign up here to participate in our research.
TeamCity offers native integration with Perforce Helix Core, one of the most commonly used version control systems in game development. Here’s what we have planned for the Perforce support.
Running multiple TeamCity nodes and making them work together can elevate your CI/CD to a whole new level of performance and reliability. We’re improving how TeamCity works in a clustered environment by implementing new features for multi-node setups.
Continuous integration is at the heart of the development process and is critical to maintaining a workflow that minimizes the risk of exposing data to third parties or falling victim to cyber attacks. In addition to our continuous work on security-related improvements in the product, we’re going to introduce the following features:
This feature allows TeamCity to fetch the value of a parameter located in an external parameter storage right before running a build. You can go to TeamCity’s Parameters UI and add a parameter referencing the external one. This feature will come in handy for teams that store parameters in an external storage like AWS Parameter Store, HashiCorp Vault, Azure App Configuration, Azure Key Vault, etc.
Thanks to the expressiveness of the Kotlin DSL, our users are really getting into storing their CI/CD configurations as code. We want to improve this feature, and these are the main changes that we have planned for the near future.
Using the Kotlin DSL allows more experienced TeamCity users to reuse build configuration settings more naturally, saving teams time and effort. Since the Kotlin DSL is statically typed, using it in an IDE also makes discovering available APIs much simpler.
At the same time, we understand that knowledge of Kotlin or the need to work with a specific IDE shouldn’t be an obstacle to configuring pipelines in TeamCity. That’s why we’re researching ways to simplify the user experience and make working with TeamCity even easier.
To simplify editing Kotlin files in non-IDEs code editors, we’re going to remove the necessity to explicitly specify DSL-related package imports in .kt files. Imports will be handled on the TeamCity server side automatically.
This will allow you to compile code in any code editor. TeamCity will ensure that it actually works.
While the Kotlin DSL provides you with the ability to configure pipelines exactly how you need them to run, smaller projects might not need all the complexity that the Kotlin DSL entails. In this regard, we’re going to simplify basic DSL for smaller projects so you can easily copy-paste examples of DSL code from the documentation. This will help speed up the configuration process dramatically.
We’re working on improving the Kotlin DSL API documentation. The updated documentation will provide clear examples of Kotlin DSL snippets that you’ll be able to copy and paste in your pipeline configuration.
This will help your team to save time when writing the Kotlin DSL configuration for your projects.
We want to allow you to manage your Server and Agent licenses transparently and flexibly via JetBrains Account. We further want TeamCity to be able to pick up those licenses in real time, without having to generate and download offline license keys.
We are planning to:
Podman is a "daemonless” container engine that doesn’t require root privileges to manage containers, and it is command-compatible with Docker. When both Podman and Docker are available on the agent, TeamCity offers a build and agent configuration parameter for choosing the preferred engine for the Docker wrapper.
Improved TeamCity analytics will provide teams with granular insights into server metrics, allowing for better capacity planning and management. Project metrics will help CI engineers monitor build processes and identify anomalies or points for further improvements. Build traces will help teams visualize build stages by exporting TeamCity pipeline data to external analytic systems.
We’re planning to add a new feature that will allow TeamCity to take a set of parameters and run a build for each combination of them – Matrix builds. This feature is especially useful when you need to run the same build or test in various environments, for example, different operating systems, Java/.NET versions, different browsers, and so on.
Matrix builds will significantly reduce time and effort, allowing you to establish one set of specified parameters (for example, OS and environment) once and then run the same set in parallel on other build configurations.
We're going to make it possible to save a history of deployed builds.
Thanks to this new functionality, you’ll be able to check the current state of all deployments, such as which version is deployed on prod and which one is deployed on staging.
You’ll also be able to access deployment history reports on all instances. On the deployment dashboard, you will find a list of instances, their current states (In progress, Success, Failed) and relevant build details (timing, agent, who triggered the build, etc.)
Because developers use their CI/CD solutions every day, we want TeamCity to feel like home.
As of version 2022.10, the Sakura UI is default in TeamCity. We’re now working on moving towards full feature parity between the Classic and Sakura UIs. To do so, we will reimplement pages from the Classic UI and polish the plugin subsystem to integrate plugin tabs in the Sakura UI.
TeamCity is a powerful CI/CD system with a great number of advanced features. To help users familiarize themselves with TeamCity and configure the software exactly how they want it to run, we’re going to provide onboarding guides within the solution. The interactive guides and hints will teach newcomers how to use TeamCity effectively and help established customers migrate from the Classic to the Sakura UI.
We are working to improve performance for the bigger TeamCity installations. Our primary focus is on agents and the project pages. Our goal is to decrease the time to first byte, cumulative layout shift, and time to interactive metrics, as well as other web vitals. TeamCity users can expect to have application pages render and load faster in all browsers.
We recognize how important it is for engineers to feel comfortable with the tools that they use for work every day. In this regard, the dark theme is one of the most requested TeamCity features. We’re working on implementing it in both the Classic UI and the Sakura UI.
TeamCity Pipelines is our codename for the major project we plan to undertake once we’ve finished implementing the Sakura UI as the default UI option.
With TeamCity Pipelines, our plan is to shift our focus from individual steps of the process of automating builds and tests to the overall experience of setting up delivery pipelines. TeamCity Pipelines will provide a simple and intuitive experience for building CI/CD pipelines, powered by the signature intelligence of JetBrains products.
The brand new visual pipeline editor in TeamCity Pipelines makes working with CI/CD pipelines of any complexity simple, powered by TeamCity’s CI/CD engine, which can handle enterprise-level workloads. The intelligent configuration assistance built into TeamCity Pipelines will guide you through all of the steps of pipeline configuration and automatically suggest optimizations along the way.
You can sign up for early access here.
We want our users to be able to develop without the hassle of installing and maintaining build infrastructure. To this end, we provide TeamCity Cloud – a fully managed CI/CD solution that is completely hosted and managed by JetBrains. It has the same functionality as the on-premises version, with the exception of several administrative features that are not needed in the cloud installation.
While everything we develop appears in both the on-premises and cloud versions of the product, TeamCity Cloud has a number of additional features on its own roadmap: