--- title: "What's the point of Continuous Delivery?" url: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/what-s-the-point-of-continuous-delivery.md" canonical: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/what-s-the-point-of-continuous-delivery/" tags: [] author: "Roy Osherove" description: "Lesson 2 of 17 in Beautiful Builds and Continuous Delivery Patterns (Introduction), 6:09. 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/" --- # What's the point of Continuous Delivery? 1. [Courses](https://courses.osherove.com/#courses) 2. [Beautiful Builds and Continuous Delivery Patterns](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/) 3. Introduction Lesson 2 of 17 Duration: 6:09 [Watch on YouTube](https://www.youtube.com/watch?v=8WDPLvRNf6Q) ## In this lesson Roy Osherove describes [continuous delivery](https://pipelinedriven.org/article/continuous-delivery-values "Continuous Delivery Values (pipelinedriven.org)") as [automated builds](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-7#ch07lev1sec1 "Automated builds running automated tests (The Art of Unit Testing, 2nd ed., ch. 7)") and [continuous integration](https://pipelinedriven.org/article/2015/5/15/time-to-main-measuring-continuous-integration "Time to Main - Measuring Continuous Integration (pipelinedriven.org)") carried all the way to the customer, and recalls a product owner asking him why he was setting it all up. His answer compares it to compiling or running tests only once every 3 weeks: [continuous compilation](https://pipelinedriven.org/article/2014/3/2/release-compilation "Release Compilation (pipelinedriven.org)") and continuous testing give fast feedback, and deploying to the customer is the next stage of feedback. Without that feedback, he says, teams risk working on the wrong thing for weeks, long-lived branches end in a big bang merge, and developers lose motivation working in a bubble. ## Transcript 1,080 words [\[00:02\]](https://www.youtube.com/watch?v=8WDPLvRNf6Q&t=2s) To me, [continuous delivery](https://leanpub.com/pipelinedriven "The Holy Grail of Continuous Delivery (pipelinedriven.org)") is is a combination of [automated builds](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-7#ch07lev1sec1 "Automated builds running automated tests (The Art of Unit Testing, 2nd ed., ch. 7)") and [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)") 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\]](https://www.youtube.com/watch?v=8WDPLvRNf6Q&t=36s) 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\]](https://www.youtube.com/watch?v=8WDPLvRNf6Q&t=69s) 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\]](https://www.youtube.com/watch?v=8WDPLvRNf6Q&t=106s) 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](https://osherove.com/blog/2013/4/23/beautiful-builds-release-compilation-step.html "Beautiful Builds: Release Compilation Step (osherove.com)"). 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\]](https://www.youtube.com/watch?v=8WDPLvRNf6Q&t=140s) 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\]](https://www.youtube.com/watch?v=8WDPLvRNf6Q&t=178s) 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\]](https://www.youtube.com/watch?v=8WDPLvRNf6Q&t=210s) 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\]](https://www.youtube.com/watch?v=8WDPLvRNf6Q&t=241s) 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\]](https://www.youtube.com/watch?v=8WDPLvRNf6Q&t=274s) 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\]](https://www.youtube.com/watch?v=8WDPLvRNf6Q&t=304s) 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\]](https://www.youtube.com/watch?v=8WDPLvRNf6Q&t=341s) 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. ## Related - [Release Compilation](https://pipelinedriven.org/article/2014/3/2/release-compilation) · pipelinedriven.org Roy's 'imagine you could only compile once a week' article, the comparison this lesson uses to explain why delivery should be continuous. - [The Holy Grail of Continuous Delivery](https://leanpub.com/pipelinedriven) · pipelinedriven.org Opening section of Roy's Pipeline Driven book on the holy grail of continuous delivery. - [If a Build Takes 4 hours, Run It Every 4 Hours](https://pipelinedriven.org/article/if-builds-take-4-hours-run-them-every-4-hours) · pipelinedriven.org Roy on builds as a feedback bottleneck, and why larger batches between builds make the feedback loop longer. ### Also linked in this lesson #### The Art of Unit Testing, 2nd ed. - [Automated builds running automated tests](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-7#ch07lev1sec1), ch. 7 #### 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) - [Beautiful Builds: Release Compilation Step](https://osherove.com/blog/2013/4/23/beautiful-builds-release-compilation-step.html) #### pipelinedriven.org - [Continuous Delivery Values](https://pipelinedriven.org/article/continuous-delivery-values) - [Time to Main - Measuring Continuous Integration](https://pipelinedriven.org/article/2015/5/15/time-to-main-measuring-continuous-integration) [Previous lesson Separation of Concerns](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/separation-of-concerns/) [Next lesson Shipping Skeleton](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/shipping-skeleton/) --- ## 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/