The State of Continuous Delivery Report 2023 – The CD Pipeline EP 7

Hey everyone. Welcome to the CD Pipeline. I'm Alan Shimel, CEO O of Textron Group, and CD Pipeline is a, a joint production between Textron Group, Textron tv, and our good friends at the CD Foundation, which of course is part of the broader Linux Foundation.

For those of you who are interested in the CD foundation and finding out more, let me just tell you right from the top. If you go to CD Foundation, you can get all, everything you want to know about the CD Foundation there. CD Pipeline is a once a month show that we, we put on here at Text on tv, along with the CD Foundation, where we explore different relevant topics to those of us who, you know, exist within that C I C D market and the C I C D community of which it's ever growing and, and many, many people strong.

Um, today's show is about a recent, uh, study and research report that was released by the CD Foundation along with a partner. We're going to hear more about it in a second. Let me introduce you first though, to today's panelists and our show members.

Um, first gentleman is Liam Dodd. This is Liam's first appearance on the CD Foundation and we have, uh, given him the usual rookie razzing and, but he's still in here with us. So, Liam, welcome to CD Pipelines and if you wouldn't mind sharing a little bit about yourself.

Uh, thank you. I'm excited to be on my first show. Uh, yeah, so my previous life I was an academic at Stern, but I've now since left to work for slash Data as a senior market research analyst.

Um, I'm currently based in the north of the Netherlands in a small city GaN um, and I was the author of the State of the CD report. Fantastic. And thank you for joining with us today.

Next up, he's a repeat panel member here on CD Foundation. He's very involved in the foundation, and it's our friend Steve Fenton. Steve, welcome a little bit about yourself.

Uh, hi, I'm Steve. Uh, I am on the CD Foundation Outreach Committee and I'm a programmer and author. Been doing that for a couple of decades.

I currently work for Octopus Deploy and, uh, I'm quite excited to talk about the CD report today. Hence the cute little octopus on your shirt there. Fantastic, Steve, thanks for joining us.

Next up, he's also been on our panel before. He is a pleasure to have on, uh, Andrew Fong. Andrew, welcome a little bit about yourself.

Thanks, Alan. My name's Andrew, as you said. Uh, right now I am c e o and co-founder of creda, where we have a mission of intelligently delivering software with zero overhead.

Uh, prior to this, spent the last 20 plus years in infrastructure at places like Dropbox, where I ran it, and then YouTube and AOL before that. Hey, Andrew, I'm sorry, the name of the company? Prana.

With a P. With a P, Okay. Just wanted to make sure people got that.

Okay. And then last, but certainly not least, she, uh, has filling in for some big shoes today. I appreciate her coming on.

I want to introduce you to Melissa McKay. Melissa, welcome and a little bit about yourself. Thank you, Alan.

Yes, I am filling in for Lori LaRusso today. She is a colleague of mine and definitely big shoes to fill, so I was happy that she asked me to, uh, fill in for her. Um, I am currently a developer advocate for JF Rog.

I've been that position for three years now. And prior to that I was a software engineer and developer for over 20 years. So lots of time in the industry, um, all the way from the intern level to, um, to Principal.

Principal. Thank you. Can't even remember where, where I went.

Anyway, I'm really, really interested in talking with you folks today with Andrew and Steve and Liam especially cuz I've read this report and, um, so to speak. I'd like to hear from the horse's mouth, um, your insights and your thoughts when you've put this report together. Absolutely.

Okay. So we, you know, we've spoken a little, we've referenced this report, but Liam, you're, you're the principal author. Let, let's get your take.

You know, what, what is, what, whats this report about? Why is it important? Why, why should our audience really care about this?

Well, the, I think there's kind of two major things that I think the audience take away from it. Firstly, um, obviously DevOps is a relatively newer field, but now is a very established practice within developer communities. I think that anyone involved in DevOps or interest in DevOps or any level of like developer probably now wants to know what is going on in DevOps and why people are doing the things they're doing, even if it's just to, to learn more about maybe what they can implement in their practices or trends that are occurring.

