---
title: "TeamCity Artifacts and Snapshots"
url: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/teamcity-artifacts-and-snapshots.md"
canonical: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/teamcity-artifacts-and-snapshots/"
tags: []
author: "Roy Osherove"
description: "Lesson 17 of 17 in Beautiful Builds and Continuous Delivery Patterns (TeamCity Demos), 9:22. Free video by Roy Osherove."
usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)."
license: "https://creativecommons.org/licenses/by/4.0/"
---

# TeamCity Artifacts and Snapshots

1. [Courses](https://courses.osherove.com/#courses)
2. [Beautiful Builds and Continuous Delivery Patterns](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/)
3. TeamCity Demos

Lesson 17 of 17

Duration: 9:22 [Watch on YouTube](https://www.youtube.com/watch?v=fBHqX51MDX8)

## In this lesson

Roy Osherove adds a slower integration build in TeamCity that has no VCS settings and gets its files as artifacts from the CI build, whose artifact paths he sets first. He explains that artifact dependencies get files while snapshot dependencies tie builds to the same source control version, and shows TeamCity warning when artifacts come from the same chain or the last successful build without a matching snapshot dependency. Without a snapshot dependency, the last successful build could deploy an old version of the product. With both dependencies, running the slower build first queues CI, which is skipped when it is already on the latest version, and he advises getting only the artifacts that are needed.

## Transcript

1,162 words

[\[00:02\]](https://www.youtube.com/watch?v=fBHqX51MDX8&t=2s) Okay, so we have a continuous integration working. What I want to do now is to show you how I can set up artifact dependencies and snapshot dependent dependencies between build configurations in Team CD and what's the difference and how important that difference really is. So first thing I want to do is let's say I want to create another integration build or a deploy build and I want both builds to have the same version of the source. So in that case what I'm going to do is I'm going to create a new build configuration. I'm going to say let's say I'm going to call it deploy.

[\[00:36\]](https://www.youtube.com/watch?v=fBHqX51MDX8&t=36s) And in deploy let's call it configuration for now. Integration or slower build. In the VCS settings I don't need any VCS settings. I'm just going to use the files from artifacts. So the build runner that I want is an rake run integration

[\[01:07\]](https://www.youtube.com/watch?v=fBHqX51MDX8&t=67s) Run cucumber let's say and the path to the rake file might be the current source and I would just say let's say cucumber.rake. Okay. Or I might say slow.rake because I don't care what's inside.

[\[01:38\]](https://www.youtube.com/watch?v=fBHqX51MDX8&t=98s) Okay. Do I need anything? I need RSpec. No, I need cucumber. I don't know what I'm going to need. I'm going to save it like this. Will be cleaned. Okay, that's good. All project related data. That's okay. Don't worry about that. That's from a previous project that I was working with. So now I have the slower build, but I want to get the artifacts from let's say CI in here. So I go to the edit settings in the dependencies.

[\[02:09\]](https://www.youtube.com/watch?v=fBHqX51MDX8&t=129s) Now in the dependencies I can use artifact dependencies to get physical artifacts like files and I will can use snap dependencies to make a link on the version of the source control. So this one just gets files. This one makes sure that the files will be from the right version. So let's start with artifact dependencies. I can get an artifact dependency. I can get all the files from tests CI.

[\[02:43\]](https://www.youtube.com/watch?v=fBHqX51MDX8&t=163s) I can choose the last successful build or I can say from the same build chain. The same build chain is what usually you would want because that means that if someone checked in a file that's newer into source control by the time CI has already run and your build is about to start, it will trigger CI again to make sure that it gets the latest version. and runs the test on the latest version. So it cannot allow for this file for this configuration and the CI configuration to run on different versions of the source

[\[03:20\]](https://www.youtube.com/watch?v=fBHqX51MDX8&t=200s) When you build from the same chain. Now what are the artifact rules? Well, I just want to have everything for now. But I can choose to have I can click here and you can see that there are no artifacts currently from test one CI and the reason is that I haven't run CI with artifacts yet. So I can edit settings for CI and here artifact paths. Well, I should have something.

[\[03:52\]](https://www.youtube.com/watch?v=fBHqX51MDX8&t=232s) I can say everything.zip or I can say everything.rb. Oh, I haven't run it yet with this. Let's run it. We should get some artifacts here at some point. Okay, now I have artifacts. These are the artifacts from the build. You can see there are the spec files here. There's Sinatra files. And I usually you don't want everything. You want most of it or half of it. Just the files that you will need in the in the next builds.

[\[04:24\]](https://www.youtube.com/watch?v=fBHqX51MDX8&t=264s) But now in my slower build in my dependencies I can say give me just the rake file for example. So it's very nice. It's very use usable usability friendly but I'm just going to get everything for now. Now here's the thing. Team CD is smart enough to say you got from the same chain but you don't have a corresponding snapshot dependency.

[\[04:57\]](https://www.youtube.com/watch?v=fBHqX51MDX8&t=297s) So he's telling me dude there is no link between the versions of these two builds. So I have to add add a link. I want this build to depend on CI and only use artifacts when it's a successful build. Now it will work. Now what if I said here not from the same chain but just the last successful build when I have this configured and I don't have a snapshot dependency if I remove that

[\[05:31\]](https://www.youtube.com/watch?v=fBHqX51MDX8&t=331s) When I have something like this configured what happens could be very risky if you have multiple projects and they depend on each other because it could be that the CI build last successor build a month ago and from that moment on it failed but my integration build will just continue on and as if nothing happened we'll just use the artifacts from that what's the point it will actually deploy the old version of the product okay

[\[06:06\]](https://www.youtube.com/watch?v=fBHqX51MDX8&t=366s) So instead we put a snapshot dependency and we make this you see it's even smart enough to say oh less successful build, there's a problem. You have snapshot dependency, but you're using the last successful build. Instead, you should change it to build the chain. Now, the build chain will be the same across these two build configurations.

[\[06:36\]](https://www.youtube.com/watch?v=fBHqX51MDX8&t=396s) Now, what that means is when I run slower build, the first thing it does is you see it queued up the CI. Now CI is already on the latest version. So it's going to skip that. Next thing it does is try to get the build files. Cannot find build file by path specified. There is no slow.rake.

[\[07:16\]](https://www.youtube.com/watch?v=fBHqX51MDX8&t=436s) And I'm just going to put everything here and paste. I'm just going to run the cube from our stuff and I want to push to the GitHub.

[\[07:49\]](https://www.youtube.com/watch?v=fBHqX51MDX8&t=469s) And now I should be able to detect a change automatically. You see one change pending. This build should start in a second. Oh, it started first. It's even telling you these things. Okay, this one is running. You see if I try to run this one, it will wait until this build will fail or pass before it runs.

[\[08:23\]](https://www.youtube.com/watch?v=fBHqX51MDX8&t=503s) If I look at the artifacts now, I should see a slow.rake. You see it's running the tests. And I didn't use source control here at all. I'm just getting the artifacts from CI to here. I can actually hide this, I guess. configure visible projects. That's okay. So that's how you create a link and get the artifacts from one one version to the other.

[\[09:03\]](https://www.youtube.com/watch?v=fBHqX51MDX8&t=543s) Okay. Now, do pay attention. The more artifacts you have, the slower this will take. So you usually just want to get some of the artifacts. So be kind to the file system etc. It does take a lot when you have a lot of files in source control to move them around either way. So you don't have to get everything. This was just for demo purposes

## Related

- [How to make your builds FAST using DRY and SRP Principles](https://pipelinedriven.org/article/2014/3/2/how-to-make-your-builds-fast-using-dry-and-srp-principles) · pipelinedriven.org

    Roy on sharing artifacts between build configurations so each build does one thing on the previous build's output.

- [Build Pattern: Cumulative Build](https://osherove.com/blog/2013/2/7/build-pattern-adopt-artifacts.html) · osherove.com

    Roy's Cumulative Build pattern, the artifact chain this TeamCity demo sets up.

[Previous lesson TeamCity CI and Artifacts](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/teamcity-ci-and-artifacts/) [Last lesson Back to the course overview](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/)


---

## About the author

**Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery.

### Sites

- [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership.
- [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts.
- [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin.
- [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model.
- [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps.
- [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes).

### Social

- X: https://x.com/royosherove
- LinkedIn: https://www.linkedin.com/in/osherove/

### Contact

- Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7

### License

Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/
