The State of Pipelines: Past, Present & Future – Part 2 – The CD Pipeline EP 2
For the second episode of The State of Pipelines: Past, Present & Future, our featured guests are maintainers, contributors, and active voices in the Jenkins project and CD Foundation. This year Jenkins celebrates its 18 birthday! As the leading open source automation server, Jenkins provides hundreds of plugins to support building, deploying, and automating any project. Hosts Alan Shimel and Lori Lorusso are joined by Mark Waite (CloudBees) and Darin Pope (CloudBees) as we dive into various Jenkins topics including, modernizing the UI, security, community contributions, and more.
Transcript
Hey everyone, welcome. This is the state of pipeline's past present in future. And this is a show brought to you by the CDF The Continuous delivery Foundation part of the Linux foundation and texture group.
My name is Alan Shimmel. I'm the CEO of texture and group and your co-host for this show where we try to shine a light on various projects and issues and people within the continuous delivery Foundation Community. We have two great people from that Community here with me as well as my co-host.
Let me introduce you to our two panelists though, and then we'll get to our co-host. First of I want to introduce you to Darren. Pope, Darren.
Welcome. Thanks, Alan. How you doing today?
I'm doing great Darren. If you wouldn't mind, would you maybe share a little bit of your? Background with with our audience.
Sure. My name is Darren Pope. I am a developer Advocate with cloudies and also do a lot of work with the Jenkins Community Based on my hair even though standing up straight right now.
It's a lot of Gray. So I've been around before Jenkins was Hudson. So we'll get into a little bit of the history today.
So absolutely and at least you have here it's not a bad thing. I still have a little bit left. No you have plenty good work.
We've been there our next and welcome Darien our next Our next panelist is Mark Wait mark. Well, hi Alan, thanks. Yeah, I'm I'm a member of the Jenkins governing board.
I'm the Jenkins documentation officer and I maintain the Jenkins get plug-in. So I'm deeply interested in Jenkins and how Jenkins works and what it does and why it does it. fantastic at least is my co-host.
She kind of heads up the marketing efforts at CDF and there's so many other things in addition to our full-time role that Jay frog Laurie Larusso Lori. Welcome back. How are you?
I'm great. Thanks for having me. And thank you, Darren and Mark for joining us today.
And again, this is the CD pipeline. So it's continues delivering software from A to Z. And we're absolutely thrilled to have Jenkins cdf's first graduated project on the show with us today.
That's it's a huge. It's a huge get for CDF. It's a huge win for the Jenkins community and the Tech Community in general and I'm really excited to kind of talk about, you know, past present and future of Jenkins.
Absolutely before we do Laurie. Where in the world are you today? Today, I am not far from home.
I'm in Raleigh North Carolina at the all things open conference, which is really cool. So to be at an open source conference talking to an open source project. It's kind of like a win-win.
Absolutely. I just saw Lori last weekend Detroit Cube concert was good to see her in person. But she does quite the schedule.
Anyway, we're gonna jump into Jenkins. Let me let me start it off with a little of my own. com in 2013.
com was Cloud piece. And back in 2013-2014 cloudbees was pretty much all Jenkins all the time. KK founder of cloud bees who we mentioned Hudson right was it was at son and Darren I I'm gonna assume you have a good Candle on the history.
I'm gonna ask you to give a quick history of Jenkins. K was there we spent an ordinary amount of time. Of our time at devops.
Well, we were trying to Define what devops was because I really wanted to know what exactly was devops. We were talking about Jenkins and plugins and Cicd fast forward it's been eight years something like that and Jenkins is still probably the dominant. Cicd tool used if we look at the total.
Commercial Market but let's spend a little time, you know visiting the Ghost of Christmas Past. So to speak the ghost of Jenkins passcode a little history Darren if you wouldn't mind you want to kick that off. I will so whether this is truth or myth we will never know since K is not here to tell the story KK and I'm ready for Tomas.
KK Mark say his name for me correctly cost. Okay kawaguchi. Thank you, because every time I butcher it.
So Mark got it, right. So the myth goes that KK was tired of Building Things by hand, so he wrote this thing that turned into Hudson and as people were leaving son, he would go around and steal the machines that were setting on and they would keep stacking up underneath. His desk until finally.
He had a great big cluster not to be confused with kubernetes cluster. We'll get there in a few minutes. And that was the first real at scale.
Hudson cluster at that time. And then at some point mark, what was that date around ballpark to where? Yeah, that's a project got renamed.
Yeah the rename I think was around 2011 2011, right? Yeah. There was a there was little Fallout between a certain company that purchased Sun Microsystems and the developer community that was maintaining The Hudson Project and the result was The Hudson Project was renamed Jenkins.
And that other company retained the license for that other name, right? I I need as the JD here. Got to step in.
I don't think it was truly a renaming wasn't it a fork? Oh, no. No, that's you you talk to the developers and they will they will hard-nose tell you no.
No, it was a rename because the the ownership of the code and the maintainer base of the code all went with the new thing. So it was truly a rename not a fork and there and there it's fun to talk to people from that era about their perceptions of why it's absolutely rigorously a fork and there are why it's absolutely rigorously rename and not a very adamant. Yes, not a fork and they they understand the term for very clearly and they know exactly what it oh, yeah.
I know there is no longer very not a fork. We left and correctly objection. All right we go from Hudson to Jenkins 2011 is Right right around 2011 and then from there it was pretty much the normal things.
We first started out and back when KK started as Hudson. There was a job type called free cell job. And that was the only job.
And if you are still using freestyle jobs today, let me fast forward don't do it just move on because there's other things that we can use today Mark once you've jumped in on that one because yes that works Mark and Darren sometimes have conflicts and these are part of our fun of this. I have some particular uses for freestyle jobs that work quite well for me, but Darren's right. That's a 18 plus year old technology that they're better ways to do it.
I still remember chaining freestyle jobs together to create pipelines on our talk today is about pipelines right? I needed to chain things together. One thing would call another which would call another and what I ended up with was a rather brittle.
Chunk of things to do the delivery and brittleness hurt wait. Brittle, give me a break Mark. Come on, man.
It's it was beyond brittle. One one small thing and that house of cards fell over. And Darren's right?
That's that's why Darren's a good good place for this one is he's absolutely right chaining things together. Like that was really hey. It was okay 15.
So we had it's always what we had and it worked but it was really not the way you wanted to do your business. No. And then over time eventually Jenkins moved from the 1X line to the 2x line.
I believe that was in 2016 round July 2016 and From there. That's when we were had the first real chance to move from what was the only way to do pipelines by the way a really bad ugly pipe plugin to chain together the thing so you could visualize it was miserable miserable miserable. But then we had the concept of pipeline coming in at first it was scripted pipeline if you wanted to get really ugly Mark the plug-in name was workflow Dash CPS makes a lot of sense, right?
How do you get pipeline out of that? but then but then around six months later we came out with something that was named even worse which was called the pipeline model definition, which is actually declarative Pipelines. And man, you know that that started making things a little bit better.
Was it yaml? No. Thankfully we won't get into the yaml versus Jason versus dsls today we could but we won't that's a whole another rabbit hole that nobody needs to go down, but then we were able to declarative declaratively Define.
our Pipelines scripted pipelines mark it was the first it was and it worked scripted pipelines gave me really a domain specific language that I could use to express my pipeline instead of the awful evil chain of series of of jobs that I had before I could encode checked into my repository say what I wanted and that was already dramatically better than the old thing. But let me just cut you off here. So while you're doing all of this, how is the adoption going?
Right? Oh, you guys aren't working in a bubble. Right?
It's not just you against the world. How is the adoption going within the community in general? Right, right, so Go ahead Darren at that point.
It was pretty horrible. Some some people would take advantage of that and they would really start building out these really stinking complex Pipelines. And they were treating even the scripted pipeline.
Let's not even get to declarative because again to begin with all we had was scripted pipeline. And people it's like oh, it's just groovy. Mmm scripted pipeline is not groovy.
It looks like groovy. It smells like groovy. It is not groovy.
You can take that. We want to take it. I I got to tell you from an Insider outside.
Of pursue and they announced pipelines and then what was the user interface to wasn't there a new user interface around then? There was the user interface the visualization interface came out about six months later called Blue Ocean and let you see a visual representation of the pipeline in in notes and graphs on a pretty good looking presentation on your screen. Yeah, absolutely, but Here's the thing.
I remember being at Jenkins world because we were producing Jenkins world. I was with KK. Seeing this thing.
Wow, this looks fantastic, but it never occurred to me. It never occurred to me that what people were using before then was brittle or crappy or you know. Down it was the dominant.
It was the s**** right? Let me let's let's call it what it was it dominated the market. Everything else was peanuts.
peanuts it probably had 90% market share. There were a thousand plugins or maybe more 1200 plugins. For so let you know.
And maybe just because I was an outside. I have an outside view of it and you guys got to see it up close with the warts, but it was a Powerhouse. Well and to Lori's point the the question of adoption or to her question the question of adoption.
Many Enterprises chose Jenkins because of its capabilities and its cost right they liked open source free is really a great price point and they like the capabilities and they kept growing but that meant they had invested heavily in this these freestyle these old way of doing things. So pipeline adoption took some time and it really did we spent some years getting people shifted away from the old way of doing things to the new way of doing things. Well and the key part to that is pipeline only worked on the two ex-line of Jenkins not the one next line and that that people to move from One X to 2x was actually a harder move than getting people to move from freestyle to pipeline.
Yes, that that I do remember it wasn't it wasn't they didn't do like backwards compatibility kind of thing it was. It was it was a different direction, right? So that took some time.
So again, this is around mid year 2016 when all of this started going into play again Jenkins 2x came out in July 2016 the first the scripted pipeline again looks like gravy smells like gravy. It isn't groovy. People would start writing their jobs as if it was real live code and they would treat it like real life code which was the exact opposite of what they should have been doing and today still should not be doing.
Because what we want to do is we want to Define whatever our job is, you know, whether we're trying to one of the examples back that year was flying a Raspberry Pi set of drone or flying a drone Damian did that right Mark? They were flying is flying something around with Jenkins in the cloud, right? Literally.
It was a Raspberry Pi flying in a drone and you know, we're doing all these things and treating it like code what okay, we're defining it as code. But that doesn't mean it has to be real code what that's when declarative came out. But since people had already put all of their time and effort into building out script to pipeline for the people that did that They weren't going to rewrite it yet again to go to declarative.
Again, each of these little steps along the way. There was friction being built. but then we get into 2017 and people that might have been coming to Jenkins brand new at that point then they're able to start with declarative on the 2x line and everything's moving forward.
It's that sort of that messy middle time of coming out of One X into scripted Pipeline and then into 2X and into declarative that a lot of people just it was hard for them to make those jumps. And of course again, that's only six years ago. So you think about it then 12 years before that.
So again, Jenkins has been around quite a long time. Yep, and people are still making changes today. So Because it's an open source project and because you are making like Leaps and Bounds and changes in friction points.
How did the community handle that because it's open source. So how how are things working within the community like you're on the market? It wasn't the TLC.
What I forget what you said that you're you're on the board. Right? Right.
So you have to hear a lot of The feedback from the community. So as you're really trying to move things forward. What were you dealing with back then?
Well, so one of the one of the compelling principles that kosuke started with was compatibility and deep and serious compatibility sometimes even if it meant to the detriment of new functionality and so his commitment to compatibility and it was really KK that started it and it just continued that commitment to compatibility meant that we would carry forward what they had done before and it would keep working and it was important crucial vital that it keep working. However, things like pipeline that really is a new thing right and that's that's not compatible because there wasn't a thing before and so so those those transition points are interestingly complicated right for a an Enterprise as they think about. How do I make this switch from what I was doing and it works for me now to a better way to do things.
Yeah. Did that answer your question Lori? Yeah, I think so.
I think it's you know, it's hard to take the leap. First of all and jayfrog. I'm sorry.
We use leap terms all the time. But then when you're if you're if you're focused on compatibility and it's something that's never been done before. How are you supposed to adopt that as an end user?
How are you supposed to tell your CTO that this is the way that we should do things when there's no literally it's just a proof of concept. You're like if it should work, you know, I know we've invested heavily in this infrastructure, but they're telling me it's gonna work. It looks like it's gonna work.
It's working over here. I mean, I think that that's what's really cool about having a project that's been around for 18 years is that you do have those long long tail use case stories and can really see how not just Jenkins evolve but how it evolved for companies and how they evolved with it to make them, you know, better stronger faster all of the good things, you know, and now we're all Cloud native, you know, moving from you know, different clouds not just on-prem to Cloud but Cloud, you know different Clouds are crime. It's just it's just fascinating to be able to have the history with one project.
And you know again you were part of the CDF. So that's that's huge for us, you know. You know, what if I could weigh in here again, maybe is an outside rather than an Insider.
I think one of the strengths of Jenkins and one of the reasons, why here we are 18 years later and it's still what it is out. There is And it started with KK because I saw it up close and personal with him, but he carried through them just about everyone at cloudbees. And that was the sense that Jenkins needed an independent Community.
That's why it's a perfect fit for the CDF that it wasn't going to be owned Lock Stock and Barrel and managed solely for the for the betterment of let's say cloud beef right Sasha labare, and and the whole Cloud Beast team actually did a really good job of setting up sort of a Chinese wall if you will right between the Jenkins community Versus cloudbees right not to say that there weren't caught these people. You know on the Jenkins board and so forth, but it functioned independently and it allowed Lori to your point. users in the market in the community to have a say in what was What was going to be in the official release and what was it?
Right and so I I think you know fast forward to today, right Jenkins was Passed over to or giving to the CDF to manage. And it certainly more in as or more independent than it ever was of any one vendor and and that you know, that's the beauty of this whole model. Is it really it works for that?
We mentioned Cloud native though and Darren you use the keyword earlier. for many people kubernetes. Oh, yeah.
Well, okay. Can we pause there for just a second before we go down this? Okay.
I'm good. So worry, I'm gonna take I'm gonna take I don't know where the right word for this I disagree with you on this not everybody is cloud native. People are moving there but it still is not there.
We are in the infancy of getting into Cloud native. I think it's still going to be 10 years before we can actually say 50 plus percent. We are Cloud native.
Different conversation, but I had to get that out there because I had to disagree with you on that point. Sorry. No, and I appreciate that.
I think that's kind of what we need to hear. Right and I think Mark you had something that you wanted to talk about in terms of like here we are. I'm jumping into the to the Future right to your point Darren, but Mark there were things that you wanted to say about like Jenkins in the I don't want to say the past but certain things that you wanted to to touch on that people might not realize are still good practices or they're just getting started with Jenkins and I know we haven't finished the history yet, but I wasn't sure if this was a good opportunity to kind of bring that part up as well Alan Alan.
I think let us towards that direction kubernetes is an expression of containerization, right? It's something containerization plus orchestration, right? And before we got kubernetes, we had Docker and the folks there who did containerization with container just pure containerization and that transition that going from virtual machines towards containerization.
Was was and continues to be an interesting and useful transition for many people if they haven't containerized yet. It's worth them thinking what would I do to containerize this thing? How could it help me?
And what would it do? All right after containerization then it may be time to say. Okay.
What can I do with the orchestration of those containers and kubernetes is an interesting choices and a container orchestrator there even other container orchestration schemes cloud cloud providers who are doing container orchestration without requiring that I do kubernetes. So all of them are interesting parts of this whole continuous integration continuous delivery Journey. Some more Darren.
Yes. answered Lori I think you know on our on our history timeline here. I feel like we're on the Saturday morning cartoon, you know Conjunction Junction.
Anyway, what's your function? Yes, I remember that. We're both that old.
Laurie has no idea what we're talking about. Oh, you're talking. Oh, I appreciate you.
but so version 2 of Jenkins that it's kind of a game-changing version with pipelines and blue ocean and all these things. And we're starting to see containerization and people are saying wait a second here. Jenkins has all of these plugins everything works with Jenkins including Jay frog including so many other devops kind of Staples that we've come to know.
We couldn't work. In a in a container World in a container environment and I don't know the current status of let's say Jenkins X and I thought that was merged in has it not been merged in are we allowed to talk about it on this show? We can certainly talk about it.
It's a CDF project. Mm-hmm. So Jenkins X has not been merged and Jenkins X continues as a separate CDF project.
They're actually right now talking about a possible rename so that they get clarity in terms of where their direction is going and where the Jenkins project is going Lori. You may have more data on more information on that but my hints are that right now Jenkins and Jenkins X are two separate entities and they they'll continue evolving as separate entities. And that's exactly right and it's not to say that they don't work together in certain in certain instances.
And I think all of the you know, that's one of the things that we at the CD Summit that we had at kubecon we're talking about was that, you know, just because it's one project doesn't mean it doesn't use another open source project to support it. But Jenkins X is going through a rename. They haven't decided yet, but they are going to continue to be two separate projects.
Jenkins is graduated Jenkins X is just getting renamed and really working towards that full-on adoption and moving forward to be a sustainable project. excellent okay, so now so I guess this brings us up to maybe 2018 in that time frame. Maybe it's 2019.
I think the CDF one was the CDF originally charted was a 2019 Laurie or do you remember? Think so. Why do you ask me questions Allen?
I mean like blank on this. So right I was there. I'll be honest with you.
I was there when they did it Jenkins I think might have been one of the first Projects that was donated to CDF Tracy Miranda was the first from cloud bees was the first CDF. Ed and manager and and that really to me that that truly made Jenkins really independent. It was it was even though Cloud bees was a benign.
A benefactor manager, whatever you want to call it. KK left Cloud bees he's doing his own thing at Lunchable. Jenkins is now part of the CDF.
It's got its own, you know emancipation if you will Proclamation and and let's go from there Darren if you want to continue the role as the story and with marketing color what what went on from there. So as Jenkins moved out of software in the public interest markably, that's the correct way SPI, whatever the moved into CDF then it's been there and growing throughout this time since that 18 19 era now up to 2022. We've lost three years, right?
So it's 2022 now just in case you were still think it was 2020. And from there, we've learned things along the way. Yes, we have all of these plugins, but one of the things that's been really realized is you don't necessarily need all the plugins.
and this is how if you're wanting to have a really good stable Jenkins controller running all the time. Oh by the way, naming changed all through that time. We moved from Master to controller we moved from slave to agent.
There were a few other renames that were that were added in during this time and As as we've seen people using it's like, okay. Well really when you're creating new jobs. We'll just call them jobs right now inside of Jenkins you really want to do it this way and this way and maybe you know lay off some of the plugins because as things get upgraded if you think about it when you add a plug-in to a Jenkins controller now, you've added one more dependency and as you keep adding dependencies and you have to keep these versions all together that Cartesian can get to be pretty bad really fast.
So if you can minimize plugins when you're going through and trying to upgrade. Then usually that's a lot easier jump to make. Mark what do you think about that?
Because you maintain one of the core not core plugins but one of the most used plugins and anywhere in that you can just ecosystem agreed and I think I think what's happened is as part of this shift as people think about how they do continuous integration continuous delivery. They're shifting away from towards a glue and component model where they use Jenkins as glue and the components are stuff they maintain themselves. And so they they've simplified their lives by making that choice.
It's easier to develop easier to deploy by using that but effectively they're doing is use Jenkins less and use their own code more. Let me add in one thing here. I'm going to give Lori some props at least jfrog.
So Lori since you're here. Recently recently. There was a new jfrog plug-in released.
There was an old school artifactory plug-in there was just artifactory and it wasn't maintained as best. I can tell by anybody within Jay frock, but this new jfrog plug-in is being maintained by jayfrog first rule of thumb if somebody produces a plug-in and they're not part of a company X whatever the company is that plug-ins for don't run far away, but Run start walking away versus now. I see that we got four committers from Jay frog maintaining the jfrog plug-in, but then I started digging into this plugin and it's basically a lightweight wrapper around the Jay frog CLI, by the way again, I'm gonna give Jay frog some love here that Jay frog CLI is the bomb I have been recommending it for when I was working within Professional Services within Cloud bees.
Let's say look you're using artifactory use the jfrog CLI. If you're not using Maven or Gradle or you know, something that has it all built in sort of handle it nicely. That's perfect.
But then I'm going to start moving at a little bit ahead here. Then all of a sudden Jay frog comes out of the blue and releases this I'm gonna try it. Percia does say it right get even though you got it.
Yeah, another CDF project exactly. And that's the key part here. Lori was talking about having the CDF projects working with each other.
Now that was just announced at the time. We're recording this last week last week Lori from around you, okay? So that's a key thing because as we're starting to get into this proof.
I don't want to use the word blockchain. I just can't I can't use the word blockchain, but I'm going to use it in a rougher. We have this Quorum or consensus if I remember reading right so we'd have three builds that are proving it Yep.
This is good and then it's inside of Persia. That's going to be key as we're moving forward in supply chain. Everybody's here tired of hearing about supply chain already.
Guess what? It's going to be. The number one thing for this is my prediction for the next 10 years.
Because until that solved nothing else matters. Darin I think you were reading my my mind because that was where I kind of wanted to take conversation to is present because again, I supply chain security shifting left. That's that's the present.
That's where we're at. What are we doing? How do we figure this out?
What is this problem solve? So what is Jenkins doing to help, you know secure their pipelines to secure your products to secure, you know, the supply chain moving forward. What are you currently working on to help solve the problem?
Yeah, so so for us daring you okay, if I take it yes, please do all right. So we've got a crucial part of our delivery process is how do we deliver new releases of Jenkins and new releases of the plugins inside Jenkins to the community and we've steadily moved from the developer releases their own to a continuous delivery model where Machinery does the release ships the plug-in and all the developer did was commit a change to the master Branch to the primary branch on their GitHub repository that continuous delivery technique means ah, the delivery Machinery is now all inside a nice safe safe space that the infrastructure team maintains rather than worrying about what's on a particular developer's environment when they do a delivery So continuous delivery for us is a big deal and it matters in terms of helping supply chain security. Well and with security that you can security team.
every developer can opt in their repositories into the security process and That's the security people are very strange. I'm sorry and if they watch this, but they have to be there has to be a Walled Garden correctly put around them because it's it's a big deal. So I don't have a whole lot of details because they don't publish a lot of details.
Sort of on purpose, right? That's how you want your security people to be you just want to slide pizzas underneath the door to them. All right.
Hey, I'm in security for 25 years. I I got to stand up for my peeps. Yeah, it's why we only eat pizza in the dark, but it's not necessarily behind closed doors.
You don't have to slide it under just leave it on the cube or something. We'll come by and get it. You know, but I like what you're saying how it makes security easy for developers, right?
Because I think you know, I I don't know if it was one of your shows that I was watching where or if it was a talk at the CD Summit but he was there was someone that was saying leave security to Security Professionals and get it out of the hands of developers, which is exactly kind of like in opposite what we've been hearing which is like give developers more opportunities to help secure their their code at source. So what you're saying is Jenkins kind of takes the Best of Both Worlds, right? You have your guys that are getting the pizza under the door and then the developer they can just, you know, commit their code and know that they're safe because of all that you're doing in the background or they will find out that they weren't safe automatically because of that which is fine.
Yeah. It's and it's part of it's part of an evolutionary thing that we see that all right. We started all those years ago.
We were proud to compile our code. We were really proud that it comp That c compiler actually worked and it made it all the way and we got really bold. We started writing automated tests for it.
And those automated tests. We were so proud that they worked too. That was so great.
And guess what? It's gotten better from there because now we do static analysis. We do detailed looks to see inside the code.
Are there known security vulnerability patterns here. We do dependency scanning. We do all sorts of additional checks now and the checks just keep getting better to help us at every every part of the of the whole delivery chain.
Absolutely. To the point on letting security people do security. I I think what we're seeing is, you know, there's always been this friction on devsecops and shift left and a lot of folks in the security world and and quite frankly the SRE world are saying hey, we're doing shift left at the expense of shift, right?
And you got to kind of balance that right? You can't. You can't throw it all on the developer.
Right. You still need to do your security after release? The world doesn't end at the point of delivery.
Right and that sound devops principles right feedback loops iterated. So You know to my security folks out there. No, we're not.
We're not taking your jobs away. And you know, they you got to be I have to go to RSA in a couple months. You want me to get killed out there.
We got to go easy guys. But anyway, but yes Jenkins is helped. Hun with this right?
So guys, we only have a few minutes left. I want you to take your crystal balls out a little bit and and let's talk about where do you see Jenkins going? What can Jenkins do?
How does it maintain its? Kind of preeminent position if you will, right? What what does it need to do?
What should it do? What will it do? Darren I've been letting you lead off.
I'm gonna go to mark first on this one if it's okay. So we've talked about integration another forms. I think the next step for us is event based integration where we use whereas previously you remember the story told earlier.
I changed jobs together explicitly this job new to call this job and new to call this job and new to call this job the better way to do it. And the way that's evolving now is I Define a series of events things that listen to those events and things that respond to those events. And thankfully the we've got a first iteration of it the CD event specification that was just released.
What a week or so ago Laurie if I remember correctly and and so event based integration is where things are headed because it decouples the integration. So that's one that's one for me and I propose let's give Darren a chance to talk to others that he sees. Well, I think one we've already sort of mentioned it it's going to be getting more more and that's supply chain.
Again, I said that's gonna be the number one thing for the next 10 years devops has been the thing for the past 10 years. The next 10 years is going to be supply chain. Because most tools whether it's Jenkins, whether it's I'll name awesome mothers get have actions.
You name it it's there that part is almost monetized, but what's not commoditized is the supply chain. And that has got to be solved as at the time we're recording there has been a new open SSL thing announced. And or is going to be announced.
That's a big one. So, how do we keep this as automated as possible? So again, when a developer puts in their code, there's as much testing not just for testing sake but for hey, we see this pattern that's a that's a bad thing to do.
So that way we're not having these days that happened where everybody's on pins and needles of okay. Am I going to lose the rest of my week dealing with remediation of this? And Mark, I think there was one other thing that was important one more one more argument for me was I think the other piece that will be a probably never-ending Quest is to accelerate what we're doing there are so many things that I want to go faster you pick whichever they are.
I want my test to run faster. I want my deployments to run faster. I want my security checks to run faster and there are lots of challenges hiding in each of those opportunities to accelerate.
actually Guys, we're out of time. Mark Darren, thank you so much for joining us on CD pipelines. This won't be the last show where we focus on Jenkins and other elements.
So I'm sure we'll have you back on again once we cycle through. You know the other projects and we start kind of combining them, but you know what? So many people on so many open source projects quite frankly.
Do yeoman's work like the two of you that allow these projects to support the vast Community they do and a lot of times they don't get acknowledged most times. They don't get acknowledged for it. So on behalf of the whole Community, let me thank you both for all the work you guys do as well as the rest of the Jenkins team, right?
It's it's not easy. So thank you. Thank you.
Thank you for that Lori. I'm gonna give you the last word. Oh man's tough.
So yes, Mark and Darren. Thank you so much for for being here today Alan. Thank you for again letting the CDF have the CD pipelines as an Avenue for us to push out what's happening in the continuous delivery ecosphere out to the world.
We appreciate everyone being here. We hope that you tune into our next show. So thank you to all of the projects in the CDF specifically Jenkins our first graduated project.
I think we just had a really good history lesson and see our way into the future and so happy to have Jenkins kind of spearheading the way for us moving everything forward. So thank you so much, and we're so you know, thanks. Thanks for having us.
Worry real quick web address for CDF. foundation and you will be able to see all the current projects that we have as well as how you can get. In our slack Channel, you can join our mailing list.
You can find out how to get more involved in Jenkins become a contributor Mark does documentation. I'm sure there's always room for someone that needs additional like dock work and not just encoding so there's always opportunities for you to work on an open source project. And that's another thing that we really just want to push out there is that don't be afraid to try there's plenty of opportunity for you regardless of what your skill set is Thank you.
All right. We'll see you next month on the next edition of CB pipelines. Have a great day everyone.

