14 Step Continuous Delivery Checklist

How can you tell how good your software development process is working? Continuous Delivery is state of the art for software development, it is how most of the best software companies in the world work. So how close is your organisation to achieving Continuous Delivery? CD is the best way to organise your work, but it is not an easy process to adopt. So what are the markers of success, what are the targets to aim for, and the measuring sticks that will help you evaluate where you are now, and what next steps you should take.

In this episode, Dave Farley, author of the book that introduced Continuous Delivery as an approach, explores these questions and defines a checklist of 14 markers that if you are achieving them clearly state that you are indeed practicing CD and building better software faster. These are excellent tools to help you on your journey and can help you to decide where to next focus your efforts to improve.

-

❗ Continuous Delivery Training Course: Better Software Faster

-

⭐ PATREON:

Join the Continuous Delivery community and access extra perks & content!

-

👕 T-SHIRTS:

A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!

🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery

-

🔗 LINKS:

-

BOOKS:

and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.

📖 "Continuous Delivery Pipelines" by Dave Farley

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

-

CHANNEL SPONSORS:

#continuousdelivery #devops #softwareengineer

[nebukadnezar]

Brilliant, high level overview of CD, love it!

[Resurrction]

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

[JohnnyNilsson]

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.

[brandonpearman]

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.

[bryanfinster]

Thanks so much for the MinimumCD callout!

[jimhumelsine]

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.

[michaelrstover]

I can determine releasability as often as you like. Is it releasable? No. Am I doing this right?

[UWIT]

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

[patrikcarlos]

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?

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

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

[megaman]

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

[polarissi]

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.

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

[INFOXlive]

This makes no sense. Every project is determined by the needs of the customer and the available budget. What is visible here is that the tools/methods have become the ends themselves.