 The next two presenters submitted talks showing some pretty cool complementary capabilities to meet unique or emerging needs. I was intrigued and I think you will be too. Their presentations are short, providing a taste of their solutions, so you'll want to follow up afterwards to learn more. First we have Axel and Vangelis from Zero One. They will take CI CD standardization even further yet with advanced customization. Then we'll hear from Kevin Gilpin how Appland provides innovation to better visualize your code structure. This could be quite handy when used in conjunction with S-bombs that we discussed earlier, but it could also help with collaboration between Dev and Sec. Hello everyone, my name is Axel Tim. Hello from me as well. My name is Vangelis Kirchimas and in the next few minutes we will showcase you our CI CD architecture proposal that hopefully contains some interesting features. Setting up CI CD pipelines has never been easier than with today's tooling. KITLAB is already a tool both by itself and several other companies have been advancing various parts of the pipeline puzzle. There are existing integrations between these components which can still be optimized further to provide a complete and secure pipeline without sacrificing stability and speed. A complete pipeline has many components, both functional and non-functional. We will focus on the core functionality. Of course the pipeline requires all parts to make sense. The components addressed in this talk are highlighted in both on the left. The reason we picked this component is because we have identified a key paradigm that most integrations do not take into account. On the right hand side you can see the products we use for the implementation, both with customers as well in our labs. Of course it is possible to switch to different products, say Nexus Repository Management instead of Artifactory or a different Kubernetes Manager by adjusting the integration work. The so-on choice is our current recommendation for a modern pipeline. When you first think about integrating GitLab with other components you start placing the GitLab instance in the center of the architecture. But that is not the real story, right Axel? No, you're right Vangelis. The hard work for the integration is happening within the runner as so on the right hand side. It is the runner that delivers to the artifact store or the runtime for building, testing or deploying. Okay, having placed our bets on the runner to do the integration, let's see what challenges we usually face as a customer and what solutions we can design to address this. The most frequent issue we see is in a clean separation of builds from different branches or even projects. Very often a build gets placed in the same artifact store repository relying on versioning, tagging or other naming convention to select the right ones. This cooperative approach often fails and leads to mixing dependencies in builds or used artifacts on deployments. Both build isolation and build reproducibility are affected. The pipeline needs to take care to isolate branch generated artifacts from each other and ensure proper dependency management as well as build reproducibility. Another problem are leaked secrets, like artifact signing keys. If a user has control over a sign job, she can't extract the private keys. The main two ingredients of the solution proposed here are the following. First we need to acknowledge Francis has first class objects everywhere, not only in git. Vault, artifact, open shift all need to embed a notion of the branch as a native structure. The other ingredient is to have the pipeline take care of build isolation, dependency management, build reproducibility, artifact signing and not leave it up to the user in his script space to have to deal with it. This requires a smart runner that will take this burden upon itself in a transparent and simply way. Let's first review what branches are in git and then apply the ideas to all other components. We see some branch named x, which could be the main or master branch or a release branch or any branch for the matter, which within our changing program framework allows to branch off. We branch off the hd's branch, a new branch named y, which is the first green commit has the same code as x at that time. y will get some commit at some point in time be merged back to x. In most workflows, the branch y is discard after the merge has been approved and completed. For example, there will be changes in x happening most likely until y emerges back or some workflow model does not delete the branch y but only merge between branches. That is correct. Nevertheless, the main three operations that are of interest to map to vote or to vote at artifactory and dot cp are branch creation, deletion and branch changes. Like code commits to branch. See how I want to address the branch paradigm to vote. This is quite straightforward. When a branch is created, the vote creates a matching branch account that can be used by the runners and that contains the relevant secrets. We will see in the next slide which secrets are used but for completeness. So let's mention them here. We need secrets or tokens, taxes, artifactory and dot cp and more specifically the repositories and name spaces projects that will be dedicated to this branch. Also, we will need signing keys to sign artifacts. The pipeline will build out of the specific branch. Signing the branch paradigm to an artifact store is the most difficult of the mappings. Here we must make sure that the new branch can access all dependencies as the same external artifacts as the accessor branch as well as all artifacts built by x at that specific point of time. We need to clone or freeze any content of the repositories of the branch. Just as x will likely change during the life cycle of y and y should not use never newer artifacts from x. The exception is when there is a merge from x to y later again, replacing to master or main. This is not depict in the picture but follows the same semantics as creating the branch y. For example, the repositories from x will be cloned again. The point of creation of branches will also need newer repositories for storing and build artifacts from the branch y. These artifacts will override artifacts from the clone repositories from x. So this is indeed the most complex case but at least the end of the life cycle is trivial again, right? Once a branch is discarded we simply delete all related repositories, be that generated artifacts, cloned artifacts or even clone dependencies. One thing is very important and we have highlighted in the slide, we never use any artifacts from y outside of its life cycle. That means we do not copy or move them out before taking down the repositories otherwise we would fail the promised build isolation. Exactly, the artifacts are built in the merge request to the branch x or x anyway so there is no use for them. Finally, let's take a look at how OpenShift deals with the branch party. Here we know that for topic branch GitLab is already proposing and implementing a branch specific environment. In GitLab these are called review apps. Upon branch creation the pipeline identifies the proper OCP cluster to create a new project or namespace and sets up. After a change is committed to the branch that requires testing or otherwise deployment the runner needs to use the branch secrets to prove the environment and redeploy the application. Of course, branch deletion is again trivial and that the branch project is completely deleted. Now let's put the whole stack together and we see that the main components of the pipeline are following the branch padding from Git. From top to bottom you see Git, both Artifactory and OpenShift. This stack takes care of the challenges we mentioned like build isolation and all that by simply applying a natural branch model to the component. Now that we know what we need to do, who's going to do that Ageles? I'm glad you asked that question Axel, we have several angles to place our integration code. GitLab and Git itself comes with a few hooks that trigger upon certain events that we can use. The rest, which actually most of the work needs to be done by the runner. Already identified the runner as a centerpiece of integration in the previous slide. Correct, so let's see how a smart runner concept looks like to complete the solution. A very simple diagram for a runner to focus on two execution nodes or spaces which we like to call script space and system space. As the name suggests, the script space is where the scripts written in the GitLab CI YAML file are executed. They will run in an isolated process space in the runner without any privileges but are under control of the author of the GitLab CI YAML file. This means that anyone who can change this YAML file can output sensitive material like signing keys or authentication tokens to the logs by passing GitLab's masking. It is not suited for our design solution and certainly would mess up the GitLab CI YAML file too much if we put all the logic there. There is also the system space, which is the non-user serviceable part of the runner. This is typically used to set up the job to run, etc., download images and execute the user scripts. We are hooking into this to perform all the required tasks in a transparent way. So at the end of the day, we end up with a custom executor until there is a native branch-based runner. Luckily for us, we have been developing a custom runner since 2019 that has our needs presented in this talk. Here you can see the future of this runner. The ones we need for the concepts presented are highlighted. The rest address, other parts of the pipeline, like security or performance will even subscript your management. Our time is up. We hope you enjoyed the talk as much as us preparing it. For further information, you can fire up the link on the slide. Many thanks for watching.