The Difference Between DevOps and Continuous Delivery

[@thatpaulschofield]

DevOps is one of those technical terms that almost immediately was co-opted and suffered "semantic diffusion" ie it was redefined by "me too" professionals in the same way SOA, Agile and microservices were. As I recall, the original concept of DevOps was "pulling operations forward" into the software developers' wheelhouse. Since the modern developer automates what he can, he will also automate the deployment process. Furthermore, since the developer is not "throwing the code over the fence" for Ops to support, they will feel the pain of any lack of monitoring capabilities baked into the software and will thus improve it out of their own self interest. They will produce software that is easier to deploy and easier to manage once it is in production. DevOps was co-opted by operations teams who did adopt most of the automated deployment tools that are baked into cloud environments, but since the development teams are still throwing it over the wall to Operations (now rebranded as DevOps), they aren't directly incented to deliver software that's easy to support in production.

[@ContinuousDelivery]

Yup!

[@donaldstrubler3870]

This channel is so immensely content heavy it’s hard to believe. Great analyses, sir.

[@DjahDesDjah]

Thank you very much Dave for your instructions. Software programming becomes more interesting and game-like pleasant after I read your books "Continuous Delivery Pipelines" and "Modern Software Engineering".🙂

[@karsh001]

To me it seems like the DevOps method is a step on the way on achieving CD more than a competing method in itself.

[@ContinuousDelivery]

Yes, I tend to see it that way too.

[@rhys9336]

I’m not sure. DevOps can actually increase siloing if CD becomes just the domain of the ops team instead of a culture throughout the whole group

[@karsh001]

@@rhys9336 I think you are right, but that is why it is a maturity journey. The company has to fail if they are to succeed. Siloing in DevOps is from that perspective just another failure.

[@ContinuousDelivery]

@@rhys9336 Nether DevOps nor CD is ever "just the domain of the ops team" if it is, then it can't really achieve Continous Delivery (which to my mind is the point of both). CD demands some things of development approach - a flow of many small, safe to deploy into production, changes. "Ops" can't achieve that. This is one of the reasons that I think that CD thinking is the more useful tool, because it makes it more clear that "DevOps != Ops" as well as lots of other misconceptions that DevOps alone seems to struggle with.

[@thewiirocks]

@@ContinuousDelivery My favorite oxymoron is “The DevOps Team”. To which I’m always like… “What?!?!”

[@OutOfDevOps]

I think the DevOps movement/culture is a consequence of Continuous Delivery. Achieving CD in an organisation can be accelerated if the organisation adopts a DevOps culture. Unfortunately, as others commented, DevOps is treated as a job title, as a skill, or team by many organisations. This is to say that I don't really understand why in this video they are seen as competing solutions. Isn't that Continuous Delivery is the solution and DevOps is a way to achieve it?

[@ContinuousDelivery]

I think that CD and DevOps are largely different takes on the same idea, but I think that the language of CD is more useful, and broader in scope. If you just look at the terms DevOps alone is not enough, it's part of the solution. I think that CD is more specific in its advice, and that the necessity for a "DevOps" culture emerges from some deeper principles in CD - but in the end whichever terminology we pick, they are certainly close allies in a common cause.

[@manishm9478]

Whoa. Perfect timing. About to make a proposal to senior management for adopting continuous delivery. I love the focus on the main outcome of better software faster!

[@cristianpupazan1423]

Fantastic video. Really enjoyed it. Great quality content as usual!

[@l_combo]

Love that shirt Dave! Dark Side of the Moon? Better Software, Faster! I love that - similar to Jon Smart's book too. Better Value, Sooner, Safer, Happier!

[@ContinuousDelivery]

😁😎

[@thescourgeofathousan]

