What's the point of Continuous Delivery?

[00:02] (external link, opens in new tab) To me, continuous delivery (external link, opens in new tab) is is a combination of automated builds (external link, opens in new tab) and continuous integration (external link, opens in new tab) to the point of delivering things all the way to the customer. So, in a beautiful delivery chain, I should be able to see all the way that the code makes from being written and to the customer, and I should be able to see it in a visual way and in an automated way, and I should be able to to to get notifications and visual and visual cues on what's really going on.

[00:36] (external link, opens in new tab) But, when I was doing all that at at one of my projects, you know, I was all having fun and setting up TeamCity and all these cool things. I really in as I said, I had the product owner ask me, "Why the hell are you doing all this? Everything is going just fine. What's the problem here? It's not like there was a big problem you were trying to solve." And I thought about it for a for for a long time because I didn't have a good answer. Because at the beginning, I thought, "Well, why am I doing this? Am I just playing with technology with for technology's sake?

[01:09] (external link, opens in new tab) Is it just me that likes to automate things, but the product owner is happy, so what's the point?" And I thought about it more and more, and I and I ended up with this answer. And the answer started with a question. And the question was, "What if I told you if you could only compile your code every 3 weeks? Right? You could write code for 3 weeks long, but you wouldn't know how well it fared towards the compiler in reality." so, you would write the code, and on the third and the and the and the last day of the third week, you'd get a compilation.

[01:46] (external link, opens in new tab) And then you'd see all the stuff that went wrong, and then you'd have 3 more weeks to fix everything, and also to add new features, etc. etc. etc. That would be horrible, wouldn't it? But that's exactly what we have solved with having continuous compilation (external link, opens in new tab). Today we have continuous compilation. We write code and we almost immediately know whether it lives up to the standards of the compiler or it doesn't. Whether it faces reality or it doesn't. Okay, so that's one one feedback mechanism that we can get very fast.

[02:20] (external link, opens in new tab) What about the next feedback mechanism? What about tests? What if I told you you could only run tests once every 3 weeks, right? Even the unit tests, all the automated stuff, you would only get to run them once every 3 weeks. How would that feel? And unfortunately, some teams today even still do have that problem. But a lot of teams would say, "What? Are you kidding me? 3 weeks to run all the unit tests? I I would need to run them every day, every time I need to change the code." Because that would be horrible to write code for 3 weeks and not get feedback that what you're doing not just compiles, but actually runs and does what it's supposed to do.

[02:58] (external link, opens in new tab) So today, luckily for us and because of the work of many many people in the open source movements, we have continuous testing. We have the ability to run tests continuously and get feedback as quickly as possible so that we don't end up working on the wrong thing for a long time. But what's the next meta level after that? What if we could only deploy to the customer machine once every 3 weeks, which is exactly what we are facing these days in a lot of teams?

[03:30] (external link, opens in new tab) Deployment is the next stage of feedback. We could be working for 3 weeks on the wrong thing. Yes, it would might compile, it might run as we stated it that it should run, but when the customer sees it, does it actually run on the customer's machine? Does the customer actually want what they just got? We don't know until we actually get the customer to take a look. And so, if we have to wait 3 weeks, that's 3 weeks we could be working on the wrong thing or in the wrong direction.

[04:01] (external link, opens in new tab) So, continuous deployment is the process of measuring the code that we wrote against the harsh reality, which is the customer. Without actually having the customer see our code, the more we are risking working on the wrong thing. And this is where continuous delivery tries to help. When I have a continuous delivery, we're trying to get continuous feedback from the customer instead of just quick enough feedback or fast feedback. We're trying to get almost immediate feedback.

[04:34] (external link, opens in new tab) That at least we can deploy to the customer's machine, that all the security concerns have been met, that performance is still working the way it should have worked. And just imagine having a branch, a big branch that you've been working on for 3 months now, and it's not on the main branch, and you haven't deployed it. You're working, and every day that goes by, you're farther and farther away from reality, and you don't even know whether what you what you're doing is better or worse.

[05:04] (external link, opens in new tab) And when you finally merge that branch, it's going to be a big bang merge. It's going to be difficult to actually get all the feedback. And the biggest scare for a lot of developers, I think even inherently without even knowing it, is that they might be working on the wrong thing. And a lot of developers end up not having any motivation to work in the code. They're just doing the simplest thing that could possibly work so they could just get it over with because they are working in a bubble. They don't get feedback. They're just working for the sake of working instead of getting feedback that their actions actually affect somebody else.

[05:41] (external link, opens in new tab) And working in a bubble is the most horrible thing. Yes, it seems like fun at the beginning, but at some point you just disconnected. You might as well go home after 3 hours or 2 hours. You might as well just play Tetris all day. Because if you don't get that feedback, what's it What does it all actually mean? So, hopefully with that happy thought, I hope I've explained a little bit about what continuous delivery actually means.