We want continuous integration to be a regular part of every developer’s life. To support more workflows and make the experience with TeamCity smoother, we now support authentication using external services: GitHub, GitLab, and Bitbucket.
TeamCity 2020.2 will instantly match external OAuth accounts with existing TeamCity users, and let them work with their projects without having to enter a password. It integrates with user directory features of the supported services, such as GitHub organizations and GitLab groups, and can automatically create new profiles when new members join your team.
In addition to cloud services, TeamCity 2020.2 supports on-premise installations of GitHub (GitHub Enterprise) and GitLab (GitLab self-hosted).
Version 2020.2 extends the integration with Bitbucket Cloud by adding support for pull requests. Now you can set up TeamCity to automatically pick up pull requests made in your Bitbucket Cloud repository and run the respective builds. Together with the Commit Status Publisher and the Automatic Merge features, this creates an amazing combination, making it possible to work with your favorite tools most efficiently.
As Python becomes the second most popular programming language in the world, you want your continuous integration system to support all of its modern features and development practices. This is why we created the all-new Python build runner, which enables you to use the power and intelligence of TeamCity in your Python projects. The new build runner works with all operating systems, supports virtual environments, and integrates with all common testing frameworks and code inspection tools for Python.
The results of your Python builds and tests are reported in the TeamCity UI, in the same way as with all other TeamCity build runners. You can track changes, analyze failures, assign investigations, and use all the other TeamCity features that you know and love.
JetBrains Space has been added to the list of services supported by the Commit Status Publisher feature. Until now, to check that your changes didn’t break anything, you had to open up TeamCity and search for your build results there. With the new integration, Commit Status Publisher will automatically send the status of your builds to Space, letting you see it on the Commits page of your project.
Do your CI/CD pipelines rely on external services, tying up your build agents as they wait for external jobs to finish? Or even worse, do they run in AWS or another cloud, and not only waste your time but also burn your money? Then you’re going to love agentless build steps in TeamCity 2020.2. Your builds can now execute their final steps in agentless mode, releasing the build agents and allowing them to run other queued tasks. TeamCity displays agentless build steps as standard builds and will enable you to track their status, browse their logs, and view their history.
Our large customers are building more than ever with TeamCity, so we continue to push our multi-server capabilities forward. In version 2020.2, secondary servers make a big step towards primary servers, allowing you to edit project-level settings. This enables your team to set up new builds while the primary server is under maintenance.
An increasing number of our users prefer storing artifacts in the cloud – for example, in Amazon S3. Starting with 2020.2, TeamCity will show you the disk space occupied by builds not only on your local drives but also in remote locations.
The clean-up feature just got more powerful. Now you can customize its schedule with the use of cron-like expressions to have the server cleanup start at regular intervals – for example, on weekends, or twice a day.
Our incredible UI team has been working hard to bring more features and support more use cases in the experimental “Sakura” UI. TeamCity 2020.2 comes with many great things designed not only for end-users but also for plugin developers.
One of the essential parts of working with CI/CD is the ability to understand the big picture of how everything is built, and TeamCity 2020.2 brings two significant improvements in this area to the Build Dependencies page:
TeamCity 2020.2 adds one more missing piece to the Sakura UI: the new Test History page. The new page gives you detailed information on your tests and allows you to analyze trends, see investigation history, and more.
We have implemented one of the most popular requests from our users: the build log search. It is now much easier to browse the build log, debug your setup, and understand what happens during your builds.
TeamCity has always provided extension points and allowed developers to build on its functionality. Starting with version 2020.2, we offer a new way to write and integrate plugins for the user interface. To learn more, check out this talk from TeamCity Technology Day .
The new Build Queue page is stylish, works very fast, and makes it easy to find everything you need. It lets you quickly see the changes for every queued build, understand what triggered the build and where it will run, get the estimated time when it will start, and view all the other build information in a neat and convenient UI. You can select any builds that you don’t need and remove them from the queue, or alternatively, if there are builds that need to complete sooner, you can move them to the top of the list.
These are just some of the ways we're strengthening TeamCity. For the full list of changes in version 2020.2, please see the TeamCity documentation.
Have you ever wanted to execute different command line scripts on different platforms, or deploy changes in different branches to different staging servers? Now you're free to do just about anything! TeamCity 2020.1 allows you to specify conditions for your build steps and execute them only if the criteria are met.
Simple and reproducible cluster deployments are now available out of the box. TeamCity 2020.1 lets you implement a scalable CI/CD architecture on top of Kubernetes: build agents can be launched automatically when you need them, do their job, and then be removed after the build is completed.
Running multiple TeamCity servers and making them work together can elevate your CI/CD to a whole new level of performance and reliability. We have improved how TeamCity works in a clustering environment by extending the capabilities of secondary servers with trigger processing and support for user-level actions in the UI.
Professionals working with large installations have hundreds if not thousands of triggers that fire on changes in VCS, package updates, and new artifacts. To help them achieve the highest possible performance, we now allow secondary servers to take part in this process and take some load off the primary server.
We have improved the UI of the secondary server, making it possible to modify user profiles, change view of projects and configurations, manage build agents, and more.
TeamCity 2020.1 comes with a new option to download a pre-packaged agent distribution from the TeamCity server. Pre-packaged build agents don’t need to update themselves upon connection to the TeamCity server, and this makes creating and updating cloud images faster and more straightforward.
To take TeamCity’s notification capabilities to new heights, we’ve implemented a new build feature that allows project administrators to set up automatic alerts to the entire team. New notifications can be configured on the build configuration level, so you can edit, reuse, and share them using the Kotlin DSL.
The all-new Slack notifier lets your team get notifications about the status of your builds directly in Slack.
TeamCity has always had 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 have extended the integration and started to send the status of your builds and deployments to Jira Software Cloud. Now you can look into your CI/CD pipelines and release history right in your issue tracker, and see which issues are associated with failing builds.
We have extended the list of Git hosting services supported by the Pull Requests build feature, and added support for the Azure DevOps pull requests. The new option allows you to automatically run builds on pull request branches of the Azure DevOps, similarly to how you can do it with GitHub and GitLab.
Most developers use CI/CD every day, and we want it to feel like home. That’s why 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.
To support more use cases of the classic TeamCity, the experimental UI of version 2020.1 comes with updated Agents and Projects pages, and allows configuring the project sidebar.
For the full list of changes in version 2020.1, see the TeamCity documentation.
TeamCity 2019.2 opens new dimensions of control over the historical data and artifacts created by your builds. A reworked clean-up engine allows you to set up different clean-up policies with a wide spectrum of filters: for example, you may choose to keep all builds from specific branches, or with specific tags.
We believe that new clean-up rules will be particularly useful for companies that have a lot of projects, and for teams that use feature branches during development.
Pros love tools that help them monitor how mission-critical systems are behaving and performing. Starting with 2019.2, TeamCity exposes its metrics via an HTTP endpoint, so they can be scraped by Prometheus and then visualized via the Prometheus web interface, or in a Grafana dashboard.
The metrics include the server performance information, as well as various details on agents, projects, and build configurations.
For many large organizations, a high-performance CI is critical to their workflows. TeamCity takes another step toward a multi-node setup allowing you to add builds to the build queue, manage build problems and investigations, and perform other user-level actions – now on a secondary server.
Developers often open TeamCity many times a day, which is why we want it to be a place where they can quickly find what they need, regardless of the size and complexity of their projects. Following the TeamCity UI roadmap, we are introducing a new build page that gives you an easy way to browse build history, investigate problems, and discover any misconfigurations or bottlenecks in your build chains.
Check out the experimental UI – we're proud of how it now looks and feels.
We want TeamCity to have everything you need in a modern workflow. Version 2019.2 adds support for EC2 launch templates, and lets you run cloud build agents using the launch parameters from your AWS account. With the launch templates, updating and installing new software on build agents becomes a very simple and straightforward task – you no longer need to change anything in the TeamCity project configuration.
Goodbye clicking, hello scripting. The Kotlin DSL now provides a simple and very straightforward syntax for defining build chains. Set up sequential and parallel builds, configure failure conditions and dependencies – and store everything as code.
Project configuration just got easier. Starting with 2019.2, your Kotlin DSL configurations may include custom parameters, which you can define later when importing the project in the UI.
For the full list of changes in version 2019.2, see the TeamCity documentation.