If you look only at the three ways of DevOps described at the start of The DevOps Handbook (the equivalent of reading the introductory blurb in Wikipedia): 1) Fast Flow - fast flow of work forward toward customers along the value stream 2) Fast Feedback - fast flow of outcome information backward towards developers along the value stream 3) Continual Learning & Experimentation - the speed and agility afforded by the first two ways makes continual adjustment and optimisation of work practices as well as the ability to use experimentation to employ a purely scientific method of work selection (ie to put out experimental mini-solutions to test the market and gather hard evidence to use in determining what solutions should be further invested in. I thinking you can fairly clearly see that Continuous Delivery solves for a large chunk of those practices. If you go further and read the full text of the first and second ways chapters you find Continuous Delivery explicitly named as the solution for same. This whole concept of confusion between the two terms CD and DevOps seems to me like it shouldn’t even exist as the most comprehensive work on the subject, written by a group of pioneers in the subject (including one of the developers of, not to mention your partner in developing the concept of, CD) and explicitly including the works of several other foundational pioneers exists. Perhaps it is because it is behind a paywall that such a resource gets less traction in peoples headspace than the slanted views plastered all over various vendors websites or Wikipedia. It is a very, hauntingly, familiar situation as I experienced in the 2000-2010’s when REST became whatever vendors and consultancies wanted it to be that would sell tools and services despite Roy’s thesis being freely available for all to read.

[@ContinuousDelivery]

Yes, personally I care about this to the degree that people can make it work. I believe that expressing these ideas in terms of CD gives a clearer statement of value than in the terminology of DevOps, and so, for me at least, DevOps is more prone the to semantic diffusion that is CD, but to be fair both get more that their fair share of semantic diffusion!

[@DannyMexen9]

I love that you mentioned "as a hint"

[@ContinuousDelivery]

😁😉

[@SoftwareInTheWoods]

DevOps should be just the first part of wiki definition. Getting rid of the siloisation of Dev and Ops. That's all it is. That so many companies have bastardised the simple idea with culture fluff, and we now have specific DevOps Engineers, is a nonsense.

[@ContinuousDelivery]

You, sir, have drunk the CD cool-aid, but we knew that😁😎

[@subcan]

I agree that... "Continuous Delivery provides the guide rails for the spokes of DevOps" I am really trying to wrap my mind around what you are talking about in all your videos... So many things feel contradictory... but this video cleared up the main point... CD does not happen overnight. Thank you for your videos... They are helping me work out the restructuring of the DevOps team I work on. CICD has been set as our primary goal... all our decisions will be based on the question of "will it get us closer to true CICD?" Bureaucracy and legacy thinking is the most difficult hurdle... I hope to be able to put all your videos together to a complete thought... at least something closer to true CD

[@ContinuousDelivery]

I think that CD works better than DevOps as the organising principle, but DevOps is the right idea and so is CD. I find CD as the more fundamental, and so more useful tool to achieve the change. Fundamentally we optimise for faster, clearer feedback so that we can maintain our software in a state of permanent readiness for release.

[@subcan]

@@ContinuousDelivery thank you again for your feedback. I am really having a hard time wrapping my mind around how to get my team in the CD mindset. I think we are close to it, but there are many stakeholders that say they want CICD but seem to really want a legacy wrapper. I have purchased your latest book Modern Software Engineering on Amazon. I am hoping that this will tie together all the concepts you present in your videos. There are a lot of opinions and often I wonder if it is all about defining the terminology more accurately? I have also been reading a lot on the cd foundation site. It looks like there is a hybrid solution for companies that do not have one product (but many extremely complicated) and have many customers with a lot of legacy requirements. It is not a solution to say that there is only one solution. I think the path to CD needs to be an iterative one too. There are so many spokes to get software from commit to production... Writing accurate tests seems to be the most critical part... but these tests are hard to write. Many developers resist this. Then there is infrastructure which is managed by the ops side which also has legacy challenges and thinking... Keeping up with modern systems requires passion... a passion only had by a small percentage of people... which today seem to be the ones on a DevOps team.

[@Burnrate]

A lot of good things in a lot of your videos but I don't think CD could really apply in safety critical software. I think the testing cycle is much longer (and needs to be much longer) than could fit into a CD type of workflow. You need to run all your unit tests, integration tests, test on test hardware, field hardware, have engineers and non-engineers test, and run through tons of possible scenarios resulting from human control and interaction. You have to keep developing while all this testing is going on also. CI/CD is great in some places but not everywhere I believe. Am I wrong? Any thoughts on CI/CD in safety-critical software development?

[@alessandrofardin9517]

Hi Dave, for me is difficult to distinguish DevOps from Continuous Delivery: I've approched DevOps for the first time watching a video from Jez Humble, because my team and I needed to improve quality and work more effectively. Then 3 year ago I've got your formidable book Continuous Delivery, the very first book I've every read and studied about Continuous Delivery and DevOps, this book is extraordinary, it opened my mind and taught me and teaching right now a lot of things. But I need to say that your thougts in this video make sense to me, in fact in our DevOps tranformation jorney, the real facts and acts is that we are implementing Continuous delivery. PS. congratulations on the shirt, pink floyd is my favorite band.

[@ContinuousDelivery]

I find CD more helpful as a tool to solve problems, but DevOps is a body of ideas and experience that can suggest ideas. Pink Floyd are certainly one of my favourites too. 😎

[@haxwithaxe]

To me DevOps and it's synonyms is a complementary set of ideas to CD. Tighter integration of roles (developers, QA, security, operations) make feedback cycles shorter. The LEAN stuff that is part of DevOps can conflict a little but it's like functional and OOP we get to pick the parts that make things work better.

[@gulgian]

I have a comment regarding the DevOps definition. I tracked Wikipedia definition for DevOps over a few years and saw it changing quite significantly (the page got over a 1000 edits). I captured these over time 2016 «DevOps is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes» 2017 «DevOps is a term used to refer to a set of practices that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.» 2018 «DevOps is a set of software development practices that combines software development (Dev) and information technology operations (Ops) to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.» 2021 «DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality.» Personally, I prefer the definition in "The DevOps Handbook" «DevOps is the result of applying Lean principles to the technology value stream.» which suggests that there is more than engineering at work for improving an organization. You touched very briefly on what is best given a context and would love to hear more from you on that in future work.

[@ContinuousDelivery]

The panel of ideas that I show in this episode are a kind of summary of the DevOps handbook. I think that this problem of drifting definition is one of the difficultties with DevOps as a "call to arms" it is not really clear how you can tell if you are doing it. I think that CD is a bit more proscriptive - "Optimise for fast, high-quality feedback" and "Work so that your SW is always in a releasable state". Now do to do that sustainatbly over time takes, organizational, cultural and technical performance. It demands collaborative teams, not just Dev & Ops but everyone else too. it requires great testing, infrastructure as code, monitoring of systems in production, good architecture and it requires that you "apply Lean principles to the technology value stream". Which is why I think it is considerably more useful as a set of guiding principles.

[@patrickrodies6111]

Thanks for this great video Dave. One of the pitfall seen in my organisation is when we are focusing so much on processes and tooling in order to apply DevOps. I always asked around the value of any of these implementations, the answer is very vague and quite often negative around my lack of trying to collaborate. Regarding collaboration, it is important for our learning and discovering to collaborate as it is also important to create valuable software to collaborate with stakeholders. Having say that, engineers do not need to collaborate with everyone on everything. This will in fact goes the opposite way, slowing down their delivery.

[@ContinuousDelivery]

Thanks. I think that it is important to have goals in-mind. I think that Continuous Delivery is better, as an idea, than DevOps because it makes some concrete goals a little clearer - "Work to speed up the feedback cycle, until you can create something releasable, at least, every day". Goals matter so that you can tell wether your changes move you closer to, or further from, them. On collaboration, I don't think it means "always agree" it means working together. Part of doing that effectively is to be willing to compromise and sometimes work on things that you don't think are the best idea and still working to try and make it work. Sometimes hard to get the balance for that right though.

[@patrickrodies6111]

@@ContinuousDelivery Agree on both accounts, on collaboration I will empathise the need to agree on values and principles. I see as a contract to allow us to work together.

[@Modzybear]

I think of DevOps as a means of achieving CD plus observability. The Dev side isn't successful until CD is achieved, the Ops isn't successful until observability is achieved. They feed into each other to shorten overall development cycles by reducing overall unknowns iteratively.

[@Layarion]

But how do you shorten the cycle of that period before "commit"?

[@ContinuousDelivery]

TDD! Write a test, run it and see it fail, write simple code to make it pass, run it and see it pass, refactor code and test to make them clearer, more general, more expressive, and then commit. For me when I am working well this takes about 10-15 minutes.

[@pevablanchard5392]

It reminds of the difference between deontological and consequential ethics. The first focuses on abiding by a specific set of rules. The second on the consequences of acting in specific ways.

[@juanpabloamorochod.752]

Checked out at "Outcome should matter more than the mechanism". In fact the idea of DevOps v. CD is polarizing. We all want the same: Faster, better software.

[@ContinuousDelivery]

The video says the same thing, but do you think mechanism matters more than outcome?

[@ederbit]

Hi Dave, would you think that it's bad practise to use CI Pipelines for Backups? For example, before a database migration takes place, the Pipeline could create a DB dump, or just initiate a backup and when it's done, it will do the migration. So that in case of some failure and data loss, you have a recent backup. Or would you say thats not really necessary since migration tools often perform safe updates.

[@ContinuousDelivery]

I certainly wouldn't say it was "bad practice". My only concern with doing this is the performance of the process. If it took too long to do the backup then I may question that approach and start to think about alternatives. But no, if that makes sense to make the release process safer, then it seems like a reasonable thing to add to the production release stage of your pipeline.

[@OhhCrapGuy]

I thoroughly appreciate that every opinion on your channel is phrased as an opinion, not as a fact. Well developed and well argued opinions, and I agree with the vast majority of them. But you avoid expressing opinions as facts, which helps to store them in my long term memory as more mutable, and to store them with the arguments and reasons for them. So where they don't apply, I more easily understand the original reasoning and it's more clear why they don't apply.

[@emaayan]

4:24, i have never seen devops as any of those items, devops are the people that create pipelines, configure and maint build servers, in case of cloud, create tr or cloud formation templates, ensure code scanning and test coverage reports, handle transition between dev and production environments

[@SM-ok3sz]

DevOps is not a job title. Anyone who calls themselves a “devops engineer” is really just a sysadmin in the developer’s way.

[@josephgarronegj]

10:44 "Going from 6 monthly releases to 3 monthly releases is certainly a positive step" I assume you ment "...from a release every 6 month to a release every 3 month..."

[@euge0]

Hi, Dave. What's your view on features that are deployed to production, but toggled off for months on end? Suppose there is some regulation or mandate in place that stops the feature from being useful before a certain date, and the feature was developed and deployed to production months before that date. Is there a smell there? Could anything there be better?

[@ContinuousDelivery]

I think that the smell is probably one of process-efficiency. If you implement a feature, predicting a need, months ahead of when it is used then 1) wasn't there something more valuable that you could have done first? and 2) If the prediction proves to be wrong, you wasted effort. In general I prefer to "deferr decisions to the last responsible moment". So if I am employing CD as my dev strategy, that means that I can release change at any time. That means that if I predict a need at some date in the future, I would prefer to wait until that date is close enough, but not too close to put me under pressure (the last responsible moment), to implement the feature. I can then release it whenever I am ready. Having a feature that is not being used for a long time is a form of waste, so I'd prefer to avoid it. The other angle on this, is if your CD is really good, then you don't need to toggle the feature, simply deploy it into production when it is needed. While I think that feature-toggles are useful, I think that they can be over-used and can add risk. I talk about this in this video: kzbin.info/www/bejne/rGWsm56na7KsnMU