And I think the second one is, as a CD foundation talks about like developer velocity is this thing that there's a kind of consistent tracking of an interest in and trying to understand what impacts developer velocity and what doesn't impact it or what has greater impact. Um, and we do a bunch of look tests looking at different factors that may be driving developer velocity and also kind of commenting on why we think maybe it's a bit stuck at certain points and hasn't changed at the top end. So I think people who work in development or interest in velocity and interest in DevOps can get quite a lot from the latest report.

Fair enough. Excellent. And, um, just in the way of background, where did the data from this report come from And, and like how big a dataset is it?

And can you give us some background on that maybe Later? So every six, yeah, so every six months, uh, slash data runs, uh, the developer nation survey. We're actually currently running the next one.

So if people are interested in, uh, filling out and adding to the data set Developer nation, um, they can find us, um, to fill out the survey. We ask hundreds of questions across different branches and obviously a section of these are focused on DevOps and um, kind of aspects of DevOps like technologies, um, restore time, so on and so forth. So we ask that every six months and we've been doing that for the last five surveys.

So two and a half years of data. We get around about 25,000 like usable responses each survey, which obviously makes it one of the largest, like continually running surveys of developers that exists. And then from that we obviously do statistical modeling, some weighting, some cleansing to, you know, make it usable and, and uh, kind of meth methodologically stable statistical.

Um, and then from that we do various analysis based on it. So this one we have various questions to ask about, um, time to restore time, lead time for coach changes, and then technologies they're using and like what specific technologies they're using. And from that, then we pull this data together and we also rotate questions in and out.

So there's a question about application security testing that we kind of rotate in and out, so we can't get give it every year, but we can give quite consistent updates. So data like that. Excellent.

Love it. So Steve, Andrew, you guys have had a chance to review the report, right? You probably have a different perspective of it than Liam obviously, who's, you know, sometimes you get lost in the forest for the trees, right?

When you're writing the report. Steve, for you, what was, you know, if you had a, the big takeaway for you, what was it? Um, there were probably two things that really jumped out for me, um, in this report.

One was, there's some really interesting information in here about the link between tools and performance. Um, and you kind of have to delve into a little bit, but there's, um, a, a, a limit basically to the number of technologies a single developer can take on before it starts becoming a problem for them, which I thought was interesting. But there's also some information in there that says that as a team, if you're using um, too few tools that can be a problem as well.

So there's like an interesting tension between the data there. It's like you need to use tools that help you do your job better, but you can't just like stick that all onto a single person. I think that's like quite an interesting piece of data to come out of this report.

Um, the other one was related to the security actually, which Liam mentioned. Um, it jumped in as being one of the top, um, uh, capabilities that people are using is actually security testing. But even though it's really high up there, it's still only 37%.

And it got me to thinking out of all of the software that I'm using, it's only 37% of it getting security tested. And that made me slightly nervous. So those were the two things that really jumped out at me from the report.

Agreed. Andrew, what about you? I think the thing that jumped out, there's two things that jumped out to me.

One is exactly what Liam said about lead time to recovery and frequency of changes. I think that's actually really nice to see, get a lot more publicity. It was something we focused on a lot at Dropbox and YouTube was just the amount of times we pushed code a day.

And just actually seeing this data at a larger dataset size actually really, really useful for the community, I think at large to understand that it, there's benefits to that. I think the other piece, um, that was very interesting to me is that was around the microservices aspect. Um, because I think right now, and you know, I think Amazon has popularized this in the last couple months where there's now a tension between monolith and microservices again.

And this report very clearly says time to restore for low, like is, is is higher for people that are not on microservices. I don't know in practice if that's actually true. Um, I think that this is a, this sample may be biased, a bit towed towards legacy pro players and if you sort of, if you put some other data on top of that, um, tech board companies that are monolith may actually show that time to recover is actually faster than microservices.

