Cloud Native Computing Foundation ArgoCon 2022, 21 Sep 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Best Practices on Organizing GitOps Repositories - Konstantinos Kapelonis, Codefresh

Description

Lightning Talk: Best Practices on Organizing GitOps Repositories - Konstantinos Kapelonis, Codefresh

One of the first questions that must be answered when adopting GitOps, is how to organize the various Git repositories. Environment-per-branch? Environment-per-Repo? Environment-per-folder?

This talk examines some common patterns and practices on how to organize the Git repositories along with their advantages and disadvantages

A

Hello, everybody welcome to best practices for github's repository is a very popular question.

A

Thanks so my name is Costas I'm working remotely from Greece for code, press I'm, a developer, Advocate I'm, also an Argo maintainer, so I contribute to Argo documentation, mainly for algoro louds and Argo CD. If you don't know anything about code, press is the Enterprise platform for Argo. We have a booth downstairs, so you can ask us more questions and if you have ever taking the first gitup certification, I was one of the co-authors. So if you have any feedback, you should tell me about it.

A

If you haven't go to learning.codres.io and start it, it's a free at this point in time.

A

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 gitlab GitHub discussions, issues and everybody's asking the same thing: how do I organize my github's repositories or how do I make motions? So if I have a excuse me, the three environments QA stayed in production, how we make promotions from one to the next.

A

So this was a very popular question and I was you know, tired of financing. The same thing, all the time and I said: let's write some articles to solve decision 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.

A

Oh 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.

A

They say I'm going to use branches and reports the result for this 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, you 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 third branch.

A

You test your feature, you create a pull request and then you merge it. That's fine I'm, not against it. What I'm talking about is this scenario.

A

You have long running branches that always exist, and maybe you know they have the same names as the environment, so let's say staging States in qaqa and then production in 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, I'm going to navigate, merge and go to the next environment. This is the pattern that I'm talking you should not adopt.

A

Now, when I ask people why they start using this environment like why they selected the answer that 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 a git flow, we knew about git flow and we did the same thing.

A

So this is wrong. If you go today to the page that explains git flow, there is a huge warning message from the creator of git flow. That says, you should not use this, so don't you know believe me believe the creator of git flow go and read it.

A

The other problem is that people are getting confused and they say: okay I'm using uh let's say git flow 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 git flow for some reason, they can do whatever they want on.

A

They know 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, um let's say practices. Each repository should do something different.

A

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 git merge, you get all the changes, let's say from Q8 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.

A

We want you to take these chains and these chains and that change, but not that one so doing a git merge will not work. So then you say: okay, what I'm doing I need to start learning about cherry pick and start pick the comments. I need and get complex quickly. So don't do this because it's getting super complex.

A

So what 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, yay, useful, there's, no use folders. So what I'm saying is that its 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 I have in the Articles. The one on the right is the one from last year's presentation not going to come from into it.

A

So this is how Intuit organizes their environments and when I update my presentation, I will also include the Adobe and say: Adobe also does this. So that's the recommended the way everything is a folder and all the environments unfolded. 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.

A

Another value file is settings that you want to promote and other value files. The 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 only copying files around and if you have five environments, you have one Brands. If you have 20 environments, you have one Brands. If you have 50 environments, you still have one branch. The complexity is always the same as far as branches as gonna send.

A

So, if you have this coordinate case, a lot where you need, you know to promote stuff out of order. This is very easy to do when you use um 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 their folders. If you're using help, Helm says I'm going to give you values and you put values in folders and it works.

A

Just fine argosdeep has the capability to to use folders, so you can have a mono repo with multiple applications and it's very easy to say to Argo CD. This folder is this application. That folder is that environment without any issues an application sets. If you are 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 are not going against your tools.

A

Well, if you're using branches customize has no concept of you know that a brand 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.

A

But if you know you want to do research, you should read it and, let's say all the the possible combinations, and if you want to play with the 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.

A

How you promote with three different environments where you use folders, so you just learned it and in your browser you get an argosity instance, a git reporters and even a GitHub action pipeline instead of Argo workflows that copies file from one 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 the presentation from input from last year that had the picture I talked about. I will also include the Adobe one in the next presentation.

A

So that's it. Thank you very much.

A

We arrived 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're, wrong and I will still use branches.