In 2023, we introduced a number of highly anticipated features to TeamCity. The long-awaited dark theme is now available in both TeamCity Cloud and On-Premises. We’ve also introduced agent terminals that allow users to open remote terminals on agent machines directly from the TeamCity UI.
The Matrix Build feature in TeamCity now allows you to define a combination of parameters and corresponding values to create a matrix of build configurations. The Build Cache feature provides the ability to store files and share them between builds.
In this blog post, we’d like to shed some light on what we’re currently working on for TeamCity and what you can expect in the first half of 2024.
🚀 TeamCity Pipelines
TeamCity Pipelines is a new product that greatly simplifies the CI/CD process. The brand new visual pipeline editor provides a simple UI for working with CI/CD pipelines of any complexity. With TeamCity Pipelines, you can create, view, and modify your pipelines in one place and on a single page.
We’re releasing the Beta version on March 18, 2024 – sign up for early access today!
☁️ TeamCity Cloud
A lot is happening within TeamCity Cloud! Here’s a quick overview of what we’re currently working on.
Options for smaller teams
We’re working on introducing new options tailored to smaller teams as part of our product roadmap. Our ultimate goal is to introduce a completely free plan for TeamCity Cloud that many developers and smaller teams will benefit from.
TeamCity Cloud on AWS Marketplace
TeamCity Cloud will soon be available for purchase on AWS Marketplace, providing users with more flexibility in accessing and utilizing our services.
TeamCity On-Premises will also become available on AWS Marketplace in the near future.
Docker Registry and other package storages
As part of our commitment to meeting user needs, we’re exploring the possibility of integrating Docker Registry and other storages like Maven Repository and npm Registry into our offerings. If this feature is of interest to you, please let us know via this contact form.
Per-minute macOS build agents
We’re going to introduce per-minute macOS build agents to TeamCity Cloud. In addition to Windows, Linux, and ARM agents that are already available, you’ll also be able to run your builds on macOS.
We’re going to offer Intel-based and Apple Silicon M1 build agents, providing teams building for iOS with greater flexibility, scalability, and cost-effectiveness.
🌤️ TeamCity Cloud Integrations
Out-of-the-box Microsoft Azure support
Our customers are increasingly 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.
Executor mode
We would like to support a common scheduler like Kubernetes, HashiCorp Nomad, or AWS ECS in order to run simple build tasks without the requirement to specify and maintain a build agent.
This will allow you to start setting up project build configurations without thinking about what workers will run your builds.
This approach will be handy for small and simple tasks that do not require local caches of VCS roots, dependencies, and similar elements. It will also increase resource utilization using schedulers. The schedulers can run multiple tasks in parallel on the same cluster node out of the box.
Build agent image builder
With TeamCity’s image builder, you’ll be able to build custom VM images of TeamCity build agents for various environments. This will speed up your builds using pre-configured VCS repositories, build dependencies, Docker images, and so on.
Learn more and vote for this feature
⛓️ VCS integrations
GitHub Checks support
(being actively developed)
TeamCity is gearing up to integrate GitHub Checks functionality, allowing users to specify and report on the checks to be executed within TeamCity for a specific repository. GitHub will subsequently trigger these checks for new commits and pull requests, and users can manually re-run them as needed.
With this update, TeamCity will provide detailed check results, including granular information like failing tests. Additionally, we are exploring the possibility of implementing code annotation, supported by GitHub Checks.
Token management
(being actively developed)
TeamCity already uses expiring third-party tokens provided via OAuth or similar connections by VCS hosting services such as GitHub, GitLab, Bitbucket Cloud, Bitbucket Server/Data Center, and Azure DevOps.
Our upcoming plan is to enhance transparency, enabling users to effortlessly re-issue or reuse existing tokens. Users will also have the flexibility to permit or prohibit token usage in specific TeamCity projects. Furthermore, we aim to make searching for and issuing tokens for use in Kotlin DSL settings easier.
Untrusted PR builds
(likely to be released soon)
This new suite of features will be especially important for those users who run builds on their public repositories, such as ones used for open source projects. TeamCity will be able to:
- Detect builds running on less trusted sources (e.g. coming from a fork of a public repo).
- Provide users with a pre-approval functionality for such builds.
- Detect build configurations that could potentially trigger such builds automatically.
PR-driven build triggering
(being actively developed)
Currently, the Pull Requests build feature can be configured to internally extend the branch specification for a VCS root to include any pull/merge request branches within it. Some filters can be applied, for example, to make it so a build can only “see” pull requests targeted at a certain branch. This is not always an optimal solution, as sometimes users want to see all branches, but only automatically trigger certain ones.
That’s why we are introducing an extension to branch filters that will allow users to filter branches by pull request attributes.
More expressive regexp-like branch filter syntax
(in design)
We’ve planned another improvement to branch filters – an alternative richer regexp-like syntax. This will allow users to maintain elaborate branch name conventions for their projects.
Simpler configuration of VCS hosting integrations
(in development)
Simplifying the user experience and making TeamCity features more discoverable are our main priorities. To do so for VCS hosting integrations, such as build status publishing and pull/merge request integration, we’re going to:
- Suggest creating relevant build and project features when a project is created from a connection.
- Consolidate as many of these integrations as practical on the TeamCity project level, with specific menu items appearing in the admin UI when such integrations are configured. For example, the GitHub menu item will appear if a project is created via a GitHub connection, and the respective admin UI page will allow you to control all GitHub-specific integrations within the project.
Custom Git LFS and submodule credentials
(likely to be released soon)
In some larger projects, users need to provide different credentials for a Git LFS storage or Git repository that stores submodules other than the ones used for the main repo. TeamCity will soon be able to support this functionality for TeamCity projects.
Agent-specific Git mirrors support
(likely to be released soon)
Sometimes with large Git repositories, it makes sense to keep a separate mirror closer to where TeamCity agents are hosted to improve performance. We’re planning to provide this functionality on an agent-by-agent basis.
Better support for SSH URLs for VCS roots created from connections
(being actively developed)
Currently, if a project, build configuration, or VCS root is created via a connection, TeamCity always uses an HTTPS-based fetch URL. Many users prefer to use SSH-based URLs, so TeamCity will support this. It will also allow users to upload a new SSH key or select one of the keys already accessible within the project.
💪 General TeamCity improvements
JetBrains Account login and the new license format
We want to allow you to manage your Server and Agent licenses transparently and flexibly via your JetBrains Account. We’re planning to simplify license management for TeamCity On-Premises customers by allowing them to manage their Server and Build Agent licenses through their JetBrains Account portal without having to generate and download with numerous offline license keys.
Making the path to Kotlin DSL in versioned settings repositories configurable
Currently, the Kotlin DSL doesn’t allow users to store settings for several projects in the same repository. Our goal is to provide more flexibility by allowing users to customize this configuration path according to their needs.
Learn more and vote for the feature
Option to run a build if the artifact dependency failed to download
Currently in TeamCity, snapshot dependencies offer the option to run a build even if the dependency has failed.
We’re going to introduce similar logic for artifact dependencies. This functionality will be optional, giving users the flexibility to choose whether a failed artifact download blocks the entire build process or not.
Learn more and vote for this feature.
Speeding up server startup times on large installations
This TeamCity improvement, aimed at enhancing performance, focuses on optimizing the server startup time for large installations.
Our goal is to reduce the time it takes for the TeamCity server to initialize and become operational in environments with extensive configurations or substantial data, ensuring a more efficient and responsive experience for users managing sizable installations.
Commit all configuration changes to a Git repository
The idea behind this feature is to commit and push every change (both project-related and global) to a specified Git repository. This repository can then be used to share configuration files between TeamCity nodes in multi-node setups.
This repository can also be used as an audit of all changes made to the TeamCity settings through the UI, Rest API, or versioned settings.
Standalone build log service
In a multi-node setup, all nodes work with build log files stored in a shared data directory. Most of the time, one node “owns” the log file corresponding to a certain build. This node writes to the file while other nodes can only read it.
If a TeamCity node decides that the node that “owns” the log file crashed, but it is actually working normally, another node might start writing to the same log file and corrupt it.
We’d like to implement a standalone build log service that can be accessed by HTTPS from every node. The new approach will help us to eliminate the possibility of log files being corrupted as a result of two nodes writing to the same file.
Execute a dependency based on specific conditions
We’re working on the capability to execute a dependency in TeamCity based on a specified condition. This would allow users to set conditions for executing dependencies, providing more flexibility and control over the build process.
Learn more and vote for this feature
🔐 Security improvements
Stronger passwords in TeamCity
We’re working on a feature that will enable administrators to customize password security policies, defining criteria such as length and the inclusion of special characters and numbers. If a user attempts to log in with a password that doesn’t meet the requirements, TeamCity will require them to create a new password that does.
🏃♀️ Build tool integrations
TeamCity Actions
We’re going to design and implement TeamCity Actions – reusable, shareable packages of build runner configurations that can be used to simplify and streamline CI/CD processes.
Dependency cache in build runners
TeamCity includes a Build Cache feature that allows caching specific directories between agents in a build chain within the artifact storage. However, users currently must manually manage the directories they want to cache.
We aim to simplify this process by automatically including the build system directories for which we offer integration within the cache. This improvement will streamline cache setup for users.
🕹️TeamCity for game development
TeamCity is one of the most popular CI/CD solutions for game development. TeamCity integrates with all major technologies and tools used in modern game development, including Perforce.
In 2024, we’re focusing on improving TeamCity’s Perforce integration and updating the Unity plugin that’s already available on JetBrains Marketplace. We’re also working on a new Unreal Engine plugin that will help game developers seamlessly integrate TeamCity with their video game development tools.
We’re going to add on-the-fly test reporting functionality for the Unreal Engine plugin.
🌸 TeamCity UI
We’re constantly polishing and improving the TeamCity UI so that you feel at home when working with your CI/CD system. Here’s what we’re focusing on in Q1–Q2 2024.
Sakura UI: Problems tab
TeamCity provides an overview of current problems and investigations on both project and build levels. Users can review build configuration errors, failed tests, and problems that are being investigated, as well as check their assignee and status.
We’re reworking the UI to give our users a better overview of all issues and their statuses in a selected project. They can now be found under the common tab – Build Problems.
Client notification center
We’re looking into better ways to notify our customers about TeamCity updates and other important product-related issues. That’s why we’re going to introduce a number of features that will help our customers to stay on top of what’s happening in and with TeamCity.
What’s new notifications
We’re going to introduce in-app notifications that will be displayed right within the TeamCity interface. The information about new releases and other important updates will be easily accessible here for all TeamCity users.
Notification center
There’s a lot going on in TeamCity that might require a user’s attention, from accessing the list of all assigned investigations to staying on top of failed builds. Until now, there was no unified way for TeamCity to notify users of any important changes related to their TeamCity instance.
With this in mind, we’re working on our new Notification Center, which will provide a quick and easy way for users to get updates regarding their account. Here, users will be able to review their assigned investigations and server health summary, among other things.
Users will also be able to configure which types of notifications they’d like to receive.
Health reports: New UI
When numerous server errors occur, TeamCity frequently presents them as extensive health reports that occupy the entire screen. Our goal is to enhance error reporting by making it more concise and compact.
Project administration and build configurations: New UI
We’re updating the project administration and build configuration UIs to be on par with the Sakura UI, the default for TeamCity. Our ultimate goal continues to be reaching feature parity between the Sakura UI and the classic TeamCity UI.
🏗️ TeamCity infrastructure
Design Teamcity-Kubernetes operator
Operators are software extensions within Kubernetes that use custom resources for managing applications and their components. These operators follow Kubernetes principles.
We’re going to design and develop a Kubernetes operator for TeamCity and first adopt it for TeamCity Cloud. The operator will seamlessly integrate into TeamCity, providing out-of-the-box installation for any Kubernetes cluster.
Terraform Provider for TeamCity
We’re introducing the Terraform Provider for TeamCity, which uses a language familiar to DevOps professionals to streamline global server setup, user management, permissions, and project initiation.
Thanks to the Terraform Provider, managing the infrastructure for TeamCity projects has become much easier. We’re releasing the Beta version in Q1 2024 and will continue developing our Terraform Provider this year.
If there’s a feature request that you’d like to submit, don’t hesitate to do so via this form. As always, we’re happy to hear from you.