 I think it's Christian Hernandez, Senior Principal Technical Marketing Manager, and I always say that's like the longest title, I think, out of anyone I meet. But I'm really, I'm also the GitOps advocate here at Red Hat. And I'm gonna be talking to you about how to get started with GitOps, right? And so this is kind of the question that I know I get a lot. I know a lot of other people on the Open GitOps working group get this as well. A lot of people, you know, we had Open GitOps, sorry, GitOpsCon here in North America, KubeCon. And we got that question asked a lot. So I'm gonna be talking about, you know, basically how to get there, right? You know, you want like a path on how to get to GitOps. So first let's talk a little bit about what is GitOps in general, right? Let's lay the lay of the land. I'm not gonna go into it too deep. I'm pretty sure the other presenters have a lot with respect to what is GitOps. So I'm gonna be talking high level here, but just to kind of set the stage. I always love using this quote because I think it's spot on, right? So Chris Short, who is a CNCF ambassador via the new stack podcast, right? And that's the episode there. So you can actually hear him say this, but he said that in 2018 he said GitOps is a holy grail of DevOps. And, you know, I love this quote because I not only think it's like a spot on observation, but it's also indicative of how DevOps has evolved into like to the forefront of how to manage a system and the software delivery system and the actual systems that manage though that software as well, right? So DevOps was here before cloud native. And so DevOps also had to evolve, right? As we got into the, you know, as Kubernetes hit the scene and cloud native architecture hit the scene, you know, people were doing automation before then, you know, with various things. And, you know, DevOps, since the practice had to evolve, you know, GitOps is the way that DevOps had to evolve, right? As I was saying before, GitOps isn't necessarily anything new. GitOps as a practice looks very similar to DevOps, right? And I keep going back to DevOps because GitOps is DevOps. If you, you know, drill down to it and you really think about it, it's really how DevOps operates a cloud native ecosystem really, right? And so it's essentially it's like, okay, we have DevOps. We have the DevOps practices. We had things in the past like, like puppet and, you know, Terraform. We had, you know, all these automation tools, all these scripting. How does that look like in a cloud native ecosystem? And the answer is really, really GitOps, right? So, and the idea with GitOps and it stems from the idea of infrastructure as code. Well, we treat everything as code, right? And so we treat not only the infrastructure but also the deployment mechanisms and also the management more importantly via Git workflows. Via Git is a single source of truth. And since the declarative nature of Kubernetes allows us to have a declaration, right? Like this is how a declarative instead of an imperative approach to managing a system, it just fits right in, right? Like let's just leverage that. Let's leverage the fact that Kubernetes reconciles everything. Let's take that same approach to managing the entire system. And so, you know, so it's kind of like that whole idea of taking infrastructure as code and kind of just applying it all around, right? And so I believe GitOps, GitOps really is the proof that DevOps works, right? Even the ability that we're able to do some of these things means that like DevOps, yeah, it's kind of like the Mandalorian, right? Like if you guys watch the Mandalorian, this is the way, right? Like there's really, it's a natural progression of how to manage a cloud native ecosystem. And actually Dan Garfield, who you'll hear speak later on today, he came on my stream. So shameless plug, I do a GitOps guide to the Galaxy bi-weekly stream. He actually came onto my stream and we had a chat about GitOps and he said really the GitOps is things we've just been wanting to do this whole entire time, but now with cloud native architecture, we're actually able to do it, right? So like, you know, things that we've been trying to do this whole time with things like, you know, like Puppet or Chef, right? I was a big chef guy back in the day. And you know, with VM snapshots and you know, all these weird, you know, scripting tools, we can actually now do it natively, right with cloud and now we can actually can do it. So before it was a pipe dream, now it's actually possible. And you know, I'm gonna end this kind of little part here, what is GitOps? GitOps is really what DevOps looks like in practice. And I think another way to think about it is DevOps. DevOps is the culture and GitOps is the practice, right? And so, especially when dealing with cloud native, the cloud native infrastructure cloud native ecosystem. So how to get started, right? So this talks about how to get started, how, you know, what's the path, all this cool things. So how do you get started, right? So if there's really real prerequisite, you know, like if you wanna know, you know, if you wanna talk to me, if you wanna, you know, this was actually like a gathering, you sit me down with a beer or a beverage of your choice and you ask like, okay, you know, what do I need to do? Really, you need to get started with DevOps. And to get started with GitOps is really, you need to get started with DevOps. And it's really, as cliche as it sounds, it's the truth. You need to start with your culture first, right? So your organization needs to be ready in order to utilize GitOps to its fullest potential, right? So I go back, I love quoting people. I quoted Dan, I quoted Chris Short. I'm gonna next, I'm gonna quote Kelsey Hightower in 2018, right? Kelsey Hightower at PuppetConf. So you can actually search for this on YouTube. Kelsey Hightower in 2018 at PuppetConf said, you cannot rub Kubernetes on your situation and make it better. So the same is true for GitOps. So you can't use GitOps to try to fix your organization. That's not how it works. You need to fix your organization first in order to use GitOps, right? That fix, right, that you're looking for is to adopt GitOps culture. And so, you know, prerequisite DevOps, I always put the Phoenix project here. I think it's required reading at this point from anyone in technology. If you haven't read it, it's a great book. Good read, fast read, amazing. And so, a lot of times when I say that you need to adopt GitOps first, people get dejected and I totally understand, especially people in larger organizations, right? And so I always say crawl, walk, run, right? So don't take a bite of that, the entire pile at once, right? You know, take smaller steps as long as you have that goal in mind, you know, for many adopting a new culture is a daunting task and I totally get it. I know someone, you know, a CIO level, actually personal friend who he, basically he wants to change the culture, right? He just took on the position and it's a daunting task, right? And for many organizations, you know, they take a few years to change their culture, even before researching any tool, any before researching any technology, you know, right away as technologists, we wanna jump on like, oh, you know, what's the coolest thing? It's all right, I'm a geek too. I'm wearing an Argo shirt, obviously I'm a geek. I love it, I understand it, but really it starts with a culture, right? But for many, this isn't an option really and it's not feasible for many organizations or at least it doesn't seem like it, right? So one method that I see out there is that for siloed organizations, I really actually, I should use a better word for departmentalized organizations, right? They make the change at the department level within the immediate group, right? And so I think making an immediate impact within your own group can do wonders, right? I've also known organizations that cause company, so like some teams that cause company-wide change just by being an example, right? And then actually it does work, it's really cool to see it work where it's like, you know, the whole entire organization will be like, why is that team delivering fast and often and, you know, their uptime is really high? Like, what are they doing? So, you know, again, like I said before, this is a really philosophical talk that I do. So, but as cliche as it sounds, be the change you wanna see and also don't take the bite of that pie holistically, right? So prerequisite, adopt DevOps, look into DevOps, understand the culture first, then you'll be able to jump on to get ops, right? And so, you know, if you're here, you're probably, you know, some of you are saying, all right, you know, I'm already adopting DevOps, you know, or I'm close to it, right? Or I just wanna know the best practices of get ops to see if it actually, you know, what I have to change, right? So, I'll pull the curtain back a little bit more, get a little bit deeper and I'll just talk about get ops best practices as a whole, right? And I know I said you shouldn't, you should focus on processes first before you look at tools, right? But like, you know, it's hard to avoid it sometimes. Again, like I said before, I'm a geek. I jump the gun sometimes, you know, I'm guilty of it as well. But it's important to get familiar with kind of the things you'll see out there, right? And when you Google, like, get ops tools, two tools come up front, right? Argo CD and Flux. And so, Argo CD and Flux are what we, I like to call get ops, the get ops controller, get ops operator, I don't know what you wanna call it, but it sits on your Kubernetes cluster to make sure that your Kubernetes cluster is constantly in sync with your, you know, essentially a get repo, right? It's called the get ops. And they're both CNCF project, they both have large communities. So it's really up to you, right? Doing your testing and see which one works best for you. You know, they're both widely adopted. So, you know, you're lucky in that respect of like, whatever you choose, you can't really go wrong. They're Kubernetes native and cloud native. So they're built specifically for this task. And, you know, another thing is templating. And I'm gonna go to templating deeper in a little bit, but templating, you'll see Helm and you'll see Customize out there a lot. Customize a patching framework built into Kubernetes and Helm is like the de facto package manager, right? And I'll go deeper into them in the next few slides. And then you'll see things like cluster management, right? So you'll see things like open cluster management or a Red Hat, that's the upstream, but we're Red Hat, we call it ACM, right? Red Hat, ACM. So the cluster manager, right? And so application cluster management. And then you'll see like things like Ansible, right? Ansible will manage things outside of your Kubernetes cluster. Some people use Terraform for that, that's fine. You know, you'll see puppet's still out there. All that's fine, how to manage things outside your cluster. So these are kind of the tools that you'll see a lot out there. And so you decided to get ops, right? So you've decided to get ops, this reminds me of a pamphlet. So you wanted to get started with get ops and you read that get ops is kind of like infrastructure as code that you'll be using get. So what do you do? You take all your YAML, you dump it in a get repo to get started, right? It's cool, yeah, you're get ops now, but now you're running into issues, right? What about different clusters? What about environmental differences? What about scaling? How do I scale this out? You know, dumping everything into a get repo was cool at first, but you're having trouble trying to deploy it to different clusters, right? And so you wanna avoid duplications of YAML, right? Because, you know, hey, you can deploy across multiple clusters, cool, but how do you manage that without copying YAML everywhere? And so first tip is to use customize, right? So you use customize, it's essentially as a patching framework built into Kubernetes. So, you know, I can spend a whole hour talking about customize, but the idea is that you have a base configuration, right? So you have a base configuration with all the YAML kind of that YAML that you initially dumped into that get repo. Well, you will put that in a base configuration and then you'll overlay your changes, right? So you kind of overlay the deltas between environments, right? So for example, if you have a deployment, maybe the scale is different between Dev and prod. Maybe the secret you're referencing is different from Dev to prod. You don't have to copy that same deployment YAML multiple times, right? You have one base, hence the name base, we use base a lot. And then you overlay the deltas, right? Pretty simple. It sounds more complex than it is. It's actually really, really simple to get started, right? You have things like, for those OpenShift users, you have like a deployment, a service and a route. Very common for Kubernetes user route, same thing as Ingress. In OpenShift, we support both, but we first came out with route. So we have route, so in Dev, maybe the route is different. It'll definitely be different, right? The Ingress point will definitely be different that it is from Dev to test. So you kind of overlay the deltas keeping the originals intact, right? So it basically renders what you tell it to. So next is Helm, right? So now we're going into actual templating, right? So Helm is a package manager for Kubernetes. I'm not gonna go into very, very deep detail in Helm. Again, you can spend a whole hour talking about Helm. And there's probably others that are smarter than I that can talk about Helm in a more intelligent way. But Helm is essentially, think about like Appget or DNF for Kubernetes, right? So you wanna, the idea is that you have a chart, right? Or the template of what they call a Helm chart. And you have the values that you wanna apply to that Helm chart. And then Helm will then render out YAML based on those two onto your Kubernetes cluster, right? And so on the Kubernetes cluster, there's releases, right? For example, the Bitnami is very, very popular. Bitnami MySQL cluster, right? So MySQL HA cluster, there's a Helm chart for that. And so you kind of input things like username, passwords, things like that, right? Things that you wanna templatize. So this kind of looks like this. So for, it's essentially go templates, right? And you can do things like if statements and loops and you can render things to YAML. So it's actually, it's goal line template under the covers. You don't really need to know that unless you're building them. You don't really need to know that. It's just the idea is to use templating. So that way you're not copying that same deployment. In this example, there's a deployment over and over and over and over again. So how it works, right? You have on the left here, you see the values.yaml file. Cool, the values.yaml file has your options, right? So the, you know, it says, okay, here are, you know, contexter equals this, the mode equals that, right? Like it's basically key value, key value, key value in a structured language, right? So it's like here, it's YAML. I think now we can all just say like YAML is now the language, right, account native because I think we've all been dealing with YAML for so long. And on the right is basically how to render those. And so, you know, you say, hey, install this application and then put my values there. So you have a, you know, here it'll render the deployment here. What's really, really cool about Helm and Customize is that since one, since Customize is a patching framework that's built into Kubernetes, like every GitOps tool supports it essentially, right? And so you have ArgoCity, Flux, ACM, right? There's even modules for Ansible to, you know, to interact with Customize and Helm. And so Helm also is also supported by ArgoCity and Flux and ACM. So it's essentially become the de facto standard how to deploy that. So really cool question. So would we use one versus the other? The answer is that it's not versus, it's a yes and question, great question, right? I get asked that a lot. It's a yes and, right? You're gonna use both in tandem, right? You're gonna use one over the other. I know some organizations that have their application, but they're using a Helm chart to deploy something that supports their application. So for example, if like I'm a front end developer, right? I'm doing Node.js and I'm deploying a front end, right? With some middleware and then a database backend. I'm using the Bitnami for, you know, my, for my database deployment. So I'm using a Helm chart with Customize for my application and the backend. So you're kind of using both, you know, you're using both, right? So Customize, patching framework. And also the, the templating is a use, use Helm. And so, so best practices for get workflows. And so I'm going to kind of just kind of drill through these Really quick, right? I have like a few slides left, right? So controversy here. Everyone knows this is a controversial subject. I always say separate your YAML from your application code. Separate them. Yes, I'm really serious. Yeah. They'll have independent life cycles. So the idea is that your application code is going to have constant commits and testing on it. Whereas your deployment code, does it really change all that often? I mean, it does change, but not in the same cadence, right? And also there's other other other things that you need to keep in mind that goes along with this, right? You use directories for environment variables. Not branches. Yes, I'm being serious, right? So like a lot of the things that developers do, that may seem natural to do with your get ops repos is actually not, right? They have, you know, even though you're using get, you're using different get workflows. You're not using branches. Cost is from, from CodeFresh has an amazing blog about why you would, why you don't use branches, right? Why you would use directories. But the idea is that a promotion, right? A merge is never simple, right? Because if you're merging from dev to prod, you're not merging the whole thing, right? You're only merging things, you know, like the, like the secrets. The secrets are going to be different. The scale is going to be different. How do you only merge a subset of, it just gets really complicated. I can go on and on about that. But use directory for environments, meaning leverage, customize. And so use chunk based development, right? So, you know, we're going against all grains, right? Don't use branches. Don't use release branches. Use short lived feature branches, right? And then you work off a trunk or AKA main. Yes, we're deploying for me. You can call it whatever you want. But the idea is that you have a short lived feature branch. And, you know, once it's merged into the main trunk, you delete your feature branch. And if you want to know more about chunk based development, you can just Google chunk based development. It's the first hit. And find out more about trunk based development. And you can, you know, hit me up on Slack or Twitter and, you know, talk more about why, why that works for get-offs, right? And so last but not least, use protected branches, right? So, you know, most people can get behind this. Basically branch protection rules, you know, don't allow force pushes, you know, protect against accidental deletion, and it forces code review, right? And approvals. So protected branches is also a good way. And so I see that I'm about a couple minutes over, but I am done. Thank you everyone. This went a lot shorter in my head when I was practicing it. It always does, Christian. It always does. So, so thank you. I'll be in the chat. If you have any questions, I'm going to be in chat all day. So, yeah. So anyways, I'll hand this off to Cornelia here. So.