 So for the delay, my name is Sasha Siegel. I'm going to talk with you today about how GitOps can actually accelerate your CI CD pipeline, including infrastructure and all the other things. I don't have much time, but a lot of slides. So I'm going to start right ahead. As a pre-sales consultant, I'm always working with different companies. And I'm actually having a look into the architecture and the workflows. And we're trying to combine them and make a global standard kind of way to have a CI CD pipeline everybody can benefit from. And that's what we're going to talk about. We're going to talk first about the use case we're looking into a bit deeper. And then I'm going to present to you what kind of tooling we're using during the CI CD pipelining to get an actually deployment on a cloud agnostic way for every customer. What I want you to have as a outcome today is that you remember to always use GitOps, because this is the only way to go. Git is our friend. And the software supply chain management can also be done on GitOps. When you're handling any software, even if it's not your own, just handle them as if they are your own. Work with different teams together, always collaborate by using open source where there's always the benefit of sharing your experience and the easiest ways to do this on the Git way as well. And if you also keep it declarative, like using it in a programmatic way, it's always easier to understand the actual outcome because you're always looking at the differences between the state and the should be state. Okay, let's start with the actual use case first. So nowadays, especially since GitOps, you always have to build it yourself and you have to take care of it yourself because it became easier kind of. And that's what we're looking at. You're always having a IT landscape where you're using multiple tools. If it's just an open stack infrastructure, there are dozens of plugins and tools you have to take care of. And also, when you're doing Kubernetes clusters, you have to take a lot of care of them. We're looking today at an application layer. So every software team creates its own individual app and it relies on a lot of open source tools. May it be some database management tool, a message broker system, or even the ingress controller inside a Kubernetes cluster. All those have to be deployed and always have to be in a software development lifecycle managed in an easy way and in the best case, standardized. So if you're going with a GitOps lifecycle, we always have to repeat this software development lifecycle for each and every software we're using. This can be a huge workload for the development teams and just for the individual app, you're actually developing as a development team. You're having the software engineering team who is actually pushing to Git. The Git repository just confirms it or gets merged and then it goes through the continuous integration pipeline or delivery pipeline by building the containers maybe and pushing it the resources somewhere, updating the configs for your application and then it goes over to some system engineers or the users. The users also have to check are the configs up to date? Is it running in my runtime environment? In this case, Kubernetes. And only when they tested it on development and staging, they can push it to production. And this has to be repeated many, many times. And thanks to CI-CD and thanks to third party software, there's one huge workload already done, the coding of the software. So we can actually just take the different software components, the modules, put them all, mesh them all together and we have our IT landscape. And all we have to do now is just the system engineering work by configuring each and every application. Since lock for shell, a lot of people still wonder how can they take care of all this supply of all the software we're using from the open source community. And that's what we wanted to achieve. We wanted to set up the whole environment to the runtime environment, starting on the left from your individual application repository, taking all the building blocks, we call that. So the third party software measured all together in the Git and then just push out or just deliver a whole setup, which is pre-configured and always can be used on any infrastructure you choose. So we're gonna talk about the first part. So we are talking about the software supply chain tool, tool chain actually and what kind of tools we used here. So the basic layer for our pipeline is GitLab as a Git repository and GitLab CI as a environment to run the tasks for the CI CD pipeline. We're always expecting the software delivery to have two different things, the configuration and the actual package. In this case, for Kubernetes, it's Helm charts or Helm files and a Docker image or multiple Docker image. And then we have two different tasks to actually accomplish. May it be some CVE scans of the Docker images, some config templates for the Helm files to give some individualization course, policy testing, deprecation testing, all this has to be done before we can actually go to production to make sure that everything is running smoothly. So the GitLab CI stages we defined are six in total. So there's a dot pre-stage which actually gathers all resources. We can say are always the same for each and every building blocker for each software service. Then we have a linting stage where we're trying to find out where we're trying to lint mostly. We're building it just to make sure that the build process is done correctly. Then we go on to the test stage. We're gonna do a release where we're bundling it all again and the post stage we're just cleaning it up. The main goal is to offer all those software servers on the right, on a global CI CD pipeline which is configured all the same. And the dot pre-stage, as I said, we have different scripts or checks for style guides, semantic versioning, policy testing, and so on and so forth. It's pretty small work you have to do there and besides all the linting which is always part of some tooling. You have to be pretty precise. So also including the fact that you want to be declarative. So we don't do this in a programmatic way. We chose to do this in Python scripts. Everybody talks Python nowadays. If you're having any linting libraries or something, we always found them in those libraries already existing. So we work with the people together, find out how the linting libraries work there or the deep diff and that's the first one to go to actually create the first templates. I've been talking about linting before in the first stage but the main stage starts actually here. So we have to check the standardized resources. May it be some Helm charts, code changes which can be read out of release notes or even some dependencies. That's what we're scanning here. This is not only linting itself but it's a huge part of it. The focus in linting is also to see if everything is done correctly on here. So that's why we chose another tool on here, the Open Policy Agents extension if you may or extra tooling called Conf test. This gave us the opportunity to have a easy readable config and easy writable also to make sure that each and every resource we're actually gathering is ready for our infrastructure or our runtime environment itself. In the testing stage we have to split the first time. Remember that we wanted to build a pipeline for each and every tool the same way. We now have to actually split it up because now each and every tool has some test cases which can't be generalized for the other ones. So if we're talking about the specific cases, we're talking about smoke testing, the initial deployments, some best practices are also gonna be included in here and this is what's been done in this stage. First of all, because we are now individualizing a bit more, we also wanna offer to each and every contributor the opportunity to make it individual itself. So we're extending the Helm charts with Helm files. So we're having ready to go templates and also have some go templating to make it easier for each software and system engineer to contribute to the testing environment and especially to the best practices configs. I talked about the smoke tests. I can only recommend the Golang itself because this is more close to the infrastructure or the runtime environments. We're having the most experience with Kubernetes and there we can actually write the smoke tests more precisely. The last stage I wanna talk about is the release stage. That's the stage where we're only bundling the different Helm charts. We're putting in some more best practices config from the go templates we've created. We're offering all the release notes, the docs and workarounds if there are any when you're trying to update from one version to another and we're also offering for an easier use case different CI templates. So if you're trying to create a deployment pipeline by yourself, you can always rely on some templating we've done in the global settings. There's one tool I wanna recommend you highly. This is renovate. The renovate bot actually gives you the opportunity to check automatically for each and every version. This is described in your CI CD pipeline and in your Git repository and we had over 100 updates per week for those 12 building blocks we've had in January. Okay, so this was lightning talk. So what is left? I've been talking about the CI CD pipe landing and if we go through the software development lifecycle we have the code checking, we have the building, we have the testing, we have the releasing and even some stuff you can just deploy and run. But they are two important things missing. This is once monitoring and operations management and the big question is how we tackle this. Operations management and alerting is always a very individual and reactive task. You can't automate those things, you just have to experience it. That's just like the hell we're working in. But there's one big approach I can always recommend and that's how we work with our customers and internally this is always shifting left. As soon as you have made the experience everybody's gonna actually enjoy having some, your experience as well. So share it by shifting left. Have the experience, write a smoke test or something and others will take care of standardizing in the way we do, for example. The benefits are I hope pretty obvious. So we can integrate multiple services into runtime environments, cloud agnostic. We can also have a already prepared CICD pipelining for a new service. So if you're creating new service all you have to do you just put it up there and then you can start with shifting left right off the start. And the collaboration also means that you don't have to work all by yourself. You're getting extra resources by everyone who uses them. This is actually the pretty neat one. And the transparency of course. Because we do need on GitOps, we are working programmatically, you're always being transparent with what you're doing during your tasks. So I spoke pretty quickly. If you didn't understand anything, just hit me up. I'm going to be here on the conference the next two days as well. You can find me on this is 11 booth and we can go into that with a more big detail. If you have any questions, just go to the microphone and go ahead. Thank you very much for you.