To empower developers to create great software without the pain of installing and maintaining build infrastructure, we have recently released TeamCity Cloud – a fully managed CI/CD solution that is completely hosted and supervised by JetBrains.
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.
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.
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.
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.
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.
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 is a managed version of TeamCity that is hosted by JetBrains. It has the same functionality as the on-premises version, except for several administrative features that are not needed in the cloud installation.
While everything we develop appears in both versions, TeamCity Cloud has a number of additional features on its own roadmap:
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 clustered environment by extending the capabilities of multinode setups with new features.
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 build dependencies such as Maven artifacts and NPM packages to one another, saving time and networking costs.
(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.)
More and more of our customers are moving their CI to the cloud because it lets them quickly increase the capacity of their delivery pipelines when needed. To improve the migration experience, we are working on a new feature that will allow transferring build artifacts, logs, and other data from local hard disk to cloud storage locations, such as Amazon S3.
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.
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:
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 will always be able to find the correct way to configure your VCS roots, clean-up settings, or entire projects as Kotlin code.
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 branched project settings.
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.
Our company has recently introduced a new product, Space – an all-in-one solution for software projects and teams. Space provides many opportunities for integration with TeamCity, such as sending notifications to chats, generating to-do list items, syncing with a team directory, inheriting project permissions, and others. We are working closely with the Space team to figure out the most useful ways to integrate the two products, and the next stop on the roadmap is authentication via Space.
Recently we have added the Kotlin script build runner that allows launching scripts written in Kotlin. To provide even more flexibility in configuration, we want to create the new C# script build runner that will allow you to specify build steps in C#, will be cross-platform, and will also support NuGet packages.
We are extending the list of authentication modules supported by TeamCity, and we’re adding support for Azure DevOps. The new option will allow you to log in to TeamCity using your Azure DevOps account, very similarly to how you would with GitHub, GitLab, or Bitbucket Cloud.
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.
Among all the different version control systems, Perforce takes a special place in TeamCity, as it is the de facto standard for CI/CD in many industries. We are exploring ways to add support for Perforce Swarm and integrate it with Pull Requests, Commit Status Publisher, and other TeamCity features.
If you have any feature requests and know important use cases that are not covered by the current integration of TeamCity and Perforce, please share them in our YouTrack project.
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 a tedious and time-consuming task. We are working on improving this experience by allowing administrators to install one webhook on the root level, and use it in all projects in your organization.
We are exploring ways to add new continuous deployment features to TeamCity. Here are some main areas we are looking into:
Your opinion is welcome! Please don’t hesitate to suggest feature requests in this area in our YouTrack project.
Continuous integration stands at the heart of the development process, and it is critical to maintain a workflow that minimizes the risk of exposing data to third parties or falling victim to cyber attacks. To improve the security of your CI/CD, we are working on a number of new features:
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.
CI/CD is one of the tools that most developers use every day, and we want it to feel like home. Our new experimental “Sakura” UI has really proven itself over the past two years – it is fast, powerful, and modern, and we’re proud of where it stands after such a short time.
Right now the Sakura UI has almost reached feature parity with the classic UI, and in one of the nearest releases we are planning to make it the default. But before this happens, you can expect improvements in the following areas:
Some of the features that we announced earlier were postponed or removed from the roadmap as we introduced new functionality that rendered them obsolete.