Um, and so it was a kind of interesting tension here where the data may not always show. Cause anecdotally every company I've worked at, um, has always started with a monolith. It has almost always had very low time to restore.

And so there's like a little bit of tension here in the data where it's not necessarily microservices versus monoliths. It should probably be sort of weighted towards to how you look at it culturally or how you're looking at your architecture versus your business. Melissa, I see you shaking your head 20 years intern the principle.

Do you agree with Andrew's? Cuz you know, Andrew's kind of reading between the lines a little here, and so I'm gonna ask you your opinion then we're gonna ask Liam what if there was anything in the data that he can kind of cite for this. But what do you think, Melissa?

Yeah, absolutely. I I do agree. Um, I appreciate, you know, how the data and the analysis brings in the Dora metrics and I just wanna clarify that that's what we're talking about here in case there's anyone in the audience that doesn't know, um, um, pretty, you know, that's the premise and we're trying to, you know, link the data with the metrics and, and how well, um, teams can move forward with that.

Um, one thing that hit me about the report is just like development team dynamics. Um, the stat that really, um, brought that home to me is that there are so many developers now that are saying that they're doing DevOps activities and, um, I think some of the numbers are, you know, maybe only 16% now according to this latest report, say that they are not involved in DevOps activities. Um, that's really interesting to me just because since I've been so long in the industry, I've, I've had a lot of the time in the beginning when, um, DevOps wasn't even coined yet.

And then later on in my career where I all of a sudden had to add to my toolbox a lot of, um, DevOps tools and methodologies that I wasn't familiar with in the beginning. So, um, you know, for Liam, I would love to ask you for the purposes of the report. Were, uh, respondents able to choose more than one role when they, uh, indicated, you know, what role they played on a development team and, uh, what would be an example job description of someone who says, you know, they are a DevOps, uh, engineer or expert?

Um, so yes, dev developers, we, the way the question asks them, like can hit select from, we give them several options plus an other where they can fill in whatever an exotic title they think they actually deserve. Um, but generally there's multiple options and we find that most developers, I think it's, I think it's just under two, is the average number of people selecting this. So most people say I'm a programmer and a thing, or like, I'm an architect and like a thing.

Like, it's quite common for, to see more than one option selected, which I think matches how developers like react in the world. Like a lot of people actually clinging to the programmer title even long after it stops being their direct role. There's a lot of people you see who are programmer CEO management, which depends on the company.

Um, but we see that a lot. So there's a lot of people claim to that title. Um, in terms of what the, the job title when it comes to DevOps engineer, dev specialist, generally you see these people have a lot more DevOps involvement in activities.

So, um, for example, like you may, like, if you do like a look, look at sample of developers who are involved in DevOps, you might find that like, oh, we mostly use infrastructure stuff, or we mostly do C I C D stuff. And then you find DevOps engineers, DevOps specialists, and they'll have multiple parts of DevOps involvement. They'll ha they'll be involved in many, many layers of it.

They'll also be often using more tools and often using like a wider range of tools as well. So it's generally just that from what we see in our data, and obviously there are, there's always exceptions to the rule, but in general, DevOps specialists pick more tools, do more activities, and I'll just generally more DevOps in their role. So yeah, You know, interestingly, I, I actually saw, and it might have been under embargo that I saw, so I'm not gonna mention names or anything, but, um, I saw another report that came out.

I, I think it's just coming out where very similar 84% of organizations said they, they, they're doing some DevOps may not be, you know, Liam's point DevOps experts, but you know, developers are working on DevOps and, and, and this particular, uh, survey was around platform engineering and how many of them are adopting sort of platform engineering type of, uh, functionality. And it, it's not that it replaces DevOps per se, but sort of an extension of and just, you know, letting developers develop and, and speeding up that whole thing. com and, and we first published it in March, 2014, so about nine years now, uh, ago that we published.

