--- title: "Build Dependencies and Snapshot Dependencies" url: "https://courses.osherove.com/courses/tdd-and-bdd-in-ruby/build-dependencies-and-snapshot-dependencies.md" canonical: "https://courses.osherove.com/courses/tdd-and-bdd-in-ruby/build-dependencies-and-snapshot-dependencies/" tags: [] author: "Roy Osherove" description: "Lesson 15 of 16 in TDD and BDD in Ruby (Day 5 - Continuous Delivery), 9:41. 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/" --- # Build Dependencies and Snapshot Dependencies 1. [Courses](https://courses.osherove.com/#courses) 2. [TDD and BDD in Ruby](https://courses.osherove.com/courses/tdd-and-bdd-in-ruby/) 3. Day 5 - Continuous Delivery Lesson 15 of 16 Duration: 9:41 [Watch on YouTube](https://www.youtube.com/watch?v=pCBxpyuEjSg) Lastly, we will add dependencies between build configurations and make sure all builds use the same source and artifacts. This is the most important part about creating a build chain: making the build faster and source correct across the chain. ## In this lesson Roy Osherove adds a slower build configuration in TeamCity that has no source control settings of its own and takes the files of the [continuous integration](https://pipelinedriven.org/article/2015/5/15/time-to-main-measuring-continuous-integration "Time to Main - Measuring Continuous Integration (pipelinedriven.org)") build as artifacts. He explains that artifact dependencies copy files while snapshot dependencies tie both builds to the same version of the source, so the artifacts should come from the same build chain rather than from the last successful build, which could be a month old and lead to deploying an old version of the product. He also advises copying only the artifacts that the next builds need, because more artifacts make the build slower. ## Transcript 1,176 words [\[00:02\]](https://www.youtube.com/watch?v=pCBxpyuEjSg&t=2s) Okay, so we have a [continuous integration](https://osherove.com/blog/2010/1/14/the-difference-between-continuous-integration-tools-and-auto.html "The difference between continuous Integration tools and automated build tools (osherove.com)") 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 TeamCity 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=pCBxpyuEjSg&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 rake run integration [\[01:07\]](https://www.youtube.com/watch?v=pCBxpyuEjSg&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 you might say slow. Because I don't care what's inside. [\[01:38\]](https://www.youtube.com/watch?v=pCBxpyuEjSg&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. What we 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=pCBxpyuEjSg&t=129s) Now in the dependencies I can use artifact dependencies to get physical artifacts like files and I will can use snapshot 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=pCBxpyuEjSg&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 is 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=pCBxpyuEjSg&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. 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=pCBxpyuEjSg&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=pCBxpyuEjSg&t=264s) But now in my slower build in my dependencies I can say give me just the rake file for example. 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. TeamCity 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=pCBxpyuEjSg&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 I remove that. [\[05:31\]](https://www.youtube.com/watch?v=pCBxpyuEjSg&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? will actually deploy the old version of the product. [\[06:04\]](https://www.youtube.com/watch?v=pCBxpyuEjSg&t=364s) Okay. So instead we put a snapshot dependency and we make this. You see it's even smart enough to say oh last 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:37\]](https://www.youtube.com/watch?v=pCBxpyuEjSg&t=397s) 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 path specified. There is no slow.rake. [\[07:25\]](https://www.youtube.com/watch?v=pCBxpyuEjSg&t=445s) Paste. I'm just going to run the cube from our stuff and I want to push to the GitHub. And now I should be able to detect the change automatically. You see one change pending. [\[07:55\]](https://www.youtube.com/watch?v=pCBxpyuEjSg&t=475s) This build should start in a second. Oh, this started first. It's even telling me 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. If I look at the artifacts now, I should see a slow.rake. [\[08:31\]](https://www.youtube.com/watch?v=pCBxpyuEjSg&t=511s) 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. Actually, hide this. This 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=pCBxpyuEjSg&t=543s) Okay. Now, do pay attention. The more artifacts you have, the slower this will take. So, 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 to get everything. Okay. Okay. So what I want to do now is to actually build either a deploy or [integration test](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_25 "Integration tests (The Art of Unit Testing, 3rd ed., ch. 1)") that uses the artifacts and uses a natural dependency from CI. [\[09:35\]](https://www.youtube.com/watch?v=pCBxpyuEjSg&t=575s) Okay. ## Related - [Build Pattern: Cumulative Build](https://osherove.com/blog/2013/2/7/build-pattern-adopt-artifacts.html) · osherove.com Roy's Cumulative Build pattern: each build configuration in a chain does one thing and shares its artifacts with the next, the chain this lesson sets up in TeamCity. - [Build Bullet #5– How to make your builds FAST using DRY and SRP Principles](https://osherove.com/blog/2012/12/6/build-bullet-5ndash-how-to-make-your-builds-fast-using-dry-a.html) · osherove.com Roy's post on making a chain of builds faster with DRY and single-responsibility build configurations, which pass artifacts on instead of repeating work. ### Also linked in this lesson #### The Art of Unit Testing, 3rd ed. - [Integration tests](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_25), ch. 1 #### osherove.com - [The difference between continuous Integration tools and automated build tools](https://osherove.com/blog/2010/1/14/the-difference-between-continuous-integration-tools-and-auto.html) #### pipelinedriven.org - [Time to Main - Measuring Continuous Integration](https://pipelinedriven.org/article/2015/5/15/time-to-main-measuring-continuous-integration) [Previous lesson Continuous Delivery with TeamCity](https://courses.osherove.com/courses/tdd-and-bdd-in-ruby/continuous-delivery-with-teamcity/) [Next lesson Summary](https://courses.osherove.com/courses/tdd-and-bdd-in-ruby/summary/) --- ## 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/