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 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.
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.
Starting from version 2018.2, TeamCity now automatically generates DSL code for all your settings and lets you preview it in the admin UI.
With parameters you can generalize version control settings, template or build configuration, making them reusable and easily customizable.
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.
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.
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.