Confidence Waves

[00:03] (external link, opens in new tab) Hey everybody, Roy here with another small installment about continuous beautiful builds. This time I want to talk about triggers and waves of confidence (external link, opens in new tab). And if you're interested in finding out more, just go to beautifulbuilds.com. So, one of the main points I want to talk about is how to get faster feedback. Faster feedback is not just about knowing that your code works, but also one mistake that a lot of people do with their automated builds (external link, opens in new tab) and continuous integration (external link, opens in new tab)

[00:37] (external link, opens in new tab) Is that they allow developers to wait too long before they can continue to write code again. So developers, one of the points of build is to gather confidence that you can that your code actually works. But how long do you have to wait? Consider this example. What if I have a continuous integration build that compiles, run unit tests and integration tests and the whole thing takes 30 minutes.

[01:07] (external link, opens in new tab) So that means that every time I check in, I have to wait 30 minutes to be able to know that my code works. And in those 30 minutes, it doesn't. as far as I'm concerned, it either works or it doesn't and I have to wait for the end of the build or at least the CI build and then I might have deployed a test and acceptance and staging and all that stuff. And so you can see in the chart below is that if my confidence is measured from 0 to 100, I have to wait 15 or even 30 minutes to actually feel like I can start coding again.

[01:45] (external link, opens in new tab) And that's just a big waste of time. One way to break up that time is to is to break up the pieces of the build so that you can get what I call waves of confidence. So waves of confidence means that I would like to have enough confidence to start coding again and then gradually get more and more confidence from the build. And that's one of the reasons that I like to break build configurations into smaller steps. And then as each step is finished, I know that I can do something that I couldn't do before.

[02:21] (external link, opens in new tab) For example, in this case, the time to code is only 2 to 5 minutes to start coding again because the the 10 build, the CI build only compiles and runs the unit test and we the 20 build only runs the integration tests. It might take 25 minutes, but at least after 5 minutes, I can go back to coding. And then 25 minutes later, I'll feel even more confident and more confident until maybe an hour later, I might feel fully confident that everything works in all the environments.

[02:57] (external link, opens in new tab) But I don't waste time just waiting for the build. Instead of having either zero or one that the code works, I have a grayscale where the code is working in terms of unit test and then the code is working in terms of integration test and then the code is working here and there and each one of them gives me one more I want to say nail in the coffin but that's a negative one more rose in the rose garden. Okay, kind of weird. It's late. it's late in the

[03:29] (external link, opens in new tab) And that's kind of the point is that I want developers to be able to get back to coding quickly and the best way to achieve that is to have automated triggers between builds. So assuming that we've we've triggered we've created these build configurations we can then add triggers or a build chain trigger. So, this is an example from a real project that I was in. It's just the first couple of weeks.

[04:01] (external link, opens in new tab) And again, you might have seen it from the previous videos that I've done. But in this case, I don't even have an integration test. I only have a CI that runs unit tests. I only have 13 unit tests and I have deployed a test. But these two are triggered automatically. the the trigger is usually a part of the continuous integration server. A continuous integration server should allow you to orchestrate the structure and the order of the build configurations so that they run in the correct order and that they run automatically when you need them.

[04:38] (external link, opens in new tab) In this case, I want the CI to be triggered every time I check in code, every time I commit code. and I want the deploy to test to get triggered automatically when the CI build finishes. So those are two different types of triggers and here are the types of triggers that you can have that you would usually have. You can trigger that build configuration to run on a specific time of day or every hour or every or every 12 hours etc.

[05:10] (external link, opens in new tab) You can trigger a build configuration when another build has finished so that they run in a specific order. You can trigger a build when someone checks in code. And then you can even trigger it via API request via a specific tool that you have. And also there's a special trigger that a lot of people are not aware of especially in TeamCity. there is a retry trigger especially when you have integration tests that have a lot of complicated stuff and sometimes they pass only on the second run etc.

[05:45] (external link, opens in new tab) You can add a retry trigger to try three times if it fails the first time. And so that saves you a lot of work of going and remembering to click on buttons to run something. This should all be happening automatically for you and you should get notified. And we'll do a whole video just about notification, how to tell something is working, build visualization. But for now, I just wanted you to know that the these triggers are one a core concept that allows continuous delivery (external link, opens in new tab) to happen automatically and continuously.

[06:25] (external link, opens in new tab) So, as always, if you want more information, just contact me on Twitter or just go to beautifulbuilds.com and I'll cover some more stuff in future videos. Cheers.