And, um, at the time there were many companies that I would interview at conferences in person or online who would say, I don't want to publish, I don't want to deploy 10 times a day. I don't want to deploy one time a day. I used to deploy once a year.

If I deploy once a quarter, I'm probably doing too much, right? Cuz we don't want to be Google and we don't wanna be Facebook and we don't wanna be one of the hyperscalers, we're we're not unicorns, we're horses. Right?

And, and, um, but as we sit here today, nine years, 10 years later, you don't, you don't hear that much anymore, right? Almost to the contrary as, as kind of counterintuitive as it might be, the more you deploy, the more stability you have, the more security you have, the more a lot of things you have. You know, when, when did that become sort of the orthodox view versus the radical view?

Andrew, you've, you've, you've been here a long time, not, not just on this show, it feels like we've been here a long time, but in the space a long time. What, What do you think? I I actually would reframe it as to, I think deployment is a capability, um, and the ability to deploy frequently is a capability you want to have in your toolkit.

Um, it's not necessarily, I don't think of deployment frequency as a goal. I think of it as you have to define what your business needs first. Um, and you look at it from that perspective and work backwards and then you say, okay, how frequently do I need to deploy to meet my business goals?

Because there are some industries, right, like that probably don't benefit from highly frequent deploys, right? If I think of traditional manufacturing plant that wants to adopt a SaaS piece of software, it's gonna be very hard for them, right? Where if change management can only occur once a quarter because there's a physical process involved with change management, but then, you know, you on the other end of the spectrum, you have SaaS providers, right?

That are, you know, they're looking at it as, okay, I want to continuously update this all the time for deployment frequency For them, the capability there needs to be very high. And I think it's really important to use that frame of reference as opposed to say there is a true be all and end all of deployment frequency as our end goal. Uh, I actually don't think deployment frequency is the end goal.

I think it's actually understanding your business ca the capability you need to provide back to the business and DevOps needs to provide to the business Fair. Steve, what do you think about that? Yeah, I'd build on that.

I think, I think that's the, the right idea. I think the difference is those people you were talking to a few years ago, um, really if, if they had said, we do want to deploy weekly, the fact is they couldn't have done it, right? They didn't even have the capability to do it.

Once you can deploy on demand, like if I decide to go live, I can be live like by pushing a button and then in an hour everything's updated, then it actually turns it around and makes it a business problem. Now. Yes, not technical problem, it's not how often can you deploy, it's like, what do we want to do as a company?

So yeah, you wanna make it a choice. I agree with Andrew. Yeah, exactly.

You wanna make it a choice. Absolutely. Um, Liam, every time, and I do a lot, I speak to a lot of people around reports and everything, usually in every report and dataset, there's one, at least one.

Whoa, I I didn't see that coming, right? That, that surprised the heck outta me. What was the big woe for you here?

Um, I'll do, I'll do the little woe first and then the big wo. Okay. But the little woe was enough.

The time to restore, time to restore service, uh, is so fickle in terms of what can set it off very quickly in directions. Like it's the one you see the biggest fluctuations with in both negative and positive. Like what causes it to go, which I think is like an interesting part of the Dora metric.

But the, the big one for me was we, we, we give a little teaser and look at application security testing and like how different types of testing and whether done manually or on a automatic kind of concurrent basis. And it was interesting to see that there wasn't, it wasn't necessarily that doing testing or not doing testing or doing it manually with guar doing automatic was guaranteed to be a better, like, performance behavior. It was kind of a much more subtle difference, like, which I think we did highlight deliberately.

Like testing is obviously very important. It's a very crucial part, but when you do the testing and how you do the testing, I think has a major impact. I think Andrew's been talking about stuff like capabilities, like they, they should be a choice.

Like you're sure you can set up a bunch of automatic tests to do all this like API security testing, but if you don't need to do that or if that's gonna add huge amounts of workflow issues, there may be a manual testing that works better with your deployment frequency could be a much better solution. So I think that one caught me off guard. I wasn't expecting it to be so nebulous and so inconsistent with how it worked.