[@mattpotter8725]

@@ContinuousDelivery I like your second thought on this. Shouldn't big features be split down into smaller features that have business benefit and still give business value and get released quickly? Isn't that the real mindset here that needs to be changed, moving from a waterfall mindset where everything is planned and give documents produced only for when the development teams have finished the work the business case for that work is redundant and the time works have been better spent on smaller projects that would have taken less time but given better return on investment in terms of time taken. I've worked in Agile teams where the business owner, the product owner comes to the team with a number of features prioritised in terms of one's he wants done by the business, these are shaped into stories and estimated in terms of time, and then the product owner realises that what they thought was easy to implement isn't and they shuffle what they want done, understanding the complexity more. Alternatively the devs can give options on maybe splitting the whole part of the main feature they want into smaller parts which can then be done (although this ideally should have been already done before it gets to the team) and then the Product Owner has to decide if is better to get part of the features they actually wanted done first or maybe some lesser priority features. Occasionally when actually explained in detail what the business is actually wanting there is a better, easier way to get what they want done, and this two way exchange really helps devs understand the business they're working in and the business understand the complexity of what's involved in delivering it, they also don't get frustrated waiting for features to get released as they are involved in the daily standups, involved in hearing how development is going, and if there are any problems they know about them long before any expected release date is missed. I think these scenarios mean there are great feedback loops between the dev teams and the business, as well as in the development teams themselves. Great videos. Only just found you. Keep up the good work. Oh, and when you say releases every 6 months or 3 months if makes me cringe. One month at the max, maybe weekly if possible, and in a perfect world less than that, basically whenever something of business benefit is ready!!!

