Yes, I tend to see it that way too.

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

@@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.

@@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.

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

Yup!

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!

😁😎

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.

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.

@@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.

😁😉

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

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.

@@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.

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.

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. 😎

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

Thanks 🥳

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 😉

You could always change your job

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

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

@@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.

@@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.

@@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.

@@tiagodagostini I like your art analogy!

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?

@@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?

Thanks, I hope you enjoy it.

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.

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

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.

Ah, then I must have misunderstood.

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.

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.

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.

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.

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.

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: kzfaq.info/get/bejne/rJp5nc6im7Pdlpc.html

@@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!!!

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.

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.

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

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.

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.

😁😎

Well, they are relative terms, but yes.

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.

Roger Smoke.

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.

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

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

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

@@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.

😁

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.

@@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.

Yup 😎

Thank you for the clarification