Excellent. I love it. Um, you know, it it, it's interesting too, again, somewhat counterintuitive, Steve, Andrew, was there any kind of big whoa surprises here for you that you saw?

Um, I thought, uh, one of the interesting ones for me from this report was, um, I think the number was 84%, um, of developers said they were doing some aspect of DevOps, um, but only 22% were found to be doing proper, um, continuous delivery. So the build and the deployment of their code to production, um, was kind of fully automated. And I thought it was interesting that, um, there's this big gap where people could be doing better in that.

And this is like the CD pipeline show. This is one area that a lot of teams could be doing better and I think maybe a lot of the other numbers might be different, um, if people had been doing more of those CD practices. Um, so yeah, I thought that was kind of low number compared to the high number for people saying they were doing DevOps.

I, I think that's a testament to this big umbrella that DevOps has become. Right? com, I remember a guest once telling me that DevOps is the si, I may screw this up, I hope not.

DevOps is the symptom. C I C D is the cure. And uh, you know, but today when we talk about DevOps, we talk about things like s r e and we talk about things like platform engineering and we, you know, we talk about observability and cloud native and you know, all of these, I don't know if ancillary or adjacent is the right word, but they're all kind of under this umbrella and, you know, but at its heart, DevOps was about pipeline and cd, right?

That, that, to me it was anyway. And I, I think that might be part of the reason we see that. Andrew, Melissa, you guys are both, you know, seasoned veterans.

What, what do you think? Yeah, I, I think, you know, a lot of the history behind where DevOps came from and where even, you know, continuous delivery came from and all of those concepts really came from business issues down. Because I mean, if you think about it, the reality of most of these, you know, enterprises, they want to get something out to market quickly.

And, um, to be able to do that, it needs to be deployed quickly. It needs to get in front of their customers quickly. Now how do we make that happen?

And that's when we start getting it, these DevOps methodologies in there. We get automation in there, we get the deployment frequency in there. And this then allowed for experiments on the public, on the, the market share that they were, um, you know, that were their audience so that they could decide whether or not they were going in a, in a, the right direction and pivot quickly if they were not.

And that is the point. And so, um, back on, you know, the idea of deploying frequently, I, I always pair that with small changes at, at a time. Um, if the cost of deploying is too great, that's when you get into these situations where you don't deploy very frequently because you don't have automation in place, it costs too much to have everyone manually together in the room to make a deployment happen, costs too much to, you know, shut the whole system down and wait while the deployment comp completes.

So I've really been interested in how things have changed over the years, um, and, and how now we're focused on these small changes and being able to pivot quickly. Fair. Jude, your thoughts?

Um, I was gonna take it back actually, actually to what you were asking earlier about like surprising things in the report. Um, I was actually just looking at this. One of the, the one of the things that's very interesting to me is that the data shows that enterprises are still showing a lot of improvements, but the mid-market sized organizations seem to be flat lining or they've adopted best practices as they've come up.

And so really where you're seeing still the big gains is enterprise, but as a, as a movement, like their best practices are being very ingrained inside of, uh, inside of the newer organizations, which probably leads more towards, like, they're looking for efficiencies now there as opposed to like best practices on delivery, um, or deployments. Um, which is like a really interesting thing that a sort of trend that's actually, I think also that's occurring these days is that that efficiency, the efficiency play is like really, really important to people. Um, and it's probably driven by that they have best practices now cuz this report's showing that like, if you're a mid-market, you probably have it.

Yeah, you know what guys, but I can't help, I'm gonna be honest, right? There is a, a certain corner of the audience and, and it's kind of what Steve said before, which is, you know, what, our DevOps experience hasn't been stellar. How a DevOps work has not yielded the kind of results that all those high performing IT teams in the DORA report seem to, to be seeing.

