The Difference Between Continuous Delivery & Continuous Deployment
Вставка
- Опубліковано 25 лис 2024
- Continuous Delivery is the foundation of Continuous Deployment. They are very closely related, but they aren’t the same thing. So Continuous Delivery vs Continuous Deployment, what’s the difference and which one is for you?
In this episode Dave Farley, author of “Continuous Delivery” and “Modern Software Engineering”, describes the differences between Continuous Delivery and Continuous Deployment: what each one gives you and when Continuous Deployment may not always be the correct answer. So, if you are a DevOps team applying the software engineering practices that we describe on the CD channel, what is the best strategy?
_____________________________________________________
🎓 CD TRAINING COURSE - "CD: Better Software Faster"
If you want to learn about Continuous Delivery, check out Dave Farley's course where you will learn the 7 Essential CD techniques.
➡️ bit.ly/CDBSWF
________________________________________________
Assess Your CD Capability with this FREE guide from Dave Farley when you sign up to our mail list ➡️ www.subscribep...
The best way to keep up to date with the latest discussions, free "How To..." guides, events, online courses and exclusive offers.
-------------------------------------------------------------------------------------
📚 BOOKS:
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd...
📖 Dave’s NEW BOOK "Modern Software Engineering" is available here
➡️ amzn.to/3DwdwT3
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
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
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ octopus.com/
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️ go.specflow.or...
I think about this in several different stages:
* Continuous Integration - Changes are merged to the main/trunk branch daily, as state in the video.
* Continuous Delivery - The main/trunk branch is always in a state where it can be deployed, even if we don't deploy automatically. Our automated tests confirm this, as stated in the video.
* Continuous Deployment - The main/trunk branch is deployed into production when the automated tests confirm that it's ready. There's an implication here that an organization can practice Continuous Delivery without practicing Continuous Deployment. Deployment may be a human decision rather than an automated one, but hopefully it doesn't require too much bureaucratic overhead.
* Release - This was referenced in the video, but I don't think this specific term was used. Deployed code in production may not be activated. One common technique for this would be Feature Flags, but there can be other techniques too. We may choose to deploy code, but release it in waves or stages with different customers before activating it for all.
thank you!
What Jim said!
I work somewhere with proper continuous delivery practices, and daily releases (unless there is a critical bug in the existing version). I previously worked for a heavily regulated government contractor who organised huge releases every 6 months. My life now is a dream, always working on iterating and feature development. My past life was a nightmare of complex debugging, crunching for deadlines, tech debt, and excruciating meetings with QA people. I would honestly say that the productivity and quality feels about 100 times higher.
This video should be a "must watch" for every junior dev. So much pain could be avoided and much money could be saved. Thanks Dave.
Hi Dave, I’ve finally got a job where CD is set up. Amazing experience!
Great to hear!
@@ContinuousDelivery Thanks! Btw, what do you think about putting QA responsibility on devs themselves instead of separate QA engineers?
Alex-can you share some more details about things that are better from a dev perspective in a CD environment? Just curious about any anecdotes. Thanks!!
@@nicholasprice2128 It will be interesting to see what Alex has to say, but my take is this: The data from the state of DevOps reports says that devs are less stressed, with lower-burnout, have a great sense of ownership of their work and produce higher quality work more quickly. My personal experience has been that anyone who has experienced this, would never willingly choose to work a different way. Basically, it's a much easier way to get things done, so it's more fun and leaves us more of the creative, inventive parts of our job that most of us like best.
@@alex_chugaev I think it is where the primary responsibility should lie, with the devs. QA on the team is often valuable for a different perspective, but I don't think it works if you delegate responsibility for quality to QA. I talk about this in this video: ua-cam.com/video/XhFVtuNDAoM/v-deo.html
I had this exactly argument today with a Azure DevOps trainer. He kept saying Delivery and Deployment are the same and it depends on the "school" you're looking at. He, literally, told me "I found some blogposts...". I had to tell him "Earth is not plane, but if you want to find material tu support your bias that it's plane, you will find it on the Internet".
I sent him the link to DevOps Institute Definition literally...
Thanks for this video! :)
You're welcome!
Lots of time People Say that Continuous Delivery Is only for context where you Need to deploy to user with high frequency.
And so I find myself triyng to explain the difference, as I've learned from Dave.
I think this video Is very useful for that reason.
I think this video Is the right source of clarification.
Working for a safety critical embedded software development company I can very much relate to this. Im trying hard to bring in the continuous delivery culture into my org. It's not easy but it's the right direction 👍
I have been between several projects at a consulting firm. Every time I bring up Continuous Delivery I see the architect’s eyes roll. Everyone says we are practicing CD, but they just point to the tools that enable it. However, the methodology is not practiced: large change sets, pull requests that run for days, and long running test suites that often get built after the fact. I hold out hope that one day I have the leadership to enable the practice of CD. If I ever make it to leadership, then I will encourage different approaches as a healthy way to stay sharp.
Thanks for the content Dave!
Thanks, and good luck in encouraging the change.
I’m kind of ridiculously excited about the T-shirts. Thanks!
Concepts that sound so simple that at first they're easy to overlook, too say of course and move on, but once the mindset really sets in, there really is no better way to proceed than Continuous Delivery. I think not only for software but for a lot of fields in life as well. Thank you for these videos.
Probably, the best contents I've seen in years about SW development. May be since Joel on Software wrote his last article.
Thanks Dave, I think the distinction between delivery & deployment is an important one.
Solid gold content.
I've got some history working to functional safety standards but am now free of those shackles. I can attest that those cumbersome change processes do more harm than good.
Finally, someone clarified it on UA-cam! Thank you :)
Thanks Dave for clearing the most common misconception between Continuous Delivery & Deployment. And yes before I forget, lovely T-shirt (I want one😊)
You're very welcome.
I hope you can get a T-shirt from Qwertee - don't forget to use the code "ContinuousDelivery" at checkout 👍
Automation can be awesome as long as you can trust it and practice it daily. I always aim for continuous deployment in small well-tested increments, but sometimes need to do some compromises. Steady stream of increasing value.
I really like the analogy of Continuous Delivery like studying for a test. It's better to learn the material continuously throughout the course and always be ready for the pop-quiz that can occur at any moment rather than waiting until the night before the final exam to pull an all-nighter cramming session.
I wonder if the analogy continues even beyond the preparing for a test. Those who study continuously tend to remember the content for much longer. Those who cram tend to forget it shortly after the test. Would this aspect of the analogy carry over to production code as well?
The continuous learner is acquiring new information in more manageable chunks through the course. Any misconceptions or misunderstandings can be more easily identified and corrected. Absorbing the earlier concepts makes it easier to build upon the upcoming concepts. The student who crams cannot correct misconceptions or establish foundations to build upon.
Continuous Delivery feels the same to me. You're adding, correcting and learning in manageable chunks. A huge feature branch merges denies us this foundation.
Today, under the delivery topic, we need to consider feature flags. Dark-launching changed the meta, and tools like Launch Darkly made it easy
So very clear! Thanks again.
I always thought CD and CD were synonyms. Thank you for fixing my misconception!
I think you meant “CD” 🤣🤣
🖐
🎤
If you had a 'ctrl (doc), shift (delorian), z(marty)' top, that would be back to the future :D
The tees are definitely the best on this channel
came for the great content, but stayed for the great t-shirt
I'm trying to promote a culture of continuous delivery. So hard when developers don't care to read slack to know they've broken the build and developers pass code to QA that they know won't pass. Maybe I'll need to sit them in a room for a Dave Farley marathon on UA-cam in the hope they'll see the light.
How does Continuous Delivery handle a pipeline that involves a manual/hands-on QA Testing stage before a change can be considered deployable?
It works to eliminate the reliance on "manual/hands-on QA". I talk about some aspect of that in this video: ua-cam.com/video/XhFVtuNDAoM/v-deo.html
Don't forget "Continues Revision" too
very strong, thank you!
Hello Dave, thanks for you channel it is very useful and inspiring. I would like to know your opinion about environments, in the past we used DTAP (Development, Test, Acceptance, Production) but if we are using CD the code should be always in a potential release candidate, so how many environments should we use??
17:58 Risk is not additive although the point is made. If I have three change each with a 50% chance of introducing a defect the total chance of introducing at least one defect is not 3 x 0.5. Instead its 1 - chance of not introducing any defect = 1 - 0.125 = 0.875. A high chance but less than 1.0 :)
Finally!! we get the T Shirts link!
you're welcome!
I understand that this suggestion, aside from any other problems it might have, is already fatally flawed because it isn't already the title of a book that was released more than a decade ago and that we've been talking about continuously (!) ever since, but would it be less confusing to call it "Continuous Deployability" instead of "Continuous Delivery"?
I can certainly see the argument. I guess it is really about from who's perspective you see delivery, producer or consumer. Continuous Delivery & Continuous Deploy make sense from a dev's perspective, but not as much from a users - which given this is a user focused approach is not ideal. "Continuous Deployability" is certainly more accurate, but I don't think that the book would have sold as well 😉
Pretty cool T-Shirt in fact 😄👍
Hi Dave. One question I have is around how to begin using continuous delivery on a new project. On day 1 of the project, I will look to add feature X. This will mean I need to add all of the relevant tests to validate that feature X has been successful. Tests that guarantee security and scalability are part of continuous delivery, so does this mean that I need to add all the security and load testing tests prior to making feature X? In principle this is fine, I just wonder if in practise this means that it can take a long time before the team starts developing new features, which will likely upset management. Keen to hear your thoughts.
I'd recommend that you start simply. I'd aim for a minimal deployment pipeline. Pick a feature that is very simple, but ends up representing a very simple, but architecturally representative version of your system. Write unit tests, and at least one, very simple acceptance test - that forces you to deploy your walking-skeleton.
I have a video that attempts to describe this here (it's quite an old one, so the production values aren't as good as my newer stuff, but the content may help): ua-cam.com/video/x9l6yw1PFbs/v-deo.html
I'd add the security and performance stuff a little later once this part is stable. Don't leave it too long, if these are things that determine the "releasability" of your system, burt don't stress over getting everything perfect on day one!
I sure hope you're getting a kickback from Qwertee, I just ordered over 250 euros worth of tees!
Been looking for a nice shop that sells 'geeky' tees and yes, I had been looking at those fancy shirts you're always wearing wondering where to get those haha!
That’s great, I hope you enjoy them. We do get a small amount per shirt, but mostly we did it for the fun. 😁😎
I have heard of examples of continuous deployment 50 times a day. In an environment where this makes sense, is the implication that the business requirements change 50 times a day? If not, what drives the changes?
Lots of people working on lots of different things in parallel.
@@ContinuousDelivery , So when the business identifies an opportunity that requires new software capabilities, the solution is delivered as hundreds of small changes over a period of time?
@@pyotrberia9741 Not usually "hundreds", but maybe. Yes, that is certainly the principle. In Continuous Delivery circles, we call that "separating deployment from release". We want the freedom to deploy a change in a series of small, incremental, steps, and then release the change to users.
I still find the constantly animated and moving stuff distracting...
It is easier to concentrate on a person talking if you look at their face. However, moving things draw attention => less attention paid to the actual content.
I certainly have seen issues which arised due to the intersection of multiple parts, despite each of the parts being okay individually. While I don't have a good estimate of how likely it is for an issue to emerge given some combination of 2, 3, 4, etc parts, I don't think the growth factor is exponential, otherwise in the real world we would see proportionally much more issues due to very long chains of interactions. I suspect it could be proportional to R_m * (n!/(n - m)!) * p ^ m, where m is the number of parts interacting to cause the issue, and p is the probability of any 2 parts having anything to do with each other at all, but since p < 1, p ^ m is actually an exponential decay, and there is a finite length which causes the maximum number of issues. I got really curious now how the R_m term might be in practice, or if anyone else has some other insight into this.
TL DR: I agree that the more changes there are, the higher the risk of a collision, increasing the total risk, and therefore shipping more frequently is safer, but I don't think the risk growth is exponential, I think it is polinomial and potentially even a high order polinomial.
I just have a hard time accepting that all software can be built in 8 hour increments that are deployable and fully functional at the end of each day. What if the business change requires you to first extend your organization's custom UI framework with a nontrivial new widget type? And that widget alone is complex enough that it may take a week or two to implement, before you can even begin to tackle the business problem that it will be used to solve? Is it better to deploy code that you know is not capable of performing its intended purpose, even though it is not yet used and technically won't throw any exceptions if it was, it just wouldn't give the correct results?
And how much longer will the overall project take if the final hour or two of every day have to be dedicated to ensuring that the thing you're in the middle of implementing is actually fully functional end-to-end right where it is at that point? That time could be spent making meaningful progress toward the target state, even if it means leaving a half baked cake sitting in your local repository overnight, where you will come back tomorrow and resume baking it right where you left off?
I definitely see the advantage to your approach when it comes to making changes to an existing, already-live application or system. But when you're creating something new or working on a major change with real complexity, this approach seems like a somewhat unreasonable burden that will make delivery of the finished product take longer.
And there's also the risk of stakeholders losing faith in the whole endeavor if they keep being given something that is wrong or does not yet meet the agreed upon requirements.
I know that many will disagree with some of my objections, and I am sure that some of this has to do with my own biases or perhaps a need to fundamentally change how I organize a solution strategy or something. I am asking in good faith here, and hoping to be proven wrong. Because, at the very least, this paradigm seems quite difficult to achieve when implementing complex features in applications.
Short answer:
1. You can commit incomplete code as long as it works and doesn't break anything else. If it's complex, very WIP and "not yet usable" then disable/hide it somehow (usually a build/compile flags). Improve and refactor as you go.
2. You don't "check if it works at the end of each day", you check it ALL the time, you make a full local build every 5-15 minutes and then check-in the code and let the Build Management System validate you didn't screw up. That's CI!
3. It works just as well for changing existing code as well as adding new code (that will need to be integrated with the old code anyway). It will often be faster to deliver **because** you know it always works (whatever definition if working you're using). No "test phase", no "integration phase", no "long arguments if we can merge it yet" because it's already integrated, finished or not.
Nothing is free and everything we know how to do takes time to learn. Meaning, going from "sit alone in a corner, coding for days on a personal branch" to "everything always works and check-in the code many many times per day" is hard. Working with TBD and CI practices takes practice, discipline, and code hygiene.
@Daniel Sandberg describes the main solution, separate "deployment" from "release" allow yourself the freedom to create new features in multiple steps, each one of which is safe to release into production.
Your imagined description of working this way lacks something important, in CD we work so that our changes are ALWAYS RELEASABLE, so you don't spend "the final hour or two of every day" checking for releasability, you works so that your automation tells you this in minutes, after every commit. What the data says, and my experience of working this way on complex projects, is that this is dramatically more efficient and effective, not less.
Your last point, "stakeholders being disappointed" is also not born out in practice. Releasing changes more often, in smaller steps, allows us to see, sooner, if the steps are wrong, so we correct sooner. On the whole orgs and teams that practice CD do a better job of building what customers and users need, not a worse job.
You only have to look at some of the orgs that practice this approach to see that it can, and does, work in practice. People use this approach to build all sorts of software, from self-driving cars and self-flying space rockets to finance systems, medical systems, telecoms systems, and the biggest software systems on the planet that we all rely on every day.
frequent small bets vs a black swan
Honestly, I really dislike the name "continuous delivery". Not for any intrinsic reason, but it's misused so thoroughly I've given up using the term correctly (at least within my professional context). I'm new to software, but most of the time I hear it people actually mean some level build/deployment tooling. One of my favorite parts of extreme programming is how unattractive the name is. I vaguely remember kent beck saying he regrets the term "agile" because no one wants to say they're not "agile", leading to profound semantic diffusion, and how XP sounds so bad no one says they unless they actually practice it. I wish CD had a similarly unattractive identifier so that I can at least have an intelligent conversation about it with a broader audience.
So Continuous Delivery is a misnomer then.
Continuous Releasability? Releasable Delivery?
Maybe, we took term from the agile manifesto. I think that it is acceptable. We work so that our SW is always in a releasable state, so we can, continuously, deliver at any given point. So we are continuously delivering workable, releasable, SW, we are just not necessarily delivering it automatically into production. That seems like a reasonable use of the terms to me.
Why not just call it "Continuously Deliverable" because that's what it is?
"Continuous delivery" without being really delivered is misleading.
There is too much confusion and explaining things since things are not clear.
Also, there isn't enough right conversation (both good and bad things) about having "Continuously Deliverable" software because people are constantly trying to get the hang of it.
If we are strong proponents of refactoring, we shouldn't be scared to refactor terms that are not really clear or rather "clean".