[@albirtarsha5370]

What happened to "configuration management"? Was it killed by Agile?

[@andreasrusso-frisk5047]

Don't know if I'm getting this wrong, but in my head, DevOps and CD are not the same thing and thus not competitors. Implementing CD can be (and often is) a part of DevOps. DevOps is a role, CD is a methos of delivery?

[@ContinuousDelivery]

Wich I think is what my video mostly says - not competitors, aimed at the same target, but where I disagree is that CD is not "part of DevOps" rather "DevOps is closer to part of CD". Continuous Delivery is the desirable outcome. DevOps is a collection of ideas to help to achieve it.

[@andreasrusso-frisk5047]

Ah, then I must have misunderstood.

[@petermanger9047]

Finally ordered your book!

[@ContinuousDelivery]

Thanks 🥳

[@tiagodagostini]

I find funny that there is so much HYPE on continuous delivery when during my 24 year experience (most of it in healthcare and communication backbone systems), most often than not the clients COMPLAIN of continuous delivery. I all the fields I worked they start to complain heavily if you make weekly deliveries. . I had cases where we lost clients because they felt they were being used as testers and they wanted at MOST 2 releases per year. This was so critical that they pushed the regulatory agencies in my country to FORBID such practices. For example I cannot deliver/ sell a software component in healthcare that had ANY change at all after it had been deployed in test field environment for 28 days.

[@ContinuousDelivery]

Except what you describe isn’t Continuous Delivery, C. delivery is defined as “working so that your software is always in a releasable state”. What you are thinking of, I think, is a sub-set of C. Delivery, sometimes called “Continuous Deployment” where the decision to release is also automated. C. Deploy. Makes lots of sense for some kinds of systems, and less for others. C. Delivery makes sense for any SW. I have several clients working at the cutting-edge of medical devices, working towards, or practising, C. Delivery. You can read about some of Siemens Healthcare’s work on this here: www.infoq.com/articles/continuous-delivery-teamplay/ and here: www.slideshare.net/VladikUkis/enabling-continous-delivery-in-the-siemens-healthineers-digital-ecosystem-platform-and-teamplay-applications

[@tiagodagostini]

@@ContinuousDelivery I do not agree with the policy, but the regulatory agencies here have setup rules that make the effort mostly moot. They demand a grace period where no change at all was made in the software before delivering it... that makes the Always at deliverable state almost irrelevant(at a businness level) , since you cannot use its most immediate gain (the only remainign gain is that you cannot take yourself too far from a stable situation and that indeed avoid going into a deep hole). Indeed there is a mix of the cocnept of deploy with delivery.. maybe here it is enhanced sicne in portuguese Deploy and deliver are the EXACT same word.

