 Hi, folks. Thanks for having me at the Crossplane Community Day 2021. And it's been super great to see this event being co-located with KubeCon EU. Today, I want to talk about setting up new applications and connecting CI-CD systems from a platform's perspective. So we start with onboarding and onboarding of developers. As an example, I remember the DockerCon demos really well for that. Most of the times, they had two people on the stage showing how easy it is for a new developer to onboard an application. They praised the demo gods, which was apparently a pretty important step. And the new developer checks out the application from Git, makes a couple of changes, and builds and pushes to production. And this is awesome for developer onboarding. It's pretty exciting. But today, I want to talk about onboarding new applications. And if you're in a large organization, this is something which happens pretty regularly. And there are usually lots of manual steps like finding the correct place, setting up Git repos, connecting CI systems, deployment manifests, et cetera, et cetera. And as a platform team member, that is something which we want to automate. So let's take a closer look at onboarding new applications. We want a couple of things, like a location to store the source code, a continuous build setup, an artifact repository for the container images, a continuous deployment setup, and nowadays also a GitHub setup. And there are a couple of different systems involved, namely a Git repository, obviously, an execution environment to run all those things, and nowadays, a GitHub software, which is a control loop from the Git repo to the execution environment. And the steps are mainly to create and configure the Git repo, to manage the deployment tokens, for read-only access to the Git repo, to create and deploy continuous integration builder, which is connected to the Git repo and has access. Obviously, the application needs to be deployed. And for the GitHub software, we also need to connect the Git repo. We need to connect the execution environment, and we need to create an application in the GitHub software, which connects those two things. So we can do that manually, but we can also use APIs for that. And there are a couple of systems. I've listed some of the popular ones here. For example, GitHub, probably everybody knows. There's also GitLab and Bitbucket, which offer an API for Git repos. For the execution environment, there's Kubernetes, because we are at the KubeCon event here. And for GitOps, there's Argo CD and Flux, which are pretty popular. And all of those offer an API for configuration. And in theory, we can implement those APIs in a custom software, which automates the steps mentioned on the left. But where should we start with that? So since we are at the crossplane community event, we will use crossplane for that. And crossplane has the feature of providers which implement arbitrary APIs and mirrors them into Kubernetes. And this is really helpful because we now have drivers for each of those APIs and are able to configure the systems in a standardized way via Kubernetes. So for example, we create a YAML file for the Git repo, a YAML file for the Argo CD application, and so on and so on. So that's really great, but we still need to know what to put in those YAML files. And since they expose everything the upstream API offers, it may be a little bit too much for us. So how can we provide a better onboarding experience? Enter crossplane compositions. A composition is a templated resource which acts as a controller and creates from a single YAML file several other YAML files, easily speaking. And in crossplane speaking, it's an XRC, a Composite Resource Claim on the lower left as an example here, and this one is namespace scoped. And whenever an XRC is created by a team, a controller will create the cluster scoped XR, the Composite Resource, which creates and keeps track of those single CRs which are then reconciled by their respective provider. For example, the provider GitLab for the GitLab API. And now let's take a look at the demo with all those things together. What we see here is a composition. And this composition basically creates all those single CRs when it's invoked by an XRC. And we see here, we create a GitLab project, deploy token to connect to the project. We deploy a GitLab CI runner, an Argo CD repository, and an Argo CD application as well. And this is the XRC, which is created from us, from basically this is the API surfacing to the developer who wants to create a new application. And the only field we chose to make configurable is whether the blueprint which will be imported into this new repository, whether that would be a Java blueprint or something else. And in this example, it will be a Spring Boot Java Blueprint. So when we deploy this XRC, we can take a look at GitLab. And we see here in our example group, there's no project right now. But if we update and reload, there is our example project which was just created by our provider GitLab, by us, basically. And if we go into it, we see there is our blueprint Java service, which is basically listed here. And we can also see, since we want to deploy a GitLab runner, we can also check if the runner was deployed 10 seconds ago. And this will start and connect to gitlab.com. And we should be able to see in the CI CD settings our runner very shortly. Here it is already. This is our freshly deployed GitLab runner. And we can start using it. So let's check out the repository. So we write back the URL to the status of this above resource so we can easily use it in other fields. All right, here we do have our Java application. Now let's make a simple change and change this to crossplane community day. Save that and commit and push. So we do have a GitLab CI set up here, which is basically just a Gradle build of the Java software. And we use GIP to push it to the GitLab registry. So if we go back here, we see, yep, there was a new runner being spun up by GitLab, which will now execute those steps. And if we go back into our overview, we can see the pipeline run. And this will now happily build and push our container image with the new steps. So this will take a while. It will be a bit longer than we have for our 10-minute talk. So I've provided a static image already and hooked that up to our ArgoCD thing, which we can take a look here. So in ArgoCD, there's the Git project being connected. And via those read-only tokens, we created at GitLab. And we also see our example app. And if we check our example app, we see there's a service account and a deployment, which is basically exactly that what is here in our chart. Because this is being used by ArgoCD to deploy the application. And we can also check kubectl forward forward our example app 8082 to 8080. And take a look what we will find at 8080, 82. That worked, obviously. OK, that's it. All of this is open source. You can find the Kubernetes controllers via those links. There are also a couple of other ones from the community. For example, for GitHub and Bitbucket, there are also some folks who use Flux instead of ArgoCD. So the choice is really yours. And if you want to get in contact, you can find me on Twitter or crossplain Slack. That's it. Thanks for listening. And have a great community day. Bye-bye.