Configuration
Projects Hierarchy
Projects in TeamCity can be nested inside other projects and thus form a tree.
Settings and permissions defined in the parent project propagate to subprojects, which greatly simplifies maintenance of a large installation.
Configuration as code
Create projects, build configurations, and build chains programmatically, as code, using the Kotlin programming language. Keep this code in a VCS, and all the changes to it will be applied to your build server automatically, without having to interact with the web UI.
To help you write configurations in Kotlin, TeamCity automatically generates DSL code for all your settings and lets you preview it in the admin UI.
Starting with version 2019.2, your Kotlin DSL configurations may include custom parameters, which you need to define in the UI when importing the project or when updating the project settings.
Parameters
With parameters you can generalize version control settings, template or build configuration, making them reusable and easily customizable.
Meta-Runner
Meta-runner is a great way to reuse a set of build tasks, making you feel like this set of tasks is natively supported by TeamCity.
You can create it from existing build steps in several clicks and then reuse in other build configurations.
Build Failure Conditions
You can use a wide spectrum of different conditions for marking a build as failed.
A build can be marked as failed if coverage drops below the specified threshold, or decreases compared to a previous build; if specific text appears in the build log; if artifacts were not published; and in many other cases.
Templates
You can create a template with the common (shared) settings, and then inherit any number of build configurations from this template.
Default and multiple templates
Set up a default build configuration template for a project. Propagate changes to all the build configurations in the project by changing just one template. Attaching a build configuration to multiple templates at a time has also been made possible.
Build Chains and Build Dependencies
By specifying snapshot and artifact dependencies, you can break down a single build procedure into several parts that can be run on different build agents either in sequence or in parallel.
2020.1 Conditional build steps
Do you need to execute different command line scripts on different platforms, or deploy changes in different branches to different staging servers? TeamCity allows you to specify conditions for your build steps and execute them only if the criteria are met.
2020.2 Agentless build steps
Starting with TeamCity 2020.2, build agents that employ external tools are no longer tied up while waiting for remote jobs to finish. Your builds can now execute their final steps in agentless mode, releasing the build agent and allowing it to run other queued tasks.
Composite builds
Composite builds aggregate results from several other builds connected via snapshot dependencies and present them in a single build. See the progress of the whole chain in one place, as well as failed tests, build problem notifications, and artifacts.
Shared Resources
Sometimes resources external to TeamCity cannot be utilised simultaneously by multiple builds.
TeamCity easily handles this by limiting access to your shared resources with just a few clicks in the UI.