 Yeah, so my name is Jim, I'm the developer advocate with Harness, and yeah, I'm here to talk about some different ways we can manage our GitOps configuration and how to promote those changes between our different environments. So I'm going to share four different methods that I've seen teams adopt for different reasons, the first being an application where the application and configuration are in the same repository, second splitting up the configuration into its own repository where there's a branch per environment, next again another repository but a directory per environment, and finally splitting up multiple repositories one per environment. So let's start off looking at a repository, this is a node application where we got some application parts of it and then some parts that are specific to its runtime configuration. So I'm intentionally avoiding any file extensions here in case we could be talking about YAML, maybe we could be talking about Terraform, it was a great talk this morning about using Terraform in GitOps workflows, so intentionally not making this specific to any specific tool. So our GitOps tool of choice, maybe Argo, maybe Flux or something, would come along and watch the development file for development environment changes and production for production environment changes. So anytime we need to compare differences between those two environments we would be able to look in one place, so that would be kind of nice. And another advantage would be that the application and configuration are all version together. So if you're ever trying to reproduce a problem, track something down in the future, you don't have to connect the dots between multiple locations to get to the bottom of it. But this could be challenging where if you'd have some kind of CI process that's watching this application, it would have to be smart enough to not trigger when you're changing your configuration files. You could maybe end up in an endless loop there. It could also be challenging if you have to go to your team that's managing your GitOps tool every time you have a new application. Every single repository has its own application this way, it might not scale well. Up next, let's look at splitting out configuration into a separate repository where there's a branch per environment. So changes would always originate in the development branch and then get promoted to production by getting merged into production branch. So these two environments then are just only differing by time. Production is always destined to have development at some point in the future. So this can be challenging where if you make changes in your development environment that aren't ready for your production environment, you might end up having to do some complex cherry picking to pick up the only changes you wanted, so as you're trying to promote them. So that's something to keep in mind. So next, let's talk about a separate repository where there's directories per environment. This is very similar to the example we were seeing before from Bring Central, I believe, from Ivan. So it's good to see that they're using that. So each environment gets its own directory. And when we promote changes, we are ideally just copying files, drag and drop maybe. We should be able to do that. We shouldn't have to worry about the differences in these files. The promotion should be an operation that's a copy operation. The development and production specific files will have changes in them that are meant to be different, but everything else ideally we can just drag and drop. This is what Argo recommends, and I believe Flux as well. Organizations like Adobe and Intuit are definitely using this method. And this is what my previous company, we did, each team had its own repository like this. So it was definitely successful then. Something to keep in mind that I wanted to mention that if you're concerned about security with this kind of workflow, multiple developers being able to change the development and production. Something I just learned about is this feature in GitHub called Code Owners. It's apparently been in there for years. I just found out about it last month. But with this, you can do rules saying, hey, these people or these teams need to approve changes to these files or directories before they can be merged. So that's worth looking into if from a security standpoint, you might be concerned about this kind of workflow. So finally, let's look at splitting everything out with a repository per environment. So here it's the same idea where we have multiple environments, and the ability to copy from one to the other is what we're aiming for. A little more complex now that we have to have two repositories. We've got to make sure we're on the right branch in both of them before we start making any changes and trying to promote something. But that's another way. I've seen companies acquire other companies that are on a different Git solution. Maybe this is what you'd have to do in some interim solution to keep them working together, but being able to use their own Git solutions in the meantime until they all get on the same page. So I wanted to highlight that no matter what workflow you're going through, if you're finding that you're getting dozens or hundreds of lines of changes and that you're trying to review as you promote between environments, an artifact might be able to help you. So Helm charts, maybe Terraform modules we saw this morning using the Terraform operator, then these things can help you to maybe get to the point where your promotion between environments is a version change instead of dozens or hundreds of lines. So that's never fun. Finishing up, here's a bunch of resources. These slides are up on the schedule, so hopefully you can find them easily. If you have any trouble, come find me and let me know. The first article is from a guy at CodeFresh named Costis. It's highly recommend checking out that article. It expands on all these topics, gives a bunch of recommendations and pros and cons. I wrote an article, it's up on the harness blog. Some links to the Argo and Flux documentation and a recording from Costis from ArgoCon last month is on the last link. Finally, if you're interested in harness at all, here are a few links to what we do and some of our community resources will be on the main floor tomorrow and to the rest of the week. If you want to come find us, find our booth. And with that, I'll say thanks for coming. Thanks for listening and find me after if you have any questions. We do have time for any question, like a question or two, if anyone has any. No master, run to lunch. Thanks for that. It was good. Have you considered using Git submodules? I've never had great experiences with Git submodules. We have been burned in the past, but no, that it certainly could work. I'm thinking of areas, nothing to do with GitOps where we've used submodules and it was challenging. But yeah, I can't see why it wouldn't work. Yep. Thanks everybody. Thanks a lot. Thanks Jim.