Continuous Delivery Pdf Ebook Download

Low risk releases. The primary goal of continuousdelivery is to make software deployments painless, low-risk eventsthat can be performed at any time, on demand. By applying patterns such asblue-green deployments it is relatively straightforward to achievezero-downtime deployments that are undetectable to users.

Higher quality. When developers have automated tools thatdiscover regressions within minutes, teams are freed to focus theireffort on user research and higher level testing activities such as exploratorytesting, usability testing, and performance and security testing. Bybuilding a deployment pipeline, these activities can be performedcontinuously throughout the delivery process, ensuring quality isbuilt in to products and services from the beginning.

These systems can be successful if they are agile. Providing continuous delivery of updated software to customers can create unmatchable satisfaction and success. This whitepaper by Tech Mahindra explores the ideas and methods of execution for DevOps and Continuous Delivery. Learn the various functions and challenges you will interact with when you deploy a DevOps culture.

Continuous integration, continuous delivery, and continuous deployment are key software delivery processes in a DevOps environment. But what does each one do for your product development and release cycles Brent Laster explains what these terms really boil down to, and how they work separately and together to help your team release software.

Pete is a good friend of Thoughtworks, used to work with him very closely, obviously quite aligned with, I would say, Thoughtworks worldview on things and the right way to build software. And today's episode is called, Continuous Delivery in the Wild, and we're going to be talking to Pete about a recent ebook that he's written for O'Reilly talking about continuous delivery. Pete, why don't you tell us a little bit about the premise of this Continuous Delivery in the Wild book that you've written

I spent quite a lot of time talking to people about continuous delivery and hearing thought leaders and stuff like that talking about continuous delivery. And what I notice is people spend a lot of time talking about the cutting edge stuff like really advanced engineering orgs are doing, which I think is great. But I don't really hear that much being talked about about just companies that are just quietly doing this stuff well and they might not necessarily be doing the most amazing, cutting edge practices, but they're succeeding really well and they're getting the value out of these continuous delivery principles without necessarily doing all of the whizzy, super fancy stuff that you'd go to a conference talk to hear about, although maybe you should be going to a conference talk to her about the successful stuff.

The premise was I want to get a real talk, not conference talks. And so, a company called Split sponsored this little project and I went in and found a bunch of organizations that were succeeding in continuous delivery by my own definition where they were releasing to production at least once a day, often more than that. That was the criteria, but besides that, that criteria, the people I talked to were quite varied. They were like big enterprise-y companies, little start ups, companies that have been around since the fifties, companies that have been around since last year. I got a really wide range of companies, but all of them, this unifying thing where they're all doing pretty well with CD. And I just basically spent some time with a bunch of the teams asking them how they did CD or how they did software delivery.

That was my criteria for companies that I feel like are succeeding with continuous delivery to some extent. The way I would define continuous delivery, and whenever I'm around Thoughtworks people I always get a little bit more nervous about sticking my neck out, my working definition continuous delivery is that you're able to release code from your main line branch or master or your trunk or whatever, wherever you release into production, you feel confident that at any time you could deploy from that code from master to production. That's, to me, is the central thing. And there's a bunch of like principles and practices that are mixed in there, but I think that's the definitional thing for me, I think, for continuous delivery.

Absolutely. Yeah, no, I think that's totally true. There isn't anything, definitely not as far as I'm aware, in that original book. And I think really in the principles of continuous delivery it's not about you must be able to deliver every X days. Particularly when it was first becoming popular, I think a lot of it was about exactly what you're saying to giving power back to the product owner or whatever to release software at the pace that felt right.

And a lot of the research that Nicole and Jez and Gene Kim did with that amazing Accelerate book and the DevOps report, I think what has emerged is there's some value in giving control back to product people. But I think there's this really like interesting, maybe it was originally understood problem, maybe it was by smart people, it's not intuitive to me, but there's this really interesting thing that by compressing that feedback cycle, by allowing yourself to release more frequently, you end up releasing more frequently and then you get these really interesting effects around reducing batch size and smaller changes going out. And nowadays. I think there's some confusion or at least there's some stuff gets mixed up in a lot of people's brains between continuous delivery and continuous deployment and this idea of frequent releases, et cetera, et cetera. And I think that's because people who are doing continuous delivery and have the capability to release whenever they want realize that using that capability to release a lot is really, really useful. And so they do it.

And so people see, oh, people who are doing continuous delivery are releasing all the time. Therefore, continuous delivery is releasing all the time. And I don't think that's exactly right. I think it's actually about the capability to do that. And what ends up happening is most organizations do that because it's super valuable to be able to have small, rapid flow or a frequent flow of small changes into production. It's super, super valuable. And that was definitely one of the things that when I was talking to these organizations as part of this book, the super common theme was the value in reducing batch sizes.

One of the things I think is really interesting around CD is the relationship with CI, continuous delivery and continuous integration. Nowadays, again, a whole other podcast series about what does CI mean because a lot of people would say it's Jenkins or Travis or CircleCI, it's in the name. And the curmudgeons that came up with the term would say like, no, CI is a practice, it's about integrating on a daily basis. And so I've wandered for a while, do you need to do CI in order to do CD If you define CI as I'm integrating my changes into a shared main line at least once a day, do I need to do that in order to be practicing CD And I had this hypothesis that no, you can actually succeed with CD without doing true CI in terms of merging all your stuff, at least once a day.

A few of them were doing trunk based development and were having a great deal of success with it. And in general, the ones doing trunk based development, I would say, were doing better in general with continuous delivery and were able to release more frequently. They were getting to the point that they were getting to like single piece flow. Literally, I have a commit, and commit, I walk that maybe one line change all the way out to production, which is great. I didn't hear anyone saying like, yeah, I wish we weren't doing that or like we tried that and it didn't work. Everyone who's got to that point, I think they were happy they were there.

There was a lot of stuff that was that reinforced existing things that I would have believed, like people doing trunk based development were doing great, generally were happier. A lot of the standard practices that I've seen in general people applying when they're trying to get to continuous delivery, so brunch by abstraction and feature flagging, all of those kinds of techniques were definitely in play. I think I was surprised that there was actually less focus on those branch by attraction techniques than I would have guessed. And I think that was generally because a lot of times when I saw not that much feature flagging going on, it was for younger startup-y orgs that were quite happy to just be blasting out features all the time and didn't really feel like they needed to put that much control on when a feature was rolled out. That was a little bit of surprise.

Cool. And one thing you did touch on that, but I'd love to explore that a little bit further. You talked about different types of companies, different types of architectures. Is it so that you have seen high levels of maturity with new and old companies, small and big, different types of architecture Because sometimes we get this myth that, oh, I am this kind of company, I have this kind of legacy of history, therefore, I cannot get to a high level of maturity on continuous delivery. What did you see related to this and that variability

And how about the value aspect, Pete You did mention, going back to what we were discussing, the definition of continuous delivery. Companies who had the ability to deploy frequently usually leveraged that and just the value of that. What have you found related to that Are companies extracting value and business value out of this Is this something the IT department is pushing and the rest of the company doesn't get it What did you see connected to that

There you go, DevOps Research and Assessment, Nicole and those folks did actual science, which demonstrates that reducing softwar