[@ContinuousDelivery]

@@tiagodagostini the "always deliverable" is never irrelevant even if you don't release into production. It gives you clear feedback on where you are and you are guaranteed to never miss a release date. At most of my clients that work with medical devices, they find a way in which to release to non-clinical settings more frequently, but even without that maintaining releasability makes for higher-quality software overall. I sometimes joke that C. Delivery assures you that you are building things right, C. Deploy ensure that you are building the right things.

[@tiagodagostini]

@@ContinuousDelivery The "always deliverable".. or as close to it as possible is something I agree, but I do not know if you heard this complain from more people, but at least in my experience, I have faced a lot of people that thinks the important part is the DELIVERY itself, not the software being always deliverable. The always in deliverable state I see a great correlation on what I learned on painting ( a hobby of mine).. a great practice is.. work from general to detail.. and try to keep your painting always in a consistent state that you could consider.. complete (even if in a lower detailed state). You add details in iterations. Always pushing the whole painting into that next stage before you advance further . The painting is always consistent. The contrast would be to render a corner of the image to user detail before you do anything else... and you fall in the trap that if you suddenly dislike your composition.. it is too late do change anything.

[@ContinuousDelivery]

@@tiagodagostini I like your art analogy!

[@jensBendig]

My thinking now has a name. It seems to be called continuous something. Is continuous delivery the same as continuous integration? I ask, because it not always is the best Idea to deliver every version to the user, or is it? From user's perspective...

[@jamzbraz]

The way I see it, Continuous Integration is all the automation you need to achieve Continuous Delivery. You should be able to deploy complete high quality work as fast as possible, and in an automated way. You should never merge code that's incomplete, in development, untested or low quality. That way you never release a problematic version.

[@nataliaovriakh8689]

Your channel s awesome. Thank you so much for all the wisdom!!!

[@amcadam26]

Continuous delivery is part of DevOps. Or at least it is according to the DevOps handbook. Is Gene Kim wrong?

[@ContinuousDelivery]

Yes, IMO I think that the authors, in that respect, are wrong. You could justifiably say the same thing about the CD book, that DevOps is described as part of CD. I don't think that there are many ideas that DevOps advocates that aren't at least touched on the in the CD book.

[@michaelnurse9089]

If you look at set theory 'part of' should be defined as either an intersection, union or subset. Just saying "it is a part of x" does not fully describe the relationship.

[@richard_luke]

I really enjoy and learn a lot from your videos. It's a shame that where I work I can't apply everything I learn here because they have a very old and rudimentary way of working.

[@ContinuousDelivery]

Well the reason that I make them is that I think that we have learned how to do a better job of creating software, so I am pleased that you find them enjoyable, but do feel free to recommend them to the people who need the help too 😉

[@vadym8713]

You could always change your job

[@richard_luke]

@@vadym8713I have been looking for a new job for more than 1 month

[@rahulparashar2647]

i am going to order your book , you are great sir :)

[@ContinuousDelivery]

Thanks, I hope you enjoy it.

[@DeanBevan]

I would say it differently - CD is a key part of DevOps. I believe DevOps, where understood and used correctly goes further than delivery. Delivery is the start of DevOps. Understanding that the delivered software will need to evolve and adapt is what takes DevOps further. Feedback and Continual Improvement of operational software, both in terms for performance and customer use are key parts of the DevOps endgame. CD is one of the key techniques in the DevOps bag, but it’s key to understand that DevOps isn’t a fixed position. It’s about creating Flow, Feedback at all stages and Continual Improvement. It uses the tools and Techniques that work in a given Context. But then, I’m slightly bias too. 😉

[@ContinuousDelivery]

I understand your argument, but I think that you miss out the "Continuous" part. CD is not just about "Delivery" it is about being about being able to maintain a flow of deliverys continuously (or a close approximation of continuously). If you want to do that, then you need to gather feedback from production, learn from that and feed it into your development cycle. To do that you need to be able to monitor the system in production, gather data and manage that system in production. For example, in the CD book that I wrote with Jez Humble, we describe gather feedback on the system in production (starts on p317) and using that info to decide how to evolve you products to better fot the needs of users. Isn't that the same thing?

[@DeanBevan]

@@ContinuousDelivery I think we are agreeing? CD is such an important corner stone, and the book is the foundation that we build upon. I think the challenge here is where both CD and DevOps stop - both are adaptive and evolve. The bastardised version of DevOps that we see "packaged and sold" isn't what DevOps should or needs to be. The rise DevOps is a response to trying to limit scope, but that always has been the objective of DevOps and CD. Learn and evolve? As much as there is a view that agile, DevOps etc are mainstream and fixed, they are still emerging and evolving?

[@camgere]

