@jimhumelsine9187
I feel that several terms are used interchangeable based upon context. I have a more rigorous definition for these terms for myself: * Integration - When all code changes are converge into trunk. When part of Continuous Integration, we want this to occur at least once per day. * Deliverable - The system is in a deliverable state when it can be deployed in short order. When part of Continuous Delivery, we want the system always in this state. * Deployed - This is when the system has been deployed to production. The product has moved out of the build/test environment and it resides in the production environment. However, this does not mean that all of the features in production are active or accessible by the user. * Released - This is when features are active and accessible by the user. Releasability can occur with a deployed system via feature flags or other such mechanisms. This allows behavior to be released in a controlled and observable manner. Some behaviors may be released as soon as they have been deployed. Unfortunately Deliverable and Deployable are very similar concepts. The former represents the state in which software can be deployed to production. The latter represents the state in which software has been deployed to production.
@nebukadnezar4431
Brilliant, high level overview of CD, love it!
@Resurr3ction
This is a great checklist! Some of the things like "single route to production" or "automated testing" are in my experience very challenging to many people in the industry. They usually do not understand what happens when you don't follow them and temptation to take a shortcut is very strong (deploy manually, bypass testing).
@brandonpearman9218
Good video. I generally work for large companies, and its very common for them to set blanket rules that teams are not allow to work of master. You have to create a branch and then raise a PR into master. When the team is kept small and we have many services, then PR into master is generally not a problem because every developer is working on a different part of the system.
@michaelrstover
I can determine releasability as often as you like. Is it releasable? No. Am I doing this right?
@JohnnyNilsson83
Great video! And a great list! I will bring this to people in my organization and see what they make of it as input to the changes that are being made. We are defining a delivery pipeline, in a broader sense than building written code and deploying it in production. I think your bullets is exactly the things we need to consider to include.
@UW4IT
@continuousDelivery basics covered very well, and extended thanks for all the efforts put in this area for people to understand what CD is. A request, to cover a real life CD pipeline with new age deployment with Helm & Flux/Argo and that is visualised in real life from E2E. I know you had a video covering this with Ansible jenkins etc, but i think it is 2 years old and kinda obsolete now in 2023. This will great to know from someone like you, who has the wealth of knowledge and resources.
@conorh999
Excellent video 👏 Thank you Dave.
@bryanfinster7978
Thanks so much for the MinimumCD callout!
@dsvoid
I think the challenge in going through this checklist is considering carefully its order of operations depending on the team you're in. I am not speaking from a point of experience, but I can imagine there's some growing pains that can vary step-by-step... it's a shame that one still has to plan these things out carefully instead of slapping it right on their existing process!
@patrik72carlos
Great summary of capabilities to focus on. Thanks. I was wondering if there is any reference to the statement that 95% of security "problems" can be avoided by using no older then 8 months of infrastructure sw versions?
@danielferszt6521
Great video!
@disgruntledtoons
What you don't do is to bunch a group of changes into epics which don't get put into production until every change is ready to go.
@megaman2016
But you need to branch off if you are developing a big non trivial feature and you dont want your work in progress affect the main branch release cycle
@polariss0i
I feel like "release-ability" is being over used sometimes in your sentences, should it not be consistently deployable? You do state that later, but I want to make sure people understand you won't always release the feature to the users each day, but you want to be able to deploy the latest code to production as much as feasible. You may dark deploy a feature, or hide them behind feature flags, but what you are trying to prevent is long living branches. You don't want to have to update some code, make sure all the logging is there, update the documentation, monitor the application all in one branch, you want to be able to add that incrementally, but in some way make the changes safe to deploy, even if incomplete.
@GamePlayByFaks
Hi, answer is simple keep it simple.
@allenbythesea
couldn't agree more 'trunk based'. The git flows out there are insanity IMO.
@krumbergify
Unfortunately our software needs to by approved by Apple and Wifi Alliance test houses before it can be sent to our customers.
@ndewet
It is such a shame that we have no "building code" or regulation in software generally. Many teams / orgs do not even practice CI nor TDD and the latter is exceptionally difficult (an opinion). I'm not sure this constitutes professionalism.
@ModernSoftwareEngineeringYT