And we, I don't know what exactly we're doing wrong, but it's just not working for us. What, what can we, you know, and, and you know, right or wrong, I'm married 33 years, I've learned, don't tell people how they feel. Um, but, but what do we, what do we say, what do we, what, you know, is there, is there good news in this report that we could share to help those people?

Liam, you wrote the report, This was Yeah, yeah, yeah, yeah, I think so. I think there's like, there's two things that I think that can be helpful. First one is to look at, um, the, the concept of a broad kind of base of DevOps technologies having a much more positive impact than focusing on one or two small technologies or just focusing around that.

I think, I think that's the thing that people can take aware of with the caveat that like, interoperability can massively undermine any strengths you, you take. So I think that's like the, when it comes to actual useful advice, I think the second one is when we also caveat several times when we talk about the Dora metrics is that the top performing group for some groups is quite an intense level of like performance. This is like, like multiple deploys a day rather than like, rather than like deploying multiple times a week, there are restore times that have like almost immediate restoration of times.

They almost immediate lead times are code. So these obviously metrics are very good. They're like good, the good way, quantizing velocity.

But if you are like in a second top performing group, that might be what, as Andrews mentioned before, and Steve is sort, well that might be what you need in your company. Um, and then when you add other things, like we haven't, we we're investigating this a moment, but like the concept of security moving between, uh, main teams like security teams and security being done by the developer. If you put a security team in place, you have more secured code, but you have a slower deployment, slower lead time, longer hand restore.

So you have to consider what you are aiming at these targets for. Because if you're solely just trying to hit the top group for the sake of being in the top group, you may be missing the actual benefits you can give to your company. I'd see people shaking their head, are we in violent agreement?

Any thoughts? I think one other thing I'd add is, so my personal bias to this is that the industry is catching up, or rather the technology has not kept up with the industry either. Um, and so like when you look at like the state of CI N C D over the last 10 years, there's very few new products, very few like innovations in the space.

Um, mostly because in my, my perspective of this is that you've seen so much cloud adoption and there's been a lot like you've had to, you've had to make this move from data center to cloud and you basically just pulled things along with you. And now you're in this cloud, you've now moved to the cloud, right? And so like I was at Google in the mid two thousands and you sort the world is where the, where they were in 2008, 2010.

And so now you're having to see, okay, how do I reinvent this in a world where the principles have changed? It's no longer physical infrastructure I'm deploying to and my lead times can be X, Y, and Z. Whether longer you actually need to rethink from first principles, how you're doing the entire operation.

I think that's where the world is today. And that's, and it's very hard for organizations to, like, you have to recognize that it's happening at a macro level. Like you can't say that my individual team is gonna get faster by doing X.

It's probably not. Um, you probably need to look at your system more holistically. And that's a big thing for people to bite off.

Um, and it's a big thing for like, for IT leaders to say, look, I have to look at this and it's gonna be a three year journey. It's not a one month journey. Um, there's no, there's no quick fixes I think in to sort of where things are.

Uh, I think the report shows that, like as things start to line now, I don't disagree, Steve. Um, I also think there's this, um, there's this interesting snapback that we keep on having in development. Um, and uh, we can all remember when s o A first came out and suddenly everyone was talking about whis and, and going nuts for s o a and then, you know, after a while we were like, we're kind of using it for everything and maybe we're using it too much now.

We need to come, come back a little bit and use it where it's appropriate. And I think we, we kind of tend to do that with technology cause it's really exciting. Something comes along and you just go a hundred percent on that technology.

I think microservices are probably there at the moment. We've probably gone a bit too far and we need to come back a little bit. Um, so I think there's always that case as well where you almost overinvest in something and then you need to kind of come back a bit because it, it hurts you when you go too far.

So sometimes I think the performance of teams in terms of like the DORA metrics, uh, it can be harmed sometimes by that overinvestment in a, in a single idea. Um, and then we find balance afterwards. So what we end up with is actually better.

