Configuration
Good software developers don’t like code duplication; similarly, good build engineers don’t like duplication of settings. TeamCity understands this and provides several ways to reuse settings.
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.
TeamCity DSL 10.0
Create projects and build configurations programmatically, as code, based on 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.
Templates
You can create a template with the common (shared) settings, and then inherit any number of build configurations from this template.
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.
Parameters
With parameters you can generalize version control settings, template or build configuration, making them reusable and easily customizable.
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.
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.
