TeamCity

## A different composition model Most CI tools let you write a pipeline as an ordered list of stages inside one file. TeamCity's unit is the **build configuration**: a first-class object with its own history, parameters, triggers, artifacts and agent requirements. A pipeline is therefore not a list — it is a graph of build configurations linked by dependencies, and TeamCity calls that graph a **build chain**. Triggering the tip of the chain triggers everything it depends on. Two kinds of edges build that graph, and confusing them is the single most common TeamCity misunderstanding. ## Snapshot dependency: ordering plus one revision A snapshot dependency from `Deploy` to `Build` means two things at once: 1. **Ordering.** `Deploy` will not start until `Build` finishes. 2. **Revision consistency.** Every build in the chain runs against the *same* snapshot of the VCS sources. If three commits land while the chain is running, the downstream builds still use the revision the chain started from, not the newest head. That second property is the reason snapshot dependencies exist. Without it, a chain of five configurations could each check out a slightly different commit, and the artifacts you deploy would not correspond to the sources you tested. Revision consistency also enables **reuse**: if a suitable finished build already exists for that exact snapshot, with the same parameters, TeamCity can attach it to the new chain instead of rebuilding. That is what makes chains cheap in a monorepo where most of the graph is unchanged. Snapshot dependencies also carry failure behaviour. You choose what happens when the upstream build fails or is cancelled — typically the dependent build does not start at all, and the whole chain is marked failed: ```kotlin dependencies { dependency(Build) { snapshot { onDependencyFailure = FailureAction.FAIL_TO_START onDependencyCancel = FailureAction.CANCEL } artifacts { artifactRules = "+:target/*.jar => libs" } } } ``` ## Artifact dependency: files, not ordering An artifact dependency is about **bytes**. Before the dependent build's steps run, TeamCity downloads files published by the source build into the dependent build's checkout directory, according to artifact rules. A rule has the form `+:<source pattern> => <target directory>`, with `-:` to exclude; archives can be unpacked by referencing a path inside them. Crucially, an artifact dependency does **not** by itself say which build to take the files from. It is resolved by a rule — the last finished build, the last successful or pinned build, a build with a given tag, or *the build from the same chain*. The last option is the one you want in a pipeline, and it only exists meaningfully when a snapshot dependency ties the two configurations into one chain. ## The failure this produces The realistic incident looks like this. A `Deploy` configuration has an artifact dependency on `Build`, taking the last successful build's JAR, but no snapshot dependency. Someone triggers `Deploy` to ship the fix they just merged. Meanwhile a later commit has already produced a newer successful `Build`. `Deploy` happily takes *that* JAR. Nothing errors; the deployed binary is simply not the change anyone thought they were shipping, and the chain shows green. The fix is to add the snapshot dependency so the pair forms a chain and the artifacts resolve to that chain's build. The symmetrical mistake is a snapshot dependency with no artifact dependency: the ordering is right, the revision is right, and the downstream build then rebuilds the module from source because nothing handed it the binary. It works, it is slow, and it quietly abandons the build-once discipline — the thing you deploy is not the thing you tested. ## Composite builds and chain shape Because each node is a real configuration, chains fan out naturally: one `Build` with several test configurations depending on it, and a single downstream node depending on all of them. TeamCity also offers a **composite** build configuration — one that runs no steps and occupies no agent, existing purely to aggregate the status of its dependencies into a single green or red result you can trigger, watch, or attach a status check to. ## What to say in an interview Name the two edges, state that snapshot is ordering *and* revision consistency while artifact is file transfer, note that they are orthogonal and usually declared together, and give the failure mode: an artifact dependency without a snapshot dependency resolves to some other build's output. If you can add that revision consistency is what makes build reuse safe, you have covered the model.