I have to wonder how customers react to continuous delivery. Some customers may like being on the bleeding edge of technology and are willing to put up with being "beta" testers and continually shifting software. If you are making "Jurassic Park" and REALLY need that brand new effect, this is just part of the game. If you are the Ford Foundation and are investing billions of dollars over decades, stability and accuracy are much more important. Let other people test the financial software for a year or more. As an aside, pure delay has a bad reputation in control systems science. High performance systems tend to have have frequency response (as well as reasonable step response). Pure delay just kills frequency response. A two day test delay doesn't just delay software release by two days. Assume errors occur and need to be corrected. You will go through this two day delay numerous times. So I fully support minimizing delay as a general goal. Are there certain customers that like continuous delivery better?

[@dgkimpton]

I'm fairly certain your conflating Continuous Delivery and Continuous Deployment here. Building a release everyday doesn't automatically imply deploying a release everyday. For me Continuous Delivery doesn't necessarily even eliminate the QA department, but it does mean that on any given day QA can pickup the latest release and know that as far as dev is concerned it's ready to ship. Then, assuming QA are happy (hah), the Release Manager (if there is one) can choose to Deploy to customers. Continuous Deployment otoh does (in my book) effectively imply that everyone gets a continuously shifting software platform... and that's why I'm not convinced Continuous Deployment is the right approach for most teams.

[@eternalskywalker9440]

Would this have been possible in the 80s when we shipped software on physical media? Would you have released to manufacturing every day and given customers a different product depending on when they ordered it? It seems that would have increased the burden on tech support. Maybe that's the "business decision" part you talk about. Of course it is less important today with over-the-network updates.

[@ContinuousDelivery]

Yes, it would have been possible in the sense that Continuous Delivery is working so that your software is always releasable. It doesn't force you to release it.

[@zauxst]

Well... DevOps is often put in the CI/CD loop in order to be explained. DevOps was always a buzzword for a cultural shift in a way to standardize and enrich the CI/CD loop. It can help simplify for those that don't understand what DevOps is to actually just focus on CD. But normally we go ahead and control much more of the release cycle. If the delivery is getting slowed, then they are doing anti-devops practices. And it requires a team that has that in focus to actually carry it around. You are, when you are consulting, acting as a DevOps that cares mostly about the CD aspect. So I'd argue that Wikipedia is not wrong.

[@ContinuousDelivery]

I don't agree with you last point. It assumes that the "CD aspect" is somehow smaller in scope than the "DevOps aspect" and I don't believe that to be true. If you take a definitional stance, there are two ways in. Either you take the "DevOps means Dev and Ops working together" minimalist stance, in which case DevOps is not even nearly enough to continuously deliver valuable software to users. Alternatively you can take the "DevOps culture" definitions, and while there are useful refinements in how some of the ideas are explained, compared to the way that Jez Humble and I described them in our CD book, I don't see anything that widens the scope. To continuously delivery valuable software into the hands of users you must have great collaboration, you must monitor and operate the system in production to learn from it and so be able to maintain that continuous flow of ideas and so on and so on. My main point, is that I think that if you think of everything as targetting this "Continuous Delivery of Ideas" it provides a model that informs everything else, and so a tool that we can use to do a better job, even if the answer isn't in my book or the DevOps handbook, or in any other book.

[@mattpotter8725]

I always thought that DevOps were the gatekeepers of releasing into production, the link between Dev and Ops, hence the name? They engaged with Dev teams to minimise risk and make sure only code that had gone through all the proper stringent processes to ensure the quality of the release, whilst also bringing in the DBAs and System Engineers that looked after the production environment so they understood what was about to be released and keep an eye on any potential problems, even ask any questions to ensure everything has been thought about. Without it, and I have worked in such places it's like the Wild West where things get released quickly to production, but there's a hell of a lot of time wasted trying to fix things in production that shouldn't have gone there in the first place!!!

[@thescourgeofathousan]

DevOps is a way of working not a they. If your organisation has a DevOps team or teams then it is not doing DevOps by definition.

[@randomgeocacher]

One single term and actually getting people to agree on the goal of that term because it adds value. Yes I agree CD may be a great term. All of these terms, companies have them but it still just does not work. I realize it isn’t binary but it often feels like they are just 10% of their journey from waterfall but they already have all the keywords checked. I noticed the trend of adding more stuff onto DevOps, such as DevSecOps. It feels a bit like ”dev ops does not work because we forget everything we need to do in order to have quality releasable software so now we start to tack on everything we forgot onto devops”. In my experience most companies aren’t thinking CD about continuously deliverable software. Often it is more: “It passed a CI/CD pipeline that run a bunch of not-very-extensive tests and probably people did not look much at the test reports anyway”. And maybe the integration tests actually were against mock-ups. And maybe no proper end to end flows were tested. And maybe months of development happened without any performance testing. So all the work and problems are left to the real integration tests that happens very rarely. Actual integration tests and actual continuous delivery is hard work. Making people to actually think and act towards a goal is hard. Checking checkboxes and piling on various keywords is much easier.

