This is so interesting and well compressed source of knowledge about practicalities in software development. I am enjoying other videos of yours also. The parts around your particular experiences with past projects are especially interesting, please post more of those if possible :)
We are working on an long run embedded (eco-)system. We introduce new features over the time. We Simply can't deploy our new features on the customer devices. We are in our journey to use and implements a full functional Continuous delivery process. But we now release internally every week, Just 2 years ago we was releaseing every 2 or 3 month. The difference in product quality and team morale Is huge!
Hi Dave, firstly I just want to say thank you for producing these videos. I got recommended your channel after your Cyberpunk video and I feel like I've stumbled upon something great! Secondly, I was going to leave a comment asking how you would recommend practicing CD when you are not able to automatically deploy to your production environment, but I think this video answered my question. The software that I build at my job is almost always deployed manually because of the constraints of the production environments, which has made it feel like we can't truly practice CD. After watching this video I feel that the answer is to continuously deploy to an environment that we control, and have people from inside the company use it. We have actually already started to take this approach, now we just need to get people to use it.
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.
This information is very helpful outside of programming and development as well. After hearing about your approach to game development, you could honestly plan out a lot of other tasks and or goals in this mindset. Appreciate the content!
The first principles approach is the best approach :) I like your thinking. I have seen people writing about doing deployments straight to production and running all their tests there. Everything behind smart feature flagging. Some add canary deployment to make sure that adding new feature in its off state did not break anything and if they find it did (on a small number of requests), then they revert the change. Canary deployments seem to be also useful in releasing changes which relate to new version of compatible packages. Same goes for feature flag canary releases. Turn a feature flag ON for small number of users (or just testers at first) and you can test everything in production (in theory). Eventually every system is tested in production anyway, so maybe sometimes there is a little point of having anything more than just one environment (production) to release to. I wonder what is your view on this kind of releases and for what kind of projects they could work the best.
Delightful explanation. I'm looking forward to implement this in my own projects. At which point would a UI review occur in the process of we decide to go with continuous deployment? 🤔
Can you please restate definitions for Release, Deploy and Delivery? I'm still a bit confused among them, especially the distinction between Deploy and Delivery. I view one as pushing code with new features. I view the other as activating activating those new features, which are pushed in a deactivated mode. The activation mechanism may be something like a Feature Flag. I had viewed Deploy as pushing the code, and Delivery has activating the feature in that code, but now I'm not quite sure. And maybe even your definitions are different that my examples. Additional clarification here would be appreciated. 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 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!
![Baby Kia - GLOVES & DRACS (BLACK AF1s) [Official Music Video]](http://i.ytimg.com/vi/ajm8LeB0qQk/mqdefault.jpg)
I was recommended this channel after your cyberpunk video. I must say this is interesting content
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!
This is so interesting and well compressed source of knowledge about practicalities in software development. I am enjoying other videos of yours also. The parts around your particular experiences with past projects are especially interesting, please post more of those if possible :)
We are working on an long run embedded (eco-)system.
We introduce new features over the time.
We Simply can't deploy our new features on the customer devices.
We are in our journey to use and implements a full functional Continuous delivery process.
But we now release internally every week, Just 2 years ago we was releaseing every 2 or 3 month.
The difference in product quality and team morale Is huge!
Working so that your software is always working makes a huge difference to teams. Congratulations!😁 😎
Hi Dave, firstly I just want to say thank you for producing these videos. I got recommended your channel after your Cyberpunk video and I feel like I've stumbled upon something great!
Secondly, I was going to leave a comment asking how you would recommend practicing CD when you are not able to automatically deploy to your production environment, but I think this video answered my question. The software that I build at my job is almost always deployed manually because of the constraints of the production environments, which has made it feel like we can't truly practice CD.
After watching this video I feel that the answer is to continuously deploy to an environment that we control, and have people from inside the company use it. We have actually already started to take this approach, now we just need to get people to use it.
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.
This information is very helpful outside of programming and development as well. After hearing about your approach to game development, you could honestly plan out a lot of other tasks and or goals in this mindset. Appreciate the content!
Cool, thanks!
The first principles approach is the best approach :) I like your thinking.
I have seen people writing about doing deployments straight to production and running all their tests there. Everything behind smart feature flagging. Some add canary deployment to make sure that adding new feature in its off state did not break anything and if they find it did (on a small number of requests), then they revert the change. Canary deployments seem to be also useful in releasing changes which relate to new version of compatible packages. Same goes for feature flag canary releases. Turn a feature flag ON for small number of users (or just testers at first) and you can test everything in production (in theory). Eventually every system is tested in production anyway, so maybe sometimes there is a little point of having anything more than just one environment (production) to release to.
I wonder what is your view on this kind of releases and for what kind of projects they could work the best.
I’m looking over your video list like a kid in a candy store. Yum, yum!
Thanks
Thanks!
Delightful explanation. I'm looking forward to implement this in my own projects.
At which point would a UI review occur in the process of we decide to go with continuous deployment? 🤔
I would like this ideas but I'll be switching to Azure Certificaiton Channels for now haha
Can you please restate definitions for Release, Deploy and Delivery? I'm still a bit confused among them, especially the distinction between Deploy and Delivery.
I view one as pushing code with new features. I view the other as activating activating those new features, which are pushed in a deactivated mode. The activation mechanism may be something like a Feature Flag.
I had viewed Deploy as pushing the code, and Delivery has activating the feature in that code, but now I'm not quite sure. And maybe even your definitions are different that my examples.
Additional clarification here would be appreciated. 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. ruclips.net/video/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!
Lol you should do more Cyberpunk criticism videos. Nobodies on youtube are gaining views and so should you.
The Cyberpunk video led me to discover this information goldmine.
Welcome to the channel, I am pleased that you like it.