 Thank you everyone. My name is Christian Hernandez. I am a Senior Principal Technical Marketing Manager at Red Hat. That is a very long title and it's always weird to say it out loud, but and I'm here to talk about a pipeline as code. So I want to start off by quoting my favorite person, Chris Short. Everyone, if you're in the CNCF community knows Chris Short. But Chris Short once said on the the New Stack podcast that GetOps is the holy grail of DevOps. And I always love this quote. This is like one of my favorite quotes because not only do I think it's like a spot on observation, I think it's indicative of how DevOps has evolved to the forefront of how to manager system and how the software delivery process happens on that system. And and really, GetOps isn't really anything new, right? GetOps as practice looks very similar to DevOps practices, right? So this is why a lot of there's a lot of confusion and why the Open GetOps project exists is there's a lot of similarities. It's like, hey, I'm kind of doing some of this stuff or all of it. Not sure. And that's because GetOps is DevOps, right? With some little tweaks for, you know, course cloud data architecture. And I really think GetOps is proof that DevOps works. And it has arrived, right? We've been talking about DevOps for a long time, right? We've that that that keyword that buzzword has been through the ringer. Now we have this new new buzzword called GetOps. And then it's really it really proved GetOps is proof that DevOps works, right? And and speaking with Dan Garfield, actually. So Dan, that was just up here. We were chatting and we basically said that really GetOps are things that we've been wanting to do this whole time. But now with like an infrastructure like Kubernetes or the platform like Kubernetes, we're able to do some of these things that we've been just kind of just wanting to do forever. So I want to end this little rant by saying is that really GetOps is what DevOps looks like in practice. So the name of the game really is automation, right, and GetOps is all about automation. And since you're using Get as a source of truth, your Get workflows become the center of everything that you're doing. And since Get workflows are industry standards, right, it's and it's easily learned, right? It's become like the de facto standard. And really even even for people like me who comes from an operations background, like I know how to do Get, right? Like we all familiar with Get, even us operators know how to do Get. More people get involved, right? And more people can have eyes on it, right? And Get really becomes, those Get workflows becomes your change request process, right? So if you think about it from a high level is that your change control process really now is in the kind of an automated fashion with your Get workflows. And you can set up things to require approvals and for people to sign off on protected branches, doing all that cool stuff. And yes, even your security team can be part of this whole process. So which kind of brings me kind of to my next point where GetOps is really the building blocks to a lot of the things that a lot of other automation paradigms, right? We hear another buzzword called the DevSecOps, right? Whereas the process of bringing your security team into the DevOps life cycle. There's AIMLOps, there is application supply chain, right? All of that GetOps is a cornerstone of all of that, right? So it becomes a center of a bigger automation paradigm. So this kind of brings me to my next thought, like where does GetOps fit in to the CICD process and, you know, us as DevOps practitioners, right? The CICD process is like where we live, right, is our cornerstone. And so you can do GetOps without CICD. And so you kind of think, you know, where does that land? It really lands currently in that CDIP aspect of it, right? At that last mile, keeping your environment in sync with whatever track branch that you want to do, you know, it's there to prevent drift detection and all those nice things that you get with GetOps. But it really sits downstream from it, right? So this provides a loose coupling between CI and CD. They're separation of powers that are related and independent with each other, but not, you know, they're not disjointed from each other either. So tools like Jenkins, Tecton, CloudBees, they could all still exist in this new automation paradigm, right? So we talked a little bit about how GetOps isn't really anything new and how DevOps practitioners, you know, have been doing a lot of these practices for years. And now with the GetOps working group, we put together these principles to help guide DevOps practitioners into who want to further go into GetOps. So I really want to start talking about what comes next, right? So GetOps, latest buzzword. It's all new. It's all exciting. I actually want to think a little bit forward about, like, all right, what comes after GetOps, right? Or, like, what comes next after this? And I mentioned in the previous slide, GetOps typically sits downstream from the CI CD process. I think we need to start building our CI systems to be more GetOps aware. So really taking that idea of GetOps and then expanding it to your entire process, you know, you started seeing kind of these things like GitHub actions and GetLab CI. And we need to move further down from GetOps just providing drift detection and deployment to a universal way of thinking. And this means making everything GetOps aware, especially your CI process. So everything has code. When I say everything, I literally mean everything. And this also means how your pipelines run. They should also be declarative. And not just how to deploy, but also how to build should be declarative as well. So you have the entire CI CD version in Get and operated via Get workflows. GetRepos can be separated out here, right? As you see here, if this looks too crazy for you, it's fine. You can do MonoRepo. This just kind of illustrates the point of having everything in a GetRepo. So not just declarative how your infrastructure looks like, right? You're declarative, but also how you want to build your infrastructure as well. And the CI process needs to also be part of that GetOps paradigm. So the Tecton community, sorry, has started working on something called pipeline as code. And pipeline as code is basically running pipelines declaratively. So it's essentially taking the idea of having kind of GitHub actions. I always kind of pick on use GitHub actions because everyone uses it. But kind of bringing that idea of GitHub actions to everyone, right? Like not just on GitHub. You can also do it on Bitbucket. You can also do it just on Splingit, right? Creating your Git repository through a command line. I'm pretty sure we all started that way. You can do it then as well. And so the idea is bringing those type of actions, those type of declarations to the broader community. So I invite all of you to get involved, right? You can join the Tecton Slack. There's a working group called Workflows. And you can also check out the Tecton Git repository. If you're more hands-on, right? So there's some links there that you can get to. There's a copy of the slides on schedule. So you can always download them and click on those links there. And Selfish Plug, right? So I run a bi-weekly streaming, GetOps Guide to the Galaxy. Dan has been on it. Scott's been on it. Cornelia's been on it. She's out there. So I invite everyone. So if you're interested in coming on, I love when people come on, we talk of GetOps. It's really, really casual. You can even demo something. We can break something together. It's cool. So for that, I want to say thank you very much. And enjoy the rest of GetOps, Khan.