Lesson 15 of 16
Build Dependencies and Snapshot Dependencies
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 (external link, opens in new tab) 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
[00:02] (external link, opens in new tab) Okay, so we have a continuous integration (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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 (external link, opens in new tab) that uses the artifacts and uses a natural dependency from CI.