 Hello, everybody. Welcome to Best Practices for GitHub's repository. It's a very popular question. Thanks. So my name is Costis. I'm working remotely from Greece for CodeFresh. I'm a developer advocate. I'm also an Argo maintainer, so I contribute to Argo documentation, mainly for Argo Loads and Argo CD. If you don't know anything about CodeFresh, it's the enterprise platform for Argo. We have a booth downstairs, so you can ask us more questions. And if you have ever taken the first GitHub certification, I was one of the co-authors, so if you have any feedback, you should tell me about it. If you haven't, go to learning.codefresh.io and start it. It's free at this point in time. So, okay, you learn about Argo CD, you install it, you finish the initial installation, you set up security. And one of the most common questions you have on day two is how you organize your GitHub repositories. I've been monitoring, you know, the Slack channels, the GitHub discussions, issues, and everybody's asking the same thing. How do I organize my GitHub repositories, or how do I make promotions? So if I have, excuse me, the three environments, QA, staging production, how I make promotions from one to the next. So this was a very popular question, and I was, you know, tired of understanding the same thing all the time. And I said, let's write some articles to solve this issue once and for all, and this presentation is a summary of those articles. It's only 10 minutes, so if you need more details, you need to read the articles. So when I talk with people, obviously they have many choices on how to do this, and it's not only, you know, the three popular ways like branches, folders, or repositories, but also the combinations. So a lot of companies, they say, oh, I'm going to use branches and repositories. So folders and repos. The combinations are endless, and people don't know what to select. So I'm going to give you, like, a starting point, and I'm going to start by what not to do. And then I will say what you should do. So don't use branches for GitHub's environments. And just to make things more clear, don't use long-running branches for GitHub's environments. It's okay if you have, you know, short branches, so maybe you want to have a feature. You create a short branch. You test your feature. You create a full request. And then you merge it. That's fine. I'm not against it. What I'm talking about is this scenario. You have long-running branches that always exist, and maybe they have the same names as the environments. So let's say staging, staging, QA, QA, and then production, production, or main. And the way that you do promotions is you say, okay, I have some changes in QA. I'm going to do a simple git merge and go to the next environment. Another git merge and go to the next environment. This is the pattern that I'm talking you should not adopt. Now, when I ask people why they start using this environment, like why they selected it, the answer I expect is we had an evaluation. We tried everything else, and this was the best choice. But almost always, the answer I get is, ah, we were using GitFlow. We knew about GitFlow, and we did the same thing. So this is wrong. If you go today to the page that explains GitFlow, there is a huge warning message from the creator of GitFlow that says you should not use this. So don't, you know, believe me. Believe the creator of GitFlow. Go and read it. The other problem is that people are getting confused and they say, okay, I'm using, let's say, GitFlow for my source code. I'm going to use the same thing for my manifest. This is not true. One of the first best practices for Argo is that you should split your repositories. So you have one repository for source code, one repository for manifest. They are completely independent. So even if your developers still want to use GitFlow for some reason, they can do whatever they want on their own repository. But on your repository, you should use trunk-based development and folders, as you will see. You should not confuse those two, let's say, practices. Each repository should do something different. But the most important point, if you ask me, like, why you should do this, is that in theory, yes, in simple cases, if you do a Gitmerge, you get all the changes, let's say, from QA to production. But there are corner cases, and depending on your company, maybe it's not a corner case. It's a usual case where you don't want to bring everything. So here I have an example where in staging there is a number of changes. And somebody says, usually, business, we want you to take this change and this change and that change, but not that one. So doing a Gitmerge will not work. So then you say, OK, what I'm doing, I need to start learning about cherry pick and start picking the commits I need and it gets complex quickly. So don't do this because it's getting super complex. So what do you do? Now I can say, do the same thing as Adobe. That's the correct answer or into it. Yes. Thank you, thank you. Use folders. Yeah, use folders. Do use folders. So what I'm saying is that each environment should be a folder in a single Git repository. There is only one branch. The example on the left is one of my simple examples that they have in the articles. The one on the right is the one from last year's presentation not going to come from into it. So this is how into it organizes their environments. And when I update my presentation, I will also include Adobe and say Adobe also does this. So that's the recommended way everything is a folder. And all the environments and folder, you only have one branch and then things become really simple. You can just copy files around. You can select everything that you, anything that you want. So let's say you're using Helm. A good practice would be to have multiple value files where let's say one value file is the container image. Another value file is settings that you want to promote. Another value file is settings that you don't want to promote. So during the promote, you can decide what you will take. The order of commits does not matter anymore. You are not only copying files around. And if you have five environments, you have one branch. If you have 20 environments, you have one branch. If you have 15 environments, you still have one branch. The complexity is always the same as far as branches as concerned. So if you have this corner case a lot where you need to know to promote stuff out of order, this is very easy to do when you use folders. So start using folders. Another important point is that if you look at the existing ecosystem of Kubernetes, these folders are very easy to support. So if you're using customize, customize says okay, I will give you overlays for different environments and they are folders. If you're using Helm, Helm says I'm going to give you values and you put values in folders and it works just fine. Argos CD has the capability to use folders so you can have a mono repo with multiple applications and it's very easy to say to Argos CD, this folder is this application, that folder is that environment without any issues. And application sets, if you're familiar with application sets, there is a whole generator, the git generator where you can have a folder pattern and say my applications are under this folder. So if you're using folders, the tools are helping you. You're not going against your tools. While if you're using branches, customize has no concept of you know that a branch is an environment. It says that an overlay is an environment. So these are the links to the two articles I talked about. So if you want to know more, you can read them. There is also a huge discussion in GitHub that one linked which contains my opinion and the opinions of other people. It's very long to read but if you know you want to do research, you should read it and let's say all the possible combinations. And if you want to play with this pattern, you don't need to set up anything. The certification that I talked about, there is a level two and one of the lessons is exactly that. How you promote with three different environments where you use folders. So you just launch it and in your browser you get an Argo CD instance, a Git repository with three folders and even a GitHub action pipeline instead of Argo workflows that copies file from one another. So if you want to see a quick demo of how this works, the easiest way is to go there. And the last one is the presentation from Intuit from last year that had the picture I talked about. I will also include the Adobe one in the next presentation. So that's it. Thank you very much. We are right on time so I don't think we have time for questions so find me afterwards and ask me anything or tell me that you are wrong and I will still use branches.