Pipelines 101: Common Concepts

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 shell 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

TeamCity Pipelines supports any project that can be built locally using Shell commands. In addition, Pipelines feature a few specialized runners tailored to interact with the specific building tools:

• Gradle

• Maven

• NodeJS

• Unity (available upon request)

These specialized runners provide quick access to advanced build tool settings: optional command-line arguments, tool version, JVM arguments, and so on.

Initial Setup

When you open TeamCity Pipelines 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 new projects only for these found repositories.

You can revoke TeamCity’s access to GitHub at any time. To do this, open your GitHub account settings and navigate to the Applications | Authorized OAuth Apps page.

YAML Configuration

TeamCity can display all Pipeline, Job, and Step settings as a YAML markup. When editing a Pipeline, use the Visual/YAML toggle switch between editing modes.

A YAML configuration file allows you to quickly view, validate, edit, and share settings of your building routine. The syntax editor highlights keywords and shows compilation errors.

Optimization

TeamCity Pipelines employ a number of smart features that allow builds to avoid wasting precious time and resources on performing repeated actions. For example, if your Jobs are organized in a single "Job A → Job B" chain and "Job A" detects no new pending changes, "Job B" can reuse the last successful "Job A" build instead of triggering it anew.

See this article for more information: Pipeline Optimization.