CONTINUOUS DELIVERY SIMPLY EXPLAINED

Continuous Delivery is a simple idea. In practice it takes a lot to make it work, but let’s focus on the simplicity - what is Continuous Delivery made simple? In this easy introduction to Continuous Delivery we explore the basic ideas in a way that will help you to deepen your understanding of its importance and value, even if you already understand it.

These days most organisations that develop software aspire to achieve Continuous Delivery. This is the state of the art DevOps approach to software development but it is more complex than it sounds. How do we deliver valuable software repeatably and reliably into the hands of our users?

In this episode see Continuous Delivery explained by Dave Farley as he explores the fundamentals in a way that helps us to understand the real value in this advanced approach to software development, this engineering-for-software.

--------------------------------------------------------------------------------------

🎓 CD TRAINING COURSES 🎓

📚 BOOKS:

📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.

📖 "Continuous Delivery Pipelines" by Dave Farley

📖 The original award-winning "Continuous Delivery" book by Dave Farley and Jez Humble

📧 JOIN CD MAIL LIST 📧
Keep up to date with the latest discussions, free "How To..." guides, events and online courses.

--------------------------------------------------------------------------------------

[bradleysaulteaux]

He looks like a prophetic dream, peaceful vision, guardian angel.

[TokyoXtreme]

Each one of your videos has a few bits of subtle humor that is definitely noticed and appreciated — kind of a scavenger hunt to find the jokes buried within.

[andrealaforgia]

Great video (as usual). Dave, may I suggest that you improve the sound quality and remove some reverberation in the room? Are you far from the mic? In case, you should wear a lavalier mic.

[jakedill]

Have you tried turning the tree sideways?

Feel like all you'd need to do is uproot it with say a backhoe or till or dodge neon, then if you hire a team of hvac specialists to build a small air delivery system from the adjacent building to carefully blow the dirt away from the root structure (you could skip this but risk bonding integredy and other surface contamination issues that may present later).

After that its a simple job of fireing the hvac crew, then hireing a subset of skilled powerlifters and a cable making facility, have them calculate the weight of the tree ect... then construct a cable that you can probably still source from oversees anyhow if you hit a good window after new years ect... just make sure you have targets samples of both from large orders and cancel the contract right after*. After that have the power lifters go to the home depot and purchase a wench system with at least a reasonable assembly guide, (see discription for any other tasks at HD for efficency, though couldnt see why you couldent just make each trip individually cause then you can expense out lunch after).

After that, just have the power lifters construct the wench and use the dodge neon and any spare vehicles nearby as a counterwieght as you raise the tree up the building side and thus... sideways!

Your Halfway there!

Lol gonna stop now... not kidding though seems like this happens all too often and usually for several reasons all mixed together in a basic principle that eventually systems are so disconnected that at some point in the chain, you just don't give a shit... (oversimplified true, but I am trying to stick under 3 pages these days per post)...

The inverse though is micromanagment and we all know that engineers never have had issues usuall... oh...

nvm.

[zoltannemeth]

My pregnant wife was horrified when I mentioned “Continuous Delivery” in a conversation about my job.

[MrXperx]

I do continuous delivery very well, continuous delivery of untested code that is.

[MichalMarcinkowski]

Are there exceptions to "always in a releasable state"? What if something takes longer? Like rewriting portions for optimization?

[biggydx]

13:44
In the video game industry, would this be synonymous to "milestones"?

[ajmeyer]

Conceptually I like the CD/CI method but the environment where I work doesn't have any automated testing capabilities. There are no test suites run on any code, it is all tested by the developers initially in the development environment, then moved to a TEST environment and then after more manual testing it is finally moved to production and more deployment day tests are manually run.

They tried to get into Visual Studio and DevOps as the source code repository but the developers fought back on that and are back to editing code in the development environment (Linux) using text line editors. (UGHH!!)
When they are finished with their change they create a "delivery" that then bundles up the changes and delivers it to the DevOps as a branch. It is all so messy.

Prior to that the only difference was that they used a different tool to manage access to the code where developers "checked out" the code and nobody else could modify that file until they were done. This could take multiple days at a minimum.

[davidkepke]

Great video. I'm only 3/4ths of the way through it, but there is one aspect of human psychology that has manifested into the Continuous Delivery methodology, and that is since it is so easy to push out new versions and fix problems, short-cuts are taken, and bad code is sent out when it shouldn't be, more often that it should. When CEO's, or business pressures push too hard for product delivery, teams feel that pressure, and probably move too fast.

On another subject, could you do (or have you done) a video on companies that make changes to software that aren't really needed, just because they feel they have to put their own mark on the product? Like Musk says, "The best part is no part" so "the best change is often no change." If it ain't broke, don't fix it.

[_TeaMaster]

Let's say we are working on a very nontrivial piece of software that requires months if not years worth of time to get to the first releasable candidate. Do we just consider it's constituents as separate development processes we can continuously iterate on and 'release' them internally?

[joeygarcia]

If it is simply explained, why does it still take 17 minutes to explain it?