Isn't DevOps CI+CD?

[@ContinuousDelivery]

Depends who you ask, that is kind of my point. DevOps describes a practice "Dev & Ops working closer together", but that practice alone isn't enough. So you could say that "DevOps matters, because CD" which is what I would say, but that isn't what the term "DevOps" says, although some DevOps people do. I think it is clearer to say "We'd like to be able to Continuously Deliver valuable software to users" that defines the outcome, not the practice, and then you do everything that it takes to achieve "Continuous Delivery" and that includes DevOps, amongst other things.

[@chrvberg]

I wonder how Jez Humble sees it. He's co-author of the DevOps Handbook *and* Continuous Delivery. In my eyes, DevOps™, CD™, Agile™, Lean™, XP™, … are all a proof of convergent evolution: en.wikipedia.org/wiki/Convergent_evolution They may start from independent approaches but end in the same outcome.

[@ITConsultancyUK]

The problem is the outcome is not a consistent factor that you can always control. I think the DevOps/CD is a bit of a fashion hype in the software world at the moment and will probably be superseded by a better model that allows the creation of quality software with less touch points.

[@paulreilly5987]

It’s the quality of test design and execution that is weak for software delivery. This is down to individuals skills. Poor quality programming is also down to individual skills. Poor communication of business needs are down to skills and poor software design, skills again.

[@gronkymug2590]

The only thing which works in convincing non technical CTO about the benefits of a new approach is standing up a working CI/CD pipeline which aligns with the practice one wants to follow. If one can just talk about it but not deliver a working pipeline and needs a lot of help to do that, then he will often require a 3rd party consultancy to convince their CTO that putting work into something that complex will benefit everyone. And because CD (in agile team) is rarely job for one we need some flow diagram for how to convince a CTO or it will be quite difficult to do so :) Also, most developers can't wrap their head around working directly with the trunk, so they are not going to help, too 😅 Still, some good companies use CI/CD well already, so maybe in another 10 years everyone will. Just in time for AGI to arrive and replace us all 😂

[@JonathanStearnes]

I believe both are needed. DevOps facilitates Continuous Delivery.

[@ForgottenKnight1]

In my experience, DevOps and corporate politics rarely make good friends. You might want to apply DevOps practices, but if the culture is not there, there is a very low chance that you will convince an entire management chain to change their "processes" to improve collaboration and streamline things.

[@Deemp548]

Have you ever seen a software that is made quickly cheaply and is reliable? I haven't

[@ContinuousDelivery]

Well, they are relative terms, but yes.

[@michaelnurse9089]

It depends on what software it is. Put up a scaffolded website with .Net or similar - sure. Program the flight systems for a passenger jet - no ways.

[@zoltannemeth8864]

Dev side of the Model. - I like the CD Release

[@ContinuousDelivery]

I think it's better for Ops, and everyone else too 😉

[@agushary9405]

Thank you very much for sharing

[@vimalneha]

I bought his book CD Pipelines, it has no substance, not a single line of Code with any tool. It is just for speaking or understanding the idea or meant for project managers at best. I suppose one has to take his online course, but not sure if there is one tool that is being followed or that just vocalized this book. I have already applied for CI/CD with Kubernetes+ GitLab, so for me, it was a nearly useless book.

[@ContinuousDelivery]

Sorry you didn't like the book. It is my view that a tool centred approach to learning new ideas is a weak one. I am more interested in how you wield the tools, rather than the tools themselves. That is at the heart of much of my work. I have implemented pipelines with a wide variety of tech, but which one suits you or you circumstances is impossible for me to judge. My experience is that the common mistakes that people make with pipelines is not a problem of tool choice. Kubernetes and GitLab don't tell you the best way to organise things to make CD work, I think the my book does, but I am sorry you didn't find it helpful. If you didn't like the book, I don't recommend my course to you, you won't like that either.

[@loquela]

I think you are barking up the wrong tree here. Continuous Delivery is part of the DevOps approach - it's a DevOps tool/process. They cannot (should not) be separated out as you have attempted here.

[@ContinuousDelivery]

That’s certainly a common viewpoint, though I think it wrong 🙂

[@loquela]

@@ContinuousDelivery Ok, well I guess you nailed it with that argument.

[@darrenatarrant]

You can deploy new software every 20 seconds but it means nothing (and in fact causes problems) if not everybody who has a stake in the software is on-board with experimenting and learning. CD, Devops, Agile - none of these are pure engineering things and will not succeed if the company is selling the software based on concrete roadmaps promising feature X in Q2 (for example). Companies that work this way invariably fall into the trap of creating backlogs of stories and slices of releases that go from nothing to that pre-conceived fully-fledged feature and call it Agile. This isn't Agile, it's just a more incremental and painful form of waterfall.

[@MrHaggyy]

