14 Step Continuous Delivery Checklist

Рет қаралды 20,068

Жыл бұрын

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
It has never been easier to access my help in adopting Continuous Delivery and receive my one-to-one input. My training course offers you just that. As one of the pioneers of Continuous Delivery, you can be sure of no third-party interpretations or misunderstandings. Study at your own pace, with lifetime access to the information. Find out more about the course HERE ➡️ courses.cd.training/courses/c...
-
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content!
JOIN HERE and start your free trial to see if you like it! There are then options from just £2 a month ➡️ bit.ly/ContinuousDeliveryPatreon
-
👕 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!
🔗 Check out their collection HERE: ➡️ bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
-
🔗 LINKS:
“Minimum Viable CD” ➡️ minimumcd.org/minimumcd/
“Importance of Small Teams” ➡️ www.qsm.com/risk_02.html
“DORA” ➡️ dora.dev/
-
BOOKS:
📖 Accelerate, The Science of Lean Software and DevOps, by Nicole Fosgren, Jez Humble & Gene Kim ➡️ amzn.to/2YYf5Z8
📖 The DevOps Handbook, by Gene Kim, Jez Humble, Patrick Debois & John Willis ➡️ amzn.to/2LsoPmr amzn.to/2LsoPmr
📖 Establishing SRE Foundations, by Vladyslav Ukis ➡️ amzn.to/3MbcT5C
📖 The Phoenix Project, by Gene Kim ➡️ amzn.to/3csuuop amzn.to/3csuuop
📖 Release It!, Michael Nygard ➡️ amzn.to/38zrINu
📖 Specification By Example, by Gojko Adzic ➡️ amzn.to/2TlfYaH
📖 Test Driven Development: By Example (The Addison-Wesley Signature Series), Kent Beck ➡️ amzn.to/2NcqgGh
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here ➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
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:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
IcePanel is a collaborative diagramming tool to align software engineering and product teams on technical decisions across the business. Create an interactive map of your software systems and give your teams full context about how things work now and in the future. ➡️ u.icepanel.io/1f7b2db3
Tricentis is an AI-powered platform helping you to deliver digital innovation faster and with less risk by providing a fundamentally better approach to test automation. Discover the power of continuous testing with Tricentis. ➡️ bit.ly/TricentisCD
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com
#continuousdelivery #devops #softwareengineer

Пікірлер: 46

@ContinuousDelivery Жыл бұрын

❗ It has never been easier to access my help in adopting Continuous Delivery and receive my one-to-one input. My training course offers you just that. As one of the pioneers of Continuous Delivery, you can be sure of no third-party interpretations or misunderstandings. Study at your own pace, with lifetime access to the information. Find out more about the course HERE ➡ courses.cd.training/courses/cd-better-sw-faster

@nebukadnezar4431 Жыл бұрын

Brilliant, high level overview of CD, love it!

@conorh999 Жыл бұрын

Excellent video 👏 Thank you Dave.

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

@michaelrstover Жыл бұрын

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

@ContinuousDelivery Жыл бұрын

" Am I doing this right?" - No! 😉

@AlexandreCassagne Жыл бұрын

First rule: always in a releasable state 😉

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

@qj0n Жыл бұрын

Actually, 'Deployable' as a word means a state when Deploy is possible (deploy+able) which would be almost the same as Deliverable The difference between Delivery and Deploy is that former include all operations needed to give value to a user (hence some people use Delivery Team as a term for Development Team in Scrum). Deploy is just a technical operation of moving code onto a server

@bryanfinster7978 11 ай бұрын

Thanks so much for the MinimumCD callout!

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

@PavelHenkin Жыл бұрын

I've worked with many people like that (usually either older people or youngsters that don't yet know better and don't have someone to coach them). There are the practices, but there are also the principles and discovering those principles takes a large amount of honesty and self-examination, from the lowest personal action level and really up to the societal.

@danielferszt6521 9 ай бұрын

