Continuous Deployment or Continuous Delivery? | When To Release 

Working so that your software is always working makes a huge difference to teams. Congratulations!😁 😎

I am pleased that you like it, thanks.

Yeah. CP2077's fiasco might have the positive side effect of increasing awareness toward software development best practices and principles.

Same here!

First thanks for the thanks😎 Second, yes, I think you have the right answer. I describe Continuous Delivery as working so our software is always releasable, so that means, exactly as you say, keeping, in effect, your own version of a production environment, that you can deliver changes to and evaluate them in. This gives you great feedback on the quality of your work, and so is an extremely valuable tool in driving the development process. The second step gives different feedback, feedback on your product ideas rather than the quality of your work, so the more frequently you can go intro production the better you learn what your customers value (or not) in your products. If for some reason you can't go into production frequently, you can sometimes simulate this second effect by putting the release candidates that you regularly and frequently create (through Continuous Delivery) into some form of "fake production". I did some work with Siemens Healthcare, and there were some regulatory constraints that prevented them from frequently deploying to real live clinical settings, but they were allowed to deploy as often as they liked for non-clincical users, so people using medical scanners for research or as part of a beta program where there weren't real patients being treated. So they did that, they released into a dedicated "mini-prod" envirionment and gathered feedback that way.

Yeah, i do the same, we even created our own color theme and launch icons for the in house deployed application. This and a different config directory default is the only source code difference to the general available software.

Cool, thanks!

Thanks

I consulted your Continuous Delivery book: "This bears repeating. Each check-in should be considered a deployable release. No commit should every be partial, as in, this is the first commit, but it requires additional commits to work. Assume the product will be released without the additional commits. If new or updated behavior is substantial and requires multiple commits, to reduce risk of changing too much, then the earlier commits must be inaccessible code, either because there's no way to access it or a feature flag keeps it deactivated. Code that is not executed can be released." This is from The DevOps Handbook: "In the last five years, there has been confusion around the terms continuous delivery versus continuous deployment-and, indeed, my own thinking and definitions have changed since we wrote the book. Every organization should create their variations, based on what they need. The key thing we should care about is not the form, but the outcomes: deployments should be low-risk, push-button events we can perform on demand. When all developers are working in small batches on trunk, or everyone is working off trunk in short-lived feature branches that get merged to trunk regularly, and when trunk is always kept in a releasable state, and when we can release on demand at the push of a button during normal business hours, we are doing continuous delivery. Developers get fast feedback when they introduce any regression errors, which include defects, performance issues, security issues, usability issues, etc. When these issues are found, they are fixed immediately so that trunk is always deployable. Continuous delivery is the prerequisite for continuous deployment-just as continuous integration is a prerequisite for continuous delivery. Continuous deployment is likely applicable in the context of web services that are delivered online. However, continuous delivery is applicable in almost every context where we desire deployments and releases that have high quality, fast lead times and have highly predictable, low-risk outcomes, including for embedded systems, COTS products, and mobile apps."

“Deployed”: A technical concern that applies in the domain of the team and means the functionality is introduced in Production. “Released”: A business term that defines functionality being available to an end-user.

It is confusing. I use the words in the following way: Deploy - The technical act of copying some new software to a host environment and getting it up-and-running and so ready for use. In context with 'Continuous' as in 'C. Deployment' I use it to mean 'automating the decision to release' - If you pipeline passes, you push the change to production with no further actions. Release - Making a new feature available for a user to use. (Note: we can deploy changes, that aren't yet ready for use by a user, when we make them available to a user, with or without a new deployment, we release them - I plan to do a video on strategies for this). Delivery - In context with 'Continuous' I mean this in a broader context. for me 'Continuous Delivery' makes most sense as used in the context of the Agile Manifesto - 'Our highest priority is the early and continuous delivery of valuable software to our users'. So it is about a flow-based (continuous) approach to delivering value. That means that the practices need to achieve CD are the practices needed to maintain that flow of ideas - so it touches on all of SW dev. I know that this is an unusually broad interpretation, but it is the one that makes the most sense to me, and the one that I find helps me to understand what to do if I am stuck trying to help a team to deliver. There is, as far as I know, one place where my language is a bit inconsistent. I tend to talk about working towards "Repeatable, Reliable Releases", if I were willing to drop the alliteration and speak more accurately that should be "Repeatable, Reliable Deployments". I hope that helps a bit?

@@ContinuousDelivery Here is my 2min take on it. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-RBQz9QhFfdc.html I appreciate any feedback!

@@ContinuousDelivery I am also not always very consistent in my language. But I see a large benefit if people understand this distinction, and if teams can actually cope technically with this. "Release On Demand" FTW!

The Cyberpunk video led me to discover this information goldmine.

Welcome to the channel, I am pleased that you like it.