Lesson 5 of 17

Cumulative Builds

Duration: 4:52 Watch on YouTube (external link, opens in new tab)

Markdown version

In this lesson

Roy Osherove explains that builds get slow when each stage, from CI to deploying to test, staging and production, checks out and compiles the code again, which also means the deployed code is not the code that was tested. In the cumulative builds pattern (external link, opens in new tab), the CI build publishes its compiled binaries as artifacts, a feature of CI servers (external link, opens in new tab) such as TeamCity, and each deploy build takes the artifacts of the previous one instead of compiling again. In his example the whole chain takes just under 4 minutes, and he notes that artifacts are almost impossible to configure in TFS but supported by TeamCity and Jenkins.

Transcript

791 words

[00:02] (external link, opens in new tab) Hey everybody, Roy Osherove again. This time I want to talk about slow builds and how to fix that problem. You see slow builds, they say it happens to everyone and I too used to have slow builds. But here's how I solved it. First, we have to understand that a slow build happens usually because we pick we repeat the same actions over and over again and sometimes we add more actions on top the closest we come to a deployment to production for example. For example here,

[00:32] (external link, opens in new tab) You'll see that we have a continuous integra- continuous integration that checks out, compiles, runs unit tests. But then if I want to deploy the test or staging and prod, what I used to do is that I would just repeat the same things and then also add deployment on top of it. And of course, that is a huge waste of time and it also creates a problem because you see the code that you compile on the CI build is different than the code that you compile here and here. You could say, "Well, it's exactly the same." But you don't know that and that's kind of the point.

[01:05] (external link, opens in new tab) I what I would like is that the code that got compiled here will be deployed here and here and here. That's not what's happening and I get a big waste of time repeating myself in all these directions. So what do we do? Well, one of the things that a lot of people don't realize is that advanced continuous integration services such as TeamCity also possess a feature called artifacts and artifacts can help us make our builds much faster and also solve that problem where

[01:41] (external link, opens in new tab) We actually have different versions of the files being compiled at each stage. And I call this pattern cumulative builds (external link, opens in new tab). The idea is that you create this piece of source and then you do all the actions on the existing piece of source that you already have and that's your artifact. And you move an artifact between builds and you keep doing more and more things on it. So, here's an example of how we can use artifacts. For example,

[02:12] (external link, opens in new tab) I should stop saying example. A cumulative build in this case would be where the CI build after it compiles etc., I can configure it to publish artifacts. And those artifacts could be all the binary files that were compiled and were going and and were being tested. And then after I would publish these artifacts, I would configure the deploy to test build to extract artifacts from the CI build and put it in the local directory before it runs.

[02:51] (external link, opens in new tab) And then all the things that I had to do before like checkout code and compile and all that stuff, I don't have to do anymore. All I have to do is just to take those artifacts and deploy them somewhere which makes my build much faster. Then I also publish these artifacts so that other builds can consume them. So, in this build I will consume the artifacts from the deploy to test and from here I will consume the artifacts from deploy to staging. And this brings about a very nice phenomenon. First, yes of course things are fast.

[03:21] (external link, opens in new tab) Second, I know that the things that were passing the tests here are the things that are being deployed here in production. And that's a very important thing. Only do everything just once. Don't repeat yourself. Applies to builds as well as to code. Just just how fast? Well, it because we're doing just one thing here, checkout compile unit test and then here none of all those other things, it only takes 34 seconds and then 1 minute, 1 minute, 1 minute.

[03:52] (external link, opens in new tab) That means that if I wanted to go through the whole thing, it takes me 4 minutes. Just about shy of 4 minutes to deploy my application after running everything. And if I were to repeat myself, that would be at least a minute and a half longer to do the same thing. And I wouldn't be trusting the build to provide the same results. Because each environment compiles something maybe just a little bit differently. We never know.

[04:22] (external link, opens in new tab) We never never know. So, I hope that this gave you a little bit of knowledge about how artifacts are useful. Unfortunately, it's very it's almost impossible to configure artifacts with things like TFS, etc. So, things like TeamCity, Jenkins are a bit more equipped for those kinds of things. And they have been for a few good years now. So, I highly recommend that you look at the idea of artifacts before moving for- forward with continuous integration. Cheers.