Great video!

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

@andrealaforgia 11 ай бұрын

Every developer working on a different part of the system is not a team. It's a group of individuals each working in their own silo.

@brandonpearman9218 11 ай бұрын

@@andrealaforgia Yeah, so putting pairing aside because thats not relevant here. what happens is a single feature may require additions to different services. a simple example, dev 1 may build an endpoint to return data, and dev 2 calls that endpoint and uses that data. Both are working on the same feature but in different areas of code. Another bad example but more simple to understand would be 1 dev coding a repository class and another coding a service class. They would not bump into each other. Of course they would have built the contracts first as a pair.

@patrik72carlos 11 ай бұрын

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?

@UW4IT 11 ай бұрын

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

@andrealaforgia 11 ай бұрын

There are plenty of examples on the internet when searching for "CD pipeline". Tools, however, are irrelevant. What counts is the principles.😊

@UW4IT 11 ай бұрын

@@andrealaforgia true.. thats why it would be very useful to see some real life pipelines and flow.

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

@logiciananimal Жыл бұрын

I think of it as a hill climbing exercise (hard at first, but wonderful pay off later), after my father's metaphor from hiking. He was an industrial chemist, but many of the general principles in software apply across domains even beyond computing.

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

@GamePlayByFaks Жыл бұрын

Hi, answer is simple keep it simple.

@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

@andrealaforgia Жыл бұрын

Nope, you don't need that. Adopt continuous integration, no matter what the size of a feature is. Big features should still be broken down into valuable slices deliverable frequently and continuously. If you adopt trunk-based development, you can hide any incomplete functionality behind a feature toggle (if there's no other way). The longer you stay on a branch, the later your changes will be integrated, the more serious will be your merging problems, the less confident you are that your complete feature is not going to break other stuff.

@megaman2016 Жыл бұрын

@@andrealaforgia thanks interesting approach

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

@ContinuousDelivery Жыл бұрын

I agree, and I kind of go back and forth on this. To be pedantic, and I think that this is a bit about pedantry and how best to communicate some subtleties. There is a distinction between "releasable" and "release", just because something is 'releasable' doesn't mean that you have to release it. When I talk about things being 'deployable' the pushback I get is "it was deployable to a test environment, it just didn't work". "Releasable" comes closest for me in avoiding misunderstandings, but as you correctly point out, it doesn't get us the whole way. Sometimes human languages are annoying 😉 I have come to the conclusion that there is no simple form of words that will eliminate misunderstandings, particularly when people want to morph the words to fit their interpretation that doesn't fit the intent. Take people claiming to be practicing CI when what they really mean is that they pull to their feature branches from an origin that isn't changing every day. There are some nuances here, but if you so that you create a releasable output every day, you won't be far wrong. I think that the discussion between "releasable" and "deployable" is relevant, but sits most firmly in the "Trunk Based Development" section. Here, one of the strategies is to maintain our ability to make fine-grained commits to trunk, by keeping our SW deployable. I think that there is an annoying a gap between these words "releasable" is nearly right and "deployable" is nearly right too, but neither one completely captures the practice. 🤔

@andrealaforgia Жыл бұрын

@@ContinuousDelivery Should we change "Continuous Delivery" to "Continuous Deliverability"? 🤣🙃

@allenbythesea Жыл бұрын

couldn't agree more 'trunk based'. The git flows out there are insanity IMO.

@CommieHunter7 11 ай бұрын

Git flows have their place. In many web services, there's only one version being served, so GitHub flow/trunk based is fine. Some products which are adapted to specific hardware, and multiple versions are supported do need a more complex source structure

@krumbergify Жыл бұрын

Unfortunately our software needs to by approved by Apple and Wifi Alliance test houses before it can be sent to our customers.

@ddanielsandberg Жыл бұрын

You can choose any build/version that has passed muster during the CD-process and send that. CD doesn't mean that you have to **deploy** all the time. It's the ability to have the option to deploy on demand or (in your case) to send any version you want to certify to external test houses.