And maybe that excitement that we have initially is what helps us to learn it all. And then, then once we know where it fits into the picture, we can use it in a more healthy way. Maybe another way of like resaying exactly what you're saying, Steve, is, um, work backwards for, like, we've talked a lot about developer velocity, right?

But like, what's developed? Why do we care about developer velocity rate? It's because we care about changes to the user.

So what does the user care about work backwards from there. That should define what your C I C D pipelines, what your developer experience looks like, all of that, right? Like, but yet we, you know, we've erred way more towards the developer of the last three to five years.

Um, and there's probably a balance of where you have to look at the other side as well, what is the user need? Um, and then balance those two things and it'll probably get a, probably yield a better results when it comes to what your business impact is. Fair enough.

Fair enough. Guys, we, we only have a few minutes left. I wanna focus really hardcore on the report here in our audience.

Um, Liam, how should folks in our audience who are in the C I C D space, or maybe they're, you know, the 80% of people in DevOps who are not in the C I C D kind of, you know, uh, highway here, uh, how should they view this report? How should they use this report? I, I think the, I think the way for them to, to view this report is, is a, as it title suggests, a, as a state of the cd, it is, it is a kind of culmination of the best data we have about where DevOps and CD and C I C D, it's, and to look at that as a kind of principle that this is where we are, this is how we are performing as like a collective group.

This is how we are doing across all these different metrics. This is how we're doing based on the technology we're using. And to consider how does their setup look to this?

How do they compare to this? Where do they think they fall? And also then if there's, as Andrew mentioned, like plans like to improve, take time, and they should consider, well, this is where we are, this is where other people are, this is where we should be looking to go forward to.

I love it. Melissa, you're the cohost this episode. So I'm gonna give you last, kind of the last word here.

Excellent. What, what do you want people to take home with them? Well, uh, something I love about data is, um, you know, it all comes down to the analysis behind it.

So data is great and, and, but the next step is decide what you're going to do with it. So, like Liam said, you know, look at these numbers, um, look to see, you know, how your numbers compare, perhaps decide on some changes you will make for your team. But along with both Steve and Andrew, I, I would caution against just diving in blindly, uh, really, you know, have some metrics that you want to meet as a company and make sure that you focus on your needs for your organization and for your development team.

Uh, I can say, and this is my personal bias coming in, um, I know on the developer side of things, we get a lot of pressure to, to learn a lot more tools, um, add a lot more to our toolbox. And, um, I'm not, I think we're overwhelming that side of the equation a lot. Um, and really interesting the, I think the report reveals this a little bit with this fact that, um, more is not always better.

Um, just adding more tools on top of your pile is not always the best thing to do. Um, I, interoperability is something that is really special to me. There is a special interest group at the CD foundation that talks about these interoperability, um, problems that we have between tool sets.

I think that comes in huge with these numbers. Um, also, you know, we're at this stage where we have finally figured out some of the standard components, you know, for a pipeline, um, to go all the way from the beginning to deployment. And we need to be able to observe that, um, better and be able to plug in, um, the tools that we need that are gonna get us to where we need to go.

Uh, we're getting better and better at this, so I'm really, really curious about next year's report. All right. Uh, so there's a sequel in the works, typical Hollywood.

All right. Hey guys, Andrew, Liam, Steve, and, and most of all, Melissa, thank you for popping in here today and, and helping us with this episode of the CD Pipeline. Again, you could download this report from CD Foundation, which is the home, online home of the CD Foundation.

Guys, I also want to thank you all, not only for being on the show today, but certainly Melissa, Andrew, Steve, you're all deeply involved and give of your time to the CD Foundation. And, you know, these kinds of foundations don't exist, but for people like you giving of your time. So thank you all, and Liam is, it sounds like you're in it as well, in, in more than just CD foundation, so thank you as well.

Um, but we're out. We'll be back next month with another episode of CD Pipelines. Until then, is Alan Shemel.

Thanks for joining us.