Continuous delivery vs. continuous deployment: What should be the default?

Episode transcript

Prem Chandrasekaran: Hello, everyone. My name is Premanand Chandrasekaran. Welcome to the Thoughtworks Technology Podcast. This is where we decode all of the buzzwords and deep dive into tech that is shaping our world. I'm joined today by Birgitta Böckeler, who is my co-host. Birgitta, do you want to quickly introduce yourself?

Birgitta Böckeler: Yes. Hi, everybody. I'm Birgitta. I'm a technical principal with Thoughtworks in Berlin, Germany.

Prem: We also have two of our luminary guests today. We've got Valentina. Valentina, do you want to quickly introduce yourself?

Valentina: Yes, sure. I work as a tech lead at Thoughtworks Spain. I've actually been a consultant since I started working and I was lucky enough to work with continuous deployment in many of my companies. I was, I would say, overexposed to this topic, and I'm also working on a book about it. That's what I'm here to talk about today because I've spent a great deal of thought about continuous delivery and continuous deployment, and it's really fascinating. Yes, that's me.

Prem: Last but not the least, we've got Ken.

Ken Mugrage: Yes. I'm Ken Mugrage. I'm in Seattle, Washington. I'm one of the hosts on the podcast, but playing the role of guest today. I was the product manager for a product we had called GoCD for quite a while, a continuous delivery tool. I'm also one of the global organizers for DevOpsDays, so I have some fairly strong feelings on this topic. Glad to be here.

Birgitta: Maybe I can talk a little bit about how the idea for this podcast came about. We're going to talk today about CD versus CD. Continuous delivery versus continuous deployment. This came about because last year, I think early last year, we had a round of revisions and improvements for our Thoughtworks sensible default practices, which is like a set of practices that we maintain inside of Thoughtworks, for software consultancy.

It's like a set of practices that we want our teams to use as the sensible default choices. One of our sensible default practices has always been early in continuous deployment. That was always the title. Last year, there was a huge discussion about if we should change that to continuous delivery. This is how this episode came about, because Valentina also has an upcoming book about continuous deployment. We want to discuss that today.

What are those two things? Is one better than the other? Maybe we can start with those definitions. Maybe, Ken, do you want to start defining continuous delivery for us?

Ken: Sure. I'm going to cheat, though. There was a book that came out, actually entitled Continuous Delivery, in 2010, and I'm going to use theirs. If you look at continuousdelivery.com, which is a website that Jez Humble, one of the authors, put together-- "Continuous delivery is the ability to get changes of all types, including new features, configuration changes, bug fixes, and experiments, into production or into the hands of users, safely and quickly, in a sustainable way."

There's a lot to unpack there, but I think the highlights are all types. It's not just new code. It's experiments, bug fixes, changes, and all that sort of stuff. Then, it says, "Into production or into the hands of users." I'm sure we'll get into the difference between deploy and release later in the podcast, but I think the important thing there is that into the hands of users. You can't know if a thing worked if no one is using it.

Birgitta: I think we're all taking this for granted today, I remember, I think, back when this first came about, I wasn't working for Thoughtorks yet, and one of my colleagues was coming back from a conference where there was one of these seminal talks about continuously delivering to production. That was a time when most organizations were happy when they did three releases a year. This was revolutionary at the time, to actually, automatically, continuously, deliver.

Ken: Yes, it was-- Oh, gosh, I'm going to mess up. It's John Allspaw and another person gave a talk.

Birgitta: [Crosstalk] All right. Yes, that was the one, I think.

Ken: Deploying 10 times a day at Flickr or something like that.

Birgitta: Right. That was the one. Yes, yes, yes.

Ken: Then, if legend has it correctly, Andrew Clay Shaffer tweeted out something and he used #DevOps during that talk. It was interesting that they both started at the same time, literally from the same talk.

Prem: That's awesome. That's awesome. Valentina, you're writing a book on continuous deployment. What are your thoughts on the topic?

Valentina: Yes, I am. At least the way I define continuous deployment, and how I think we mostly understand it within Thoughtworks, is that it's basically an addition to continuous delivery. Actually, I was talking to Dave Farley, who wrote the Continuous Delivery book, about it. He said that the way he sees it is more of a specific implementation of continuous delivery. Let's say this detail aside, it does encompass everything that I think we know and love from continuous delivery.

The way that we want to make the system always production-ready and to be able to deploy on demand, at any given time, for all types of changes. It also has one small addition, which is basically not only every change needs to be deployable to production, but it has to be actually deployed to production once it goes through all of the quality gates and all of the pipeline. This might seem like a very small addition to the concept of the automated pipeline, which is already quite pervasive everywhere.

What I found, especially working in my teams, is that it seems like a small difference, but actually, it implies a lot of changes in the team's ways of working, that I'm happy to elaborate on later. Yes, this is essentially the difference between the two. Continuous delivery, at least more traditionally, stops, I would say, just before deployments to production, even though this should be all done on demand, whereas continuous deployment also, let's say, enforces the deployment to production for every commit.

Prem: Nice, nice. Here is a thing that has always confused a lot of people and probably has been a source of confusion for me as well. There is also this term that we use, continuous integration. Just probably something that was used even earlier than continuous delivery and deployment. What's the difference? We always keep saying CI/CD, almost as if they're synonymous. What's the difference, or is there a difference?

Ken: Continuous integration predates continuous delivery as a term, at least, by a good decade. It's interesting because we do a thing called Thoughtworks Radar, where we call out different techniques, and so forth. We actually put one called CI Theater, or continuous integration theater, on hold, a couple of years ago, because a lot of people thought that if you install Jenkins, you have CI. That's really not the case. It's not a product. Continuous integration is about continuously integrating the code.

I make a change, it gets committed to my main line, trunk, or whatever you want to call it. We actually were recording a podcast yesterday, about pull requests, and is that CI? I'm not going to get in that debate here today, but it really is about continuously testing. Early on, there was a protocol cruise control that came out, I think it was 2001 or so, in Martin Fowler's blog, describing continuous integration, it was about the same time.

We were testing the code constantly and being able to showcase it at the end of an iteration or a sprint, which meant show it to a product owner, but it still wasn't in production. It wasn't in front of users. We were testing it constantly, making sure it worked in a production-like environment and all of those things, but we still weren't actually delivering it. It still might be a year or 18 months before a user touched it.

We found out that-- Hey, it turns out that they didn't want that kind of car. Meanwhile, we spent all of that time doing all of this automated testing that we never got any real feedback on. At Thoughtworks, we had, frankly, a ‘go wrong,’ we call it, when something bad happens. Before I joined, so I think 2006, where we were doing all the "right things--" On an audio recording, people can't see air quotes if I do them.

Then it went to deploy, and it was deploying onto a Solaris environment after being developed on a Windows environment, and it simply wouldn't start. They had to spend a couple of years refactoring it. That led to the white paper that led to the Continuous Delivery book. Very long story, but CI is about the automated testing. What I hated to see at the time, and then I'll turn it over to Valentina, to get to a more recent thing, is that people would add a step to the end.

They'd literally add a simple step that said, "Deploy, and call it continuous delivery." That's just not it. There's more there in that gap.

Valentina: Yes, I think I agree with pretty much everything you said. I would say my personal take on continuous integration is that I see it as more or less the first step in this concept that I think comes from XPU, like doing things more often. To me, continuous integration was always about validating often, that your changes would actually work with other people's changes. Again, don't want to get into the whole debate with trunk-based development, but that is certainly a good way to do it.

You're all committing on trunk. Therefore, you have no choice but to integrate and to do the right thing. Then it's not only the integration, but also the automated testing part, the building an artifact part. I see continuous delivery as a further step, further building block put on top of continuous integration, where not only we integrate and run the automated tests as many times as we possibly can, but also, we deploy to at least the pre-production environments as many times as we possibly can.

Yes, I think maybe all the terms are going through some semantic diffusion and have been maybe confused with having a Jenkins installation ready to go, but I think that there's ways to do continuous integration, delivery, and deployment wrong, even if you have a Jenkins installed, so it's good that we're clarifying them here.

Prem: To quickly summarize my understanding, what you're saying is continuous integration is a prerequisite for continuous delivery and maybe continuous deployment as well.

Valentina: I believe so. I've also worked in teams that were claiming that they do, for example, continuous delivery, but also had very, very long feature branches, and they only claimed that they did continuous delivery because they had an automated pipeline that would deploy on demand. I would disagree with that statement, because yes, you can deploy on demand, but can you really, when all of your code is tucked away in some very long feature branches?

If you need a certain version or a quick bug fix, suddenly, you have to do some very complicated version control trickery in order to get the commits you need, validate them, and make sure that they don't interfere with other work. I would say that that is not really having your code base in an always deployable state, because you're not fulfilling this prerequisite of continuous integration.

Birgitta: It's quite easy for the commits on the branch to not be theoretically deployable, because you feel like you're in a safe environment on your branch. Before we go more into comparison I just wanted to briefly drive one point home a little bit more, maybe. I think both of you have already hinted at it, but-- Very common question we get is, "Why do I even need to deploy that many times?" I think, Ken, you were already hinting at it with the Solaris-Windows thing, and Valentina, you were talking about risks.

Talk a bit more about-- Why would I even deploy multiple times a day when I don't even have a new user feature available?

Ken: Yes. It's funny, because-- We mentioned that John Allspaw talk. A lot of it is about mean time to recovery and fixing problems. When you have issues, and I stress the word when there, not if, how much do you have to do to fix it? If I can deploy into our production-like environment-- In that case, it was Solaris, or what have you. When that fails, if my previous deployment was an hour ago, then I have a smaller thing to look at.

In the case of actually getting in the hands of users, if all of a sudden my sales plummet, because I made the buy button transparent or something silly, I get faster feedback. It's really about the feedback loop. It's about knowing whether it be a system issue, a network issue, a user issue, or a user experience issue. It's really about getting the fastest feedback you possibly can and having the smallest change set in between your last known good and your current issue.

Valentina: Yes. By the way, this is one of the reasons why I like continuous deployment so much, is that fast feedback. That change you have to sort through, if you deployed it an hour ago or one day ago, yes, it is small, but imagine that with continuous deployment, that change consists only of one commit every single time. instead of, say, 5 or 10 commits that have accumulated since your weekly deployment clock that you had with your team.

It really, really shrinks that mean time to recover, because it shrinks the amount of changes you need to sift through, and that way, it reduces, also, the amount of time you need to spend debugging. Also, I think that deploying more frequently is obviously beneficial for the rest of the four key metrics, of which, of course, you mentioned one, but if we look at them, I believe they were deployment frequency, lead time, and mean time to restore we've talked about, and the change failure rate, of course.

Birgitta: Just to clarify, you mean the DORA metrics, right? In Thoughtworks, we sometimes call them four key metrics…

Valentina: [Crosstalk] Oh, yes, for sure.

Birgitta: We know them as the DORA metrics, right? Yes.

Valentina: Yes. The DORA metrics, also known. I think there's a fifth one, but to be honest, I don't remember which one it was.

Birgitta: It's availability.

Valentina: Availability. If I can speak at least the other three-- Obviously, deployment frequency is self-explanatory, I won't even go there, but with shorter windows in between deployments, of course, the lead time for changes is drastically reduced, because the overall time it takes for a commit to go from the developer's laptop into production, that is just shrunk immensely, from a situation where you deploy once a month versus a situation where you deploy multiple times per day.

That enables you to experiment much more quickly, and also debug much more quickly. In teams where I was doing continuous deployment, for example, it was not uncommon to deploy to production one single log line as a commit, in order to understand a bit better what a part of the system was doing, when perhaps we had some doubts about the existing observability.

Also, something surprising was that it really decreased the change failure rate, which might seem counterintuitive, because you think, "Oh, wait, if I deploy to production all the time, doesn't that guarantee that things will go wrong really often?" The answer is actually the opposite, because the bad changes that you make don't really get bundled up with the good changes.

Even if you have, say, 10 commits to deploy, and 3 of them are bad, they contain a bug or some sort of regression, if you deploy with the narrowest possible granularity, then, overall, even with the same three bad commits, you will have a lower rate of failures if you deploy more granularly, and of course, with all the benefits you already talked about, of easier time, debugging, et cetera. Yes, that was a surprising effect on all of the metrics that at least I saw.

Prem: One question I have, and maybe this is a bit controversial. The criticism that I hear a lot of times is that-- If we are not Facebook, we don't want to-- Even if we are ready to be able to deploy, we don't really want to, because our business users don't want that. What's the comeback there, or if I really want to do continuous deployment, are there other things that I need to be able to do so that I can actually be ready for it? Not everyone can pull this off.

Ken: Yes. That's why, when we were talking about what the Thoughtworks sensible default should be-- Which, again, if people didn't catch it, we use the term sensible defaults instead of something like best practice, because there's no such thing as a best practice. That's why I was actually lobbying for continuous delivery over continuous deployment, was for that reason. Releasing software, making software available to users, is a multifaceted thing.

It's certainly the features of the software itself, but it also is, quite often, training of the users, training of support staff, or a marketing event where we want to make a big splash. There's other reasons why you might want to not deliver something constantly, or not deploy something constantly. We were even joking, before we started recording this call, because when I wanted to start it, my Zoom client had to update, because it had continuously deployed during the night, so I was a couple minutes late.

The joke I always say is that-- Part of this is me showing my age, admittedly, package software and large software versus microservices and that sort of thing. Not ready to disclose my age, but I can tell you I worked for an ISP in 1991. I would always tell people, for a website, absolutely, or-- Now, microservice is different architectures, but if you give me a new version of Photoshop 10 times a day, I'm going to be very angry. Part of that is the architecture question, I guess.

Birgitta: Yes. The delivery mechanism. You're talking about a rich client here, right?

Ken: Exactly.

Birgitta: There's also web applications and so on.

Ken: Yes…

Birgitta: That's the idea of the defaults. It doesn't mean you do them all the time. There are always reasons why-- Not always, but there are frequently reasons why you might soften the default, but yes.

Valentina: Yes, I agree. I think one nuance that I would like to add here is what we were also mentioning before, which is the difference between a deployment and a release. I completely agree with Ken, that as a user myself, I don't really want to have to deal with new features released multiple times a day, because, simply, I would not be able to use any software at all.

I think that the continuous delivery already, but especially deployment, it forces you to introduce some mechanisms that separate the concept of deployment and release. In particular here, I am referring to feature flags. I believe that with this type of method, we can basically keep the difference between our code base and production as low as possible without necessarily releasing your features that are visible changes for the users to act on.

In fact, I would even go further to say that I believe deployments should be more technical events that are completely overseen by the engineering team, and they happen on the cadence and at the discretion of the engineering team, whereas product releases-- Changing visible behavior, that needs to have A/B testing around it. It has to have a calendar because we don't want to release several features at the same time, polluting the data from our users' feedback and so on.

I would say that in things like web applications, this comes really easy, when deployments are basically imperceptible to the end user. Of course, in the example of Photoshop, or even harder ones, like mobile apps, self-driving cars, or Smart Toasters, deployment itself can be a disruptive event. That is where we can have more nuance and say, maybe in those situations, continuous delivery is more appropriate than deployment. I think each one can have its own domains, essentially.

Ken: If I could flip sides onto Valentina's side of the debate here, real quick. Another thing about feature flags that is awesome, as we mentioned, is experiments. Using technologies like that, I can experiment, I can say I want to roll out this, or actually deploy this feature, and then release this feature to a percentage of my audience, and find out it's if it's effective before I go out to the other ones.

Microsoft calls it blast radius, but there's lots of things, so-- Very much on Valentina's side here, where if you can continuously deploy, and then use software features to release, absolutely should.

Prem: What I'm hearing from both of you is that-- One, Ken, you said that if you're continuously deploying all the time, it's very annoying for users, and I can relate to that. I use a software called Home Assistant. It's open-source software, which is home automation software. They do releases every month. It's very annoying sometimes. I just updated something, and there's something new already there, and I really don't know if I need it.

What you're seeing, Valentina, is that you can simulate continuous delivery through the use of feature flags, and thereby also get the best of both worlds, where you get really, really good at deploying, and thereby get that change failure rate down, but then at the same time, not affect how end users perceive what you've been doing to control the amount of change that they see. If you want to do it that way.

Valentina: Exactly. The fact that you have feature flags and you do have the production environment, I would even add-- It has some more benefits than simply keeping the code locked in pre-production, waiting for a monthly release. One of those benefits, for example, to me, is when you can, of course, feature flags allow you to test directly in the production environment by enabling certain users to see the feature or not.

I would say that where we can do this, and again, web applications are one of the prime examples, this is an extremely powerful feature. Of course, the more often you deploy, the more you can leverage it, because it means that stakeholders, your product owner, or anyone who's interested in the feature, your QA engineers in the team, they can prove that this feature works in production.

That gives you such a high level of confidence when you really want to enable it for an A/B test or for a gradual rollout, that it's basically almost impossible to see regressions afterwards, because all of those differences that we sometimes see between staging and production have been canceled. Data differences, network configuration differences, they are not a factor anymore.

You can really do all of the manual exploratory testing needed in the most broad like environment of all, which is production, obviously. Lots of power there.

Birgitta: To be clear though, feature toggles are used in both continuous delivery and continuous deployment, or even more so, are needed for both continuous delivery and deployment, because also, for continuous delivery, when you want deployment to be a business decision, you have to have every state of your software to be theoretically deployable, so you also need feature toggles.

If we go a little bit more into the comparison maybe, I was mentioning that big discussion, the internal discussion that we had before, what should be the default. One of the things was about aspiration and complexity, the points that people were making. For example, the proponents of changing the default, our internal default to continuous delivery, said-- Isn't saying continuous deployment is the default distracting from the bigger picture, distracting people, because they have to be more aspirational, think about more things.

Isn't being able to deploy on demand good enough as the ultimate goal?

Ken: We always say, if you put four thought workers in a room, you'll get five opinions, or five definitions, and so forth. We did an infographic a few years ago, that said, "The difference between continuous delivery and continuous deployment," and there was a finger hitting a button on the second one. In an ideal world, to me, the technical of what you do, how ready you are, how prepared you are, and is your documentation done, is exactly the same.

The only difference is that I have said-- Hey, for whatever reasons, for our go-to market or whatever, maybe we're a regulated industry, that Prem has to push a button to make it happen. Prem pushing that button runs exactly the same step as a continuous deployment pipeline would have. To me, the testing is exactly the same. The automation is exactly the same. The only difference is, does the pipeline fire off that step manually, or automatically?

I know that not everybody shares that vision. They think there's a difference in the testing level, or the readiness level, which I'll let Valentina talk about there. If they are are the same, then to me, it wasn't aspirational, really. It's the same pipeline. You just choose whether or not you're going to push the button.

Valentina: I see that point of view, but I would say there is a few differences that I see between continuous delivery and deployment, in terms of workflow. I agree that the quality gates should mostly be the same, because, of course, we always need the observability and automated tests, both at unit level and at higher levels of abstraction, and a real environments, and so on. Fundamentally, what I see is that when you remove that button with the finger on it, that lets your changes go to production.

At least in my experience, some interesting things have happened in my teams, which is one of the reasons I started writing about it. That's where I think the interest lies with continuous deployment. The first difference was, first, there was a bit of a sense of paralysis because, suddenly, there was no more distinction between defining a change that should happen to the code base at some point in time, and applying that change.

The act of developing was becoming simultaneous with production deployments. This had some interesting consequences when we were working on distributed systems, which is the case for most non-trivial systems, of course. Just an example, what happened to us was that before, when we had gates to production, we would deploy weekly, and in one of our teams, this meant deploying all of our systems at the same time, essentially.

Suddenly, however, without the gate to production, one day we had to basically refactor one feature across two systems. That impacted the contract between those two systems, changing a field type. I'm overly simplifying here, but we found ourselves in a situation where we made all the changes, locally, that we could think of. The code base was absolutely perfect in both components, yet we could not find a way to deploy it with continuous deployment because whichever one we deployed first would immediately break the other.

We realized that we were relying on simultaneous deployments, and the ordering of deployments, when we did have a gate to production, because we did have that manual battle. This changed things--

Birgitta: It surfaced a weakness of your existing system that you couldn't see when you had more manual control over it.

Valentina: Exactly. Manual control used to give us some measures to, for example, change the ordering of deployments, or trigger them whenever we wanted, that now we had lost. We had to make up for it with better safeguards at the code level. For example, never releasing software versions that were not compatible with version and minus one of another component, and so on. This is one of the impacts that it had on our workflow. Other ones are, for example, where we did our testing.

Suddenly, our staging environments were becoming a little bit useless, and also what the different phases of our workflow meant. One example of this is, we used to map the columns on our board to specific environments. If something was in QA, it meant it was deployed in pre-production, if something was in done, meant it was waiting for deployment to production, but suddenly, all of our tasks in the progress column were already in production itself.

What were our QA engineers going to do, and where were they going to test? We had to reshuffle a lot of things, just as a consequence of removing that very innocent-looking deploy button. It did end up becoming very interesting, and these topics came up over and over, in all the teams where I used it.

Birgitta: I think some people might say, "Oh, yes, so you had extra effort because you started doing continuous deployment. You wouldn't have needed to do this in continuous delivery." I think there's all of this effort that isn't being looked at before, that is all about cognitive load. Cognitive complexity of keeping all of this in mind, "Okay, you first have to deploy this, and then we do this, and then we have to coordinate, and we have to go on a call."

You have to do that every single time you have the situation, as opposed to doing an automation and improving this setup so it becomes more resilient.

Valentina: I would say the effort doesn't disappear, or doesn't increase. It just moves. Whereas the cognitive load, with continuous delivery, it could be before you deploy your code from pre-production to production. Continuous deployment forces you to shift it during the development phase. I would argue that that is a great place for that cognitive load to be.

Thinking of test coverage, security, interdependencies between systems that you're deploying, this is the whole team of shifting quality to the left, for me, I think there is no more left than the development phase itself, and that's where you can have the most context and collaboration on those changes. I would also say that it removes the temptation to cheat that continuous delivery because it makes it impossible.

Birgitta: Again, back to our discussion. Something that somebody, who was against changing the default from deployment to delivery, said, "If we change this to continuous delivery, is that sending a message to people in ThoughtWorks, that we think continuous deployment is more extreme, it's more of an exception." There were actually quite a few people chiming in about multiple experiences, also, at large enterprises where continuous deployment is the default.

How fringe is this, Valentina? How many companies are actually doing this? Is it extreme?

Valentina: I would say there's a large amount of companies that I found. I know this because I had to collect case studies for the book. It's one of those practices where there's a certain bubble of companies doing it without any problem, really enjoying it, and just seeing absolutely no issue with continuous deployment. Then there's a large amount of companies also, outside of the bubble, who thinks it's absolutely crazy to deploy every commit to production.

Which is one of the reasons I collected case studies in the first place, to show that, hey, this is being done, and yes, it's happening. Just for context, of course, we don't really have data on continuous deployment itself, because studies like the State of DevOps study only specifically look at continuous delivery, which is a more broad term. I don't have exact figures, but I can tell you, in my experience working with companies, that I would say maybe we're spanning five countries.

I'm relatively young in my career still. I still found a dozen or so, just working as an individual developer consultant, within two consultancy companies. I would say perhaps it's more common than a lot of people think.

Prem: I have a two-part question for both of you, actually. Imagine I'm an upcoming startup. What should I do? Should I aspire for continuous delivery? Should I go for continuous deployment? Then the second part of the question is-- Let's say I'm an established business and I've got a bunch of users already, and maybe I'm doing neither. What should I be trying to do?

Should I just go for the ultimate, continuous deployment, or should I say, "Okay, I'll start with continuous delivery?" What's your advice for both sets of teams?

Ken: The correct consultant answer is-- It depends. We have to make that joke in every podcast. In your first example, where it's a new thing, continuous deployment. Why would I create a thick client that has to be downloaded in 2024? It's going to be a cloud-based app, whether it be public or private, is neither here nor there. It's going to be a distributed system. By the way, distributed doesn't mean continents.

It can mean Kubernetes clusters. [Laughs] I think continuous deployment is absolutely the way to go for any new application, using the difference between deploy and release, that Valentina talked about earlier. Then you have to look at-- Okay, what is my-- I don't know what the right word is, appetite for changes among my users, and so forth. You have to decide whether or not you want to roll out new features all the time. As far as deploying to production, that should be any greenfield.

Then your second one is-- I'm going to pretend, even if you didn't mean it to be that, it was a bit of a trick question, because if they have neither, then they probably don't have good automated testing, and so forth. I'm going to say that what they probably are hurting at the most is continuous integration and that they need to worry about testing, and so forth. I think it was Kent Beck that was saying something like-- I'm going to paraphrase because I don't remember the quote, but it was basically– ‘The first step is making it easy to change. The second step is actually changing.’

My guess is, for most legacy stuff, that you need to work on the automation as far as the testing and that sort of thing goes, and the ability to make quick changes, the ability to either deploy or deliver on demand. It's very unlikely they're ready for either CD. My guess is that you really have to go back deeper than that.

Valentina: I would agree. If I could offer an order for at least the second scenario, I would definitely look after continuous integration first, with all of the test coverage that comes with it, so agreeing with you there. Then, moving on to automated deployment, on-demand with continuous delivery. Then, if, and only if all the quality gates are top-notch, maybe moving to continuous deployment, if it applies to the type of company.

Of course, we discussed several domains, several types of application where that is not feasible. Going back to the Photoshop example, I would recommend the continuous deployment only to companies, regardless of their maturity, if they have full control of their production environment and that production environment is not, for example, in the user's hands, like a mobile phone or desktop application.

Ken: I think I'd also like to add-- I was actually at a conference yesterday, and Nathen Harvey, who runs the current DORA Project at Google, was there. Somebody was asking about some of the metrics and so forth. It was specifically a legacy-type question. He made the point, and I really, really liked it, that he would rather see 20% improvement for a team than the highest-scoring team on the metrics, if you will.

If you're in that second situation that Prem mentioned, getting better is the next step. Maybe it doesn't even make sense for you to try to get to a, "I'm going to deploy to my users every month," if you're at a year and a half now. The point is incremental improvement. Getting into the hands of users faster, getting faster feedback, reacting to market changes, political changes, economic changes, and et cetera. Don't feel like it's an all-or-nothing. Getting better is a great next step.

Birgitta: Maybe I can round it up by actually saying what we decided for the Thoughtworks' sensibility for our practices, because I think it's a great example of the, "It depends," problem, and how, ultimately, it's really all about the context. These default practices in Thoughtworks are for a consulting company, they're not for a particular client. We also went back to-- Why do we have these in the first place?

It's one of our artifacts of our communities of practice. It's also about showing people what skills they should actually develop, what they should be able to speak about articulately with our clients. Also, they're about us having an aspiration to continuously impact the craft and influence the industry as well. That's why we actually kept it at early in continuous deployment, to say, "This is the best thing that helps us grow and advance the practice."

Also, for me, as the community lead at the time, it's actually something that, then, people continuously start discussions about, and actually have discussions, engage, and learn from each other. That was the ‘why’ behind, in my particular case, which is potentially different from an organization who wants to set a default for their new teams. It can also be, in some teams that makes sense, in other teams, it doesn't. As always, we have to think about the why in our context, and not just about exactly what's in the book.

Premanand: Well, thanks a lot, Valentina and Ken, this was really, really fun. What we seem to be saying is that continuous integration, continuous delivery, and continuous deployment, all three of them are worthy things to take up. What you will choose to do eventually, in your context, will depend on a lot of things that are realities for you, but the bias thing is to go for continuous deployment and make it appear as if you're doing continuous delivery through the use of things like toggles, and so on, so forth. That's me. Your realities might be very different.

Birgitta: I'm looking forward to reading your book, Valentina. Do you have a target date when it's coming out?

Valentina: Yes, actually, it's already available on Amazon for pre-order. I don't remember if the target date is August or October. I am a bit ashamed of it because that's something I should know, but you can definitely pre-order it, and there's a preview online, on the early learning platform, so if you have access to that already, or you want to do a free trial, you can already find there, an early release version, which is not edited yet, and the figures haven't been redrawn, but you can still read it.

Birgitta: Looking forward to it.

Prem: Thanks a lot, folks. It was really fun, and we look forward to the next episode.