Aren't DevOps the poor guys that get called every other minute by management to fix stuff and CD the folks with a live who make management run for sales. But jokes aside, a software delivery in under 1h/1day? I work in embedded engineering and can't really see a way of getting that fast. Testing and approvals alone take a view weeks if all went good. If you write something that needs to be deployed on a server or downloaded to a client i can see this work. But with mechanical, electrical and control engineering etc how do you get that short cycles?

[@ContinuousDelivery]

Checkout what Tesla do, or Ericsson, or Huawei, or Volvo Trucks. Lots of embedded systems, even embedded safety critical systems, work this way.

[@MrHaggyy]

@@ContinuousDelivery Thanks for your advice. I watched your video about Tesla and read a few things about Volvo, as we have safety-critical devices too. Automated and load-balanced testing instead of a scheduled testing routine is probably a key feature to get from 1-2 months to a view weeks. These rather long human testing staged by some surveillance is a double-edged sword. I think this even hinders those mentioned to get down to a view days as well. (if it's the whole system and safety-critical) But on the other hand, they are in place because they find stuff quite often. And they also share liability with you if someone got harmed by using your device. And sadly this happens ... even with the best intentions and practice in place. If you change your system multiple times you would need organizations that can approve your systems multiple times a day too.

[@Hazebeast]

IT Mantra!

[@ContinuousDelivery]

😁😎

[@a0flj0]

I think there's a logical fallacy in your reasoning - you equate delivering software artifacts with delivering value. Creating and deploying the artifacts is just one step of the entire process required to provide value to users through software. As with any process, local optimization might harm overall efficiency. To pick up on your products analogy, a company creating great products may very well fail if their logistics department is shit. If their products are complex - like software - logistics alone won't help, if customer support and service network don't keep up. If you keep working on the product, increase delivery speed, without working across the organization to make sure support, sales and service can keep up, you're not delivering more value at a faster pace. You're destroying value, in fact.

[@ContinuousDelivery]

Thanks for your thoughtful reply. I don't think that I am making that mistake. Continuous Delivery is not just about the technology, It is about the CD of value. What I take from that, to borrow from your analogy, is that if you want to learn about your products from your customers then you need to be able to 'Continuously Deliver' value across the board. So if your Logisitics function, or whatever else, is the problem then you must fix that. CD is not just about software tech, it is a mindset that ultimately impacts on every aspect of business, that is what I mean by CD, that is why I think it is the broader concept.

[@a0flj0]

@@ContinuousDelivery You call it CD. Most people call that mindset just an agile approach. Devops, however, is not completely overlapping with an agile approach, although devops and agile go hand in hand, and you can't do one properly without doing the other. The essential point, however, IMO, is not naming. CD, at least the way most people understand it, misses an important point, I believe. In order to have a running system, that delivers value, you need to have many components deployed and running well, and, very important, running well together. You need to practice CD for each of those components (from the OS of each server and each laptop to the smartest of your applications that runs on top of an application server deployed in a container run by docker inside a VM, with all of docker, the container and the VM being built and deployed through separate, independent CD pipelines). But that's not enough - it takes care of getting everything deployed and running well, but not of getting all components to run well _together_. That's where devops adds value on top of CD. Devops requires you to practice CD for each component, but also requires you to go a step further, and integrate CD for each component with the CD of all components it will interact with, once deployed. You sort of need to make sure you don't just break _your_ work, but also don't break other people's work, or, expressed in a positive way, what you do on your component has to add value to other components it interacts with too, and this becomes your responsibility. That adds an entirely new layer of complexity and concerns on top of just CD, or at least on top of what most people perceive to be CD. The more so since an enterprise system is never coherent enough that you could treat everything, end to end, as one single huge delivery pipeline. This approach, of teams partially taking on responsibility and having to get involved with the internals of systems you interact with, but that aren't under your full control, blurs the traditionally strict demarcation between dev and ops in a way that CD (or at least the way most people understand CD) does not. Hence, its name: devops. However, the blurring at the dev-ops boundary is just the most visible effect, but many other boundaries are affected as well. Devops is about keeping some structure and order in a system that tends to disintegrate at all time. CD, both as a mindset and a process, is just part of that effort.

[@tedfitzpatrickyt]

awesome t-shirt, long live Roger Waters

[@michaelnurse9089]

Roger Smoke.

[@nhqtnhqt]

Better Food Faster

[@CodingWorm]

first

[@ContinuousDelivery]

😁

[@Greedygoblingames]

DevOps, CD, Agile... all buzzwords misused and abused by marketing teams and consultancies to dress up the same simple goal... build better software, faster.

[@ContinuousDelivery]

Yup 😎

[@wvv3758]

If you want to create better software (much) faster you need a low code platform.

[@zoranProCode]

no difference...

[@fringefringe7282]

Software is not tamato salad...

[@ContinuousDelivery]

Thank you for the clarification

[@ITech2005]

Tbh, this distinction is truly meaningless and serves as a point mental masteurbation. Just speed up your dev cycle and get good code into production. Once you understand that you can move on and let the philosophers play with words and labels.

[@Talk378]

Another video another false dichotomy