Build Configuration Dependencies
Real-life CI/CD pipelines often combine multiple standalone stages. For example, "Build", "Test", and "Deploy to Staging" configurations (or jobs) can run independently or in sequence.
TeamCity offers multiple options to create relations between these standalone entities.
- Build Chain
A build chain is a collection of classic TeamCity configurations interconnected using snapshot dependencies.
Snapshot dependencies are right-to-left relations. For example, in the "A -> B" chain where configuration "B" has a dependency on configuration "A", "B" cannot run until "A" produces a suitable build first. The criteria for "suitable" builds depends on your setup, see the Suitable Builds section for more information. At the same time, "A" can run independently without triggering new "B" builds.
For mission-critical scenarios, you can set up dependent configurations to always force fresh upstream configuration builds, even if there were no recent changes to the project.
- Pipeline
A simplified alternative to build chains with jobs representing each phase of a process. This is a recommended option for smaller, less complicated workflows (around 10 to 15 phases in the entire routine).
Compared to build configurations linked in a build chain, pipelines showcase the following differences:
You can only link jobs that belong to the same pipeline. Build chains, in turn, allow you to link build configurations owned by completely separate TeamCity projects.
Standalone artifact and snapshot dependencies that require manual configuration are not available. When you choose a job that should precede your current job, you can instantly select whether all of its artifacts should be imported.
A pipeline runs all of its jobs regardless of their dependencies. A build chain has more customization options and can be executed partially.
- Finish Build Triggers
Finish build triggers establish left-to-right relations. For example, you can create a similar "A -> B" sequence similar to a build chain, but with one key difference: "B" can run independently, while each new "A" build automatically triggers a new "B" build.
Finish build triggers offer a simple but inflexible way to trigger downstream builds and can often be replaced or complemented by snapshot dependencies.
- Artifact Dependencies
Artifact dependencies allow configurations to import files produced during other configurations' builds. For example, a "Delivery" configuration can deploy files (Docker images, NuGet packages, HTML documentation pages, and so on) produced by a "Build" configuration to a designated resource.
Artifact dependencies do not create explicit links between configurations: both can run independently without triggering each other’s builds. If you use artifact dependencies without corresponding snapshot dependencies, a dependent build has no ability to ensure a suitable source of artifacts (an upstream configuration build) exists. For that reason, you may want to set up artifact dependencies to target pinned/tagged builds.
This section focuses on build chains and artifact dependencies. To learn more about other options, see the following articles instead: