 Yeah, okay. So I'm here to talk about piecing together code application and Helm charts into one repository. I'm Omar, I'm a staff engineer at the Infra Group at SNCC where we practice platform as a product aiming to lower the cognitive load of our developers. Most of a long time using Augusta Day, really amazing to see so many people in this room today. And yeah, so I'm here to talk about one of the most common practices and documented as best practice of separating application code from the Kubernetes configuration. Because two years ago, we kind of broke it and combined them together into one repository. So our story really begins with two repositories. We follow the best practice, we create a repository for the application code and a repository for the Helm chart that has the Kubernetes config. And we build a deploying pipeline, a very simple one. It's build an image and it then changed the image tag to the version that was need to be deployed. And most of the time that was great, but in some use cases that increases the cognitive load significantly. And one of the best examples was when adding an environment variables. Because when adding an environment variables, the developers start with changing the code, introduce a code change that uses that environment variable. And that will deploy with the simple deployment pipeline, but nothing happens in the application because that environment variables not being called, nothing has changed. The developer need to remember, it's need to now get clone the Helm chart repo. So he does that, get clone, he finds the right service in that monorepo, the GitOps repo. He changed, he reduced the new change of the environment variables, he opened another PR, he gets another review, and then he's standing in the room and he's asking how I'm going to deploy that weird GitOps repo, I just clone it. I have nothing, this is the first time I'm doing a PR, he's standing there and asking for help and then he's come for us. That cognitive load, we don't want. I believe we can do a better developer experience for our developers. But best practices has a good reasons and Argos CD is doing amazing job in documenting that reasons. So we went after them and first one is separation of access in some organization. Different people change the Helm chart from the people that write the code, that's not relevant for SNCC. At SNCC, the application developer does everything. They own the whole application end to end. The second one is sometimes you can modify only the manifest and that can trigger a faster CIN CD, although that's true. We just saw having two different ways to deploy is not the best experience. Application can be built from different services so this is still possible under a solution but we found that it's not the most use case in SNCC. So in most applications in SNCC, the application builds from one repository. It can have different third parties but only one place with SNCC code. So rolling out those three, we're left with clean audit log and infinity CIN CD loop in the case where you aim to commit back the version to the same repo with the application code and then you trigger another CIN and then trigger another CIN. So the question is can we combine those two into one but have a clean audit log and without infinity CIN CD loop? And we found that the answer is yes, we just need to find a different place to commit the version. We still want a version. We still want it to be inside Git. So finally, our solution was to use the app of apps repository. So we already have that, we already had an apps of apps repository with the application CRD inside of it. This is what create all the application inside the cluster and we added the version of the application to the values. So every service now has a version for the pre-pro, the staging cluster to the production cluster. It can be different in the deployment system but eventually it will be the same. And now the application CRD template, the Helm chart can use that version. So we can see it's going to find the right version per the cluster and we'll inject that as Helm parameter to the Helm template. So the application can use that image tag value inside their versions, inside their Helm chart, sorry. And combining this together, we now have only one deployment pipeline because everything is inside the same repository, both the Helm chart of the application and the application code. We have only one deployment. It will always build a Docker image. It will always change the right version once for pre-prod, once for prod and it will actually do two things. So it will sync the app of apps, the application CRD itself, it will set the right application image tag parameter and then it will go and sync the application itself. So that solved that problem but we also got one amazing benefit from that. We now also have a version for the Helm chart. So we're not tracking the main anymore for the Helm template and we don't need to set different branches for different environments. We don't need to set different values or find different weird ways to deploy that GitOps repository. We can use the same version and have the Helm chart in the same version of that as the application code. And with that, we achieved, we reduced the cognitive load of the developers. We allow them to work on only one repository, one deploying pipeline and with one version of the Helm chart. So thank you and see you later.