Pipelines 101: Common Concepts and Settings
This section outlines the main enhancements and differences Pipelines exhibit compared to the classic TeamCity UI, and explains core concepts and terms.
Common Terms
In Pipelines, any CI/CD routine consists of three logical blocks:
Step — a simple build action an agent performs, such as testing a Maven solution, executing a CLI script, or building a Gradle project. Steps are not standalone entities and always have parent Jobs.
Job — a sequence of consecutively executed Steps. These are "build configurations" in classic TeamCity terminology.
Pipeline — a sequence of Jobs executed either consecutively or in parallel. Jobs united in a Pipeline can share output files. Multi-Job Pipelines are counterparts to classic TeamCity "build chains".
Supported VCS and Project Types
Supported version control systems:
GitHub
Supported project types:
Gradle
Maven
NodeJS
Custom Command-Line Scripts
Initial Setup
When you navigate to the Pipelines tab for the first time, TeamCity asks you to approve the OAuth access to GitHub. TeamCity uses this authorization method to scan for repositories in your personal account, as well as repositories of your organization(s). You can create Pipelines only for these found repositories.
You can revoke TeamCity’s access to GitHub at any time. To do this, visit the Settings | Applications | Authorized OAuth Apps page.
YAML Configuration
TeamCity stores all Pipeline, Job, and Step settings in an .yml file. You can click Preview YAML button in the top right corner to browse this file.
A YAML configuration file allows you to quickly view, validate, and share the hierarchy of your Pipeline with all of its Jobs, Steps, and individual settings. We are currently working on making this file editable, so that settings you add in a YAML configuration are reflected in the web UI.
Reusing Builds
If you run a Pipeline whose underlying VCS repository did not change since the last successful build, TeamCity will use those last successfully built Jobs instead of re-running them. This technique optimizes builds and allows TeamCity to skip builds whose results are already known.

In future releases, we intend to add Job settings that will allow you to force TeamCity do a fresh Job run even if there are no changes.