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.
There is more to this release! For the full list of changes in TeamCity 2020.1, please refer to 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.
TeamCity UI is getting a major overhaul, and here’s a first taste of what you’re going to get in this version.
Not only have we improved the look, but we've also updated the underlying technology stack so now the UI works as a single-page application, which means you can access parts of it faster and all the changes appear instantly. See the TeamCity UI roadmap to stay up to date with all the planned changes.
In 2019.1, we are targeting the pages related to working with projects and build configurations.
You can now access and search all your projects and build configurations via a sidebar. Tag build configurations or whole projects as your favorites, and they will always be available at the top of the list in the sidebar. You can also find extra bits of handy information there, such as new changes, build status, new tests, and running builds.
The new project overview presents you with a dashboard-style view over your build configurations. Each configuration gets its own card which displays a histogram with up to 14 of the latest builds. For each of the builds, you can see the status (green means successful, red is failed), build time, and how long the build has spent in the queue. There is also information about the build that is currently running.
The reworked Branches tab displays your default branch at the top, hiding the rest of the branches in an expandable block underneath. The details of the latest builds in the default branch can now be seen right away which increases the visibility of the important data.
Using GitLab? TeamCity 2019.1 adds full support for GitLab. You can now set up a GitLab connection and create projects in TeamCity with one click, by simply picking a GitLab project from the list.
We’ve also added support for GitLab merge requests, so you can now set TeamCity up to automatically run the build on each merge request and then automerge it if the build is successful.
The Go language is now supported natively by TeamCity. Add your Go projects and TeamCity will detect and report Go tests, providing rich insights into the test status, its history across the builds, and duration, and will mark unstable tests as flaky. With the Test History tab, you can now dig deeper into your Go tests.
In addition to basic HTTP authentication, TeamCity now supports authentication based on permanent access tokens. Tokens are useful for REST API authentication, so that you don’t need to expose a user login and password in scripts.
With this more flexible way of creating Spot Instances, you can now have more granular control over your Spot Fleet. TeamCity 2019.1 lets you submit and edit the spot fleet configuration file and specify the strategy, set the target capacity, and add tags to your instances. It is a more advanced and cost-effective way of running your builds on AWS.
The secondary node now has an additional responsibility: processing the build lifecycle. If you turn it on, the secondary node will handle the build-related tasks, such as running and finishing builds, uploading artifacts, and failure conditions processing. This change expands the already broad list of tasks that you can offload from your main server onto a secondary one: collecting changes, serving as a read-only backup node, and now, processing the build lifecycle.
Tools will now only be loaded onto agents on demand. The necessary tools will be loaded only when the first build requiring them appears. This significantly improves the build agent upgrade times and saves you network traffic.
There is more to this release! Find out about the other new features.