@krumbergify Жыл бұрын

@@ddanielsandberg And that is what we do. Unfortunately as I said, it does require addition testing before it can be sent to our users.

@ndewet 11 ай бұрын

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.

@ddanielsandberg 11 ай бұрын

Bob Martin has done several talks about this in the past. On how we'd better get our act together or politicians and bureaucrats will do it for us and Software Engineering as we know it will die.

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

@andrealaforgia Жыл бұрын

Continuous Delivery is the material foundation of agility. Working agilely means collaborating with the customer by releasing valuable working software as frequently as possible, in continuous small batches. The needs of the customer are continuously evaluated and wasting the customer’s budget on potentially useless features is avoided. The tools/methods here are those that enable us to satisfy our customers via early and continuous delivery of valuable software. Do you know a better way of working?

@INFOXlive Жыл бұрын

@@andrealaforgia , your statement “Continuous Delivery is the material foundation of agility”, is already a false. AGILE is predominantly a set of principles that you use to make decisions. Fulfilling decisions creates a material base. The fundamental premise is that you should not be dogmatic, but rather find and apply instruments/methods in accordance with actual aims and adapt constantly to changing environments. CHANGE is a critical component of the agile concept. That is, you can alter the rules, processes, tools, approaches, etc. Whatever is impeding your ability to meet targets more quickly, effectively, and with higher quality should be replaced. That is why all of these "rules" are meaningless.

@deanparker7867 Жыл бұрын

@@INFOXlive This take is utterly ridiculous... I'm sorry, there is no other way to describe it. I have been building software since the early 90's including everything from one-off utilities to enterprise class cloud based distributed applications for companies that you would recognize as world-leaders were I free to share their names. It is TRUE that you can make up anything you want on the fly to suit any individual goal but you are missing the connection between these 14 steps and "freedom" for lack of a better term. You will find that over time, over many different problem domains that ALL of the problems we continually see when doing enterprise work can be alleviated greatly by following these 14 steps in some fashion. There is a a reason that Dave has continually pushed these ideas for years. That is because they work even if you just want to slap together a web app for a locally owned garage using a portable embedded DB, or you want to service all of Europe and Asia with a multi-regional payment system. Sure, for that one-off garage app you make intelligent decisions about HOW you achieve the goals represented by these steps based on cost, scope and other resource limitations but that does not mean that applying ALL of these steps methodically won't result in better software faster most of the time. It will and I can tell you that from almost 3 decades of trial and error. Just like with TDD, give it a TRUE shot for awhile and come back and tell me how you still don't see these as valuable. I can promise you that any series of steps you DO come up with will simply be a subset of what was presented here.

@ContinuousDelivery Жыл бұрын

I think that you have missed the point. These are the tools in the same way that an aeroplane is a tool to take you to any destination in the world. Your response is like "Yes but I want to go to Paris" - yes, any destination! That is what software engineering is for, to allow you to reach your destination, but you are right these are the tools to use to get you there. If you can do these 14 things you will have a better chance of success, whatever the purpose or nature of the software that you are attempting to build. That is why these tools are important.

@andrealaforgia Жыл бұрын

@@INFOXlive I’m amused by your comment 😄. The first principle in the Agile Manifesto states: “our highest priority is to satisfy our customers via early and *continuous delivery* of valuable software”. The fact that software must be delivered continuously is specifically stated in that foundational principle of Agile, so I don’t understand where you see the falsity in my statement. The Agile Manifesto contains a set of values and principles that foster agility: the ability to respond to change quickly. I was asking you a specific question: do you know a better way of working? That’s the opposite of being dogmatic. I’m all ears. I’m open to learning a better way from you. How do you think software should be engineered if not following the points that Dave is mentioning in this video? You say that they are meaningless but you offer no alternative. What do you think is an advisable way to engineer software so to meet targets more quickly, effectively and with higher quality standards?