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 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 support them in the best possible way. 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 are 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 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.
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 to organize your development process in a more efficient way.
We’re continuing our quest to create a user interface that will be fast, easy to use, and 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 supervised by JetBrains. It has a number of additional features on its own roadmap.
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.)
We believe that every development team should have full visibility into their delivery pipelines. To improve the setup and debugging experience of cloud CI/CD, we are planning to give users the ability to open a secure terminal session directly from TeamCity – without the need to access the cloud provider’s management console or ask a busy DevOps team to set up network access lists and SSH key-pairs.
TeamCity already allows you to transfer build artifacts from local storage to Amazon S3. This enables teams to migrate from on-premises installations to the cloud. Next we will implement other migration scenarios, such as moving artifacts between different S3-compatible storages, consolidating different projects into a single S3 bucket, or separating projects by moving their artifacts to different S3 buckets.
We are working on a new credential management system that will be responsible for providing TeamCity’s build features and cloud integrations with temporary AWS security credentials that provide just enough rights to do the job. With this system, you will no longer have to configure access to EC2, ECR, S3 and other resources manually, and you will have an easy way to change and set up automated rotation of static AWS credentials.
We’re seeing a trend of cloud-native teams moving from traditional VMs and containers to various forms of serverless technology. To support their build scenarios, we are looking into potential integrations of TeamCity with AWS Lambda:
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.
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.
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.
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.
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 their organization.
A traditional approach to continuous integration involves collecting changes from a version control system, running the build, and then notifying you about the result. But what if you could trigger pipelines and receive notifications directly from your IDE? Are there any other ways to integrate with an IDE that can make the development process faster and more enjoyable? This is something that we want to explore in the near future.
If you know any great scenarios where the integration of TeamCity and an IDE could improve your experience, please share them by creating an issue in our YouTrack.
Meta-runners in TeamCity provide an easy way to create build configurations without configuring every build runner from scratch. One of the best things about them is that they can be shared and re-used by different TeamCity installations that need to run similar build scenarios. To make the experience of setting up CI/CD pipelines easier and faster, we are planning to create a library of meta-runners and provide an easy way to find, download and share them.
TeamCity combines the capabilities and versatility that no other CI has – no wonder it’s one of the most popular CI solutions used in game development. We are starting to explore this industry in two main areas:
Interested in using TeamCity to build your games? We welcome you to sign up for the research here.
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.
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:
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.
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.
To improve this experience, we are planning to add the ability to create new TeamCity projects by simply committing the respective .teamcity configuration to a repository – without having to interact with the user interface.
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 help us shape our plans by suggesting feature requests related to deployment in our YouTrack project.
For greater control over your CI, we are planning to introduce the concept of matrix builds which will allow you to run multiple similar builds with minor differences and then combine their results in one comprehensive report.
CI/CD is one of the tools that most developers use every day, and we want it to feel like home.
Sakura UI has almost reached feature parity with the classic UI, and now we’re mostly focused on improving its performance. In the next release, we are planning to make it the default for new installations – stay tuned!
Now that Sakura UI is getting ready to replace the classic UI, where do we go next? To answer this question, we want to introduce a project with the codename TeamCity Pipelines.
TeamCity was always designed as a general-purpose solution that allows all sorts of development practices and doesn’t enforce any specific workflow. While this approach always worked great, it also brought a certain bias to the way we develop the user interface. When your goal is to make sure that every user can find all the information and has all the tools they need to do the job, you naturally start paying more attention to individual pages of the product, rather than thinking about end-to-end experiences.
With TeamCity Pipelines, our plan is to shift focus from individual steps of automating builds and tests to the overall experience of setting up delivery pipelines.
We want our users to be able to develop without the pain of installing and maintaining build infrastructure. To this end, we provide TeamCity Cloud – a fully managed CI/CD solution that is completely hosted and supervised 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: