 So, hello everyone. I am Benjamin and here is Christian. And we are the 42 team, well, and we'll explain that. So, hello, that's Christian and I. So, what's so cool about Cloud Foundry. This is my source code. Run it on a Cloud Foundry, I do not care how. Well, the problem is that actually when you push an app, you don't only, soon you don't only need to push that app. You end up writing a pipeline so that you can push your code to GitHub, for example, and the pipeline is responsible for actually deploying to Cloud Foundry. And soon you get to support chain environments like staging, pre-prod, prod, etc. Demo, dev, integration. That's where the user experience is missing something. And our idea is to provide that user experience as a developer for creating a pipeline right from the start. Well, actually, no, we start pushing it up and then we open that with the pipeline. And later on, so we can add several chain environments. We start with a single one and we can add some more for permitting from staging to prod. So, which, because making the CI CD around your app is time that developers don't want to spend. And in the end, it's quite always the same. You have an app, it's easier, so why would it be that complicated to create a pipeline around that? Let's do it with a commodity. I don't need to re-evaluate all the CI CD tools around there. And should I care actually which one I'm using? So, it's commodity. Let's go commodity with this. Which gives us, here's my code repo, deliver it on the cloud for me. I do not care how. And so instead of having built packs for supporting many application languages, we would have kind of pipeline packs which, in fair, which pipeline to initiate from the code and existing build back and up. Do you have time? Yeah, that's for me. So, let's get back to our code. So, for example, I have, yeah, yeah, surely, surely. For example, I fear the spring music app. All we know, all people of us know it, most of it. It's a simple spring boot application for demo examples which is able to be pushed to the cloud. There is an existing manifest file. So, you can easily push that by building it and putting on your cloud front re-installation. So, what we are now doing is exactly that thing. So, what we are doing is I look into where I'm heading. So, I'm at some point of sight. So, I'm switching now the space to, let's have a look. So, I'm switching to the demo space. So, I fear apps running. I have the spring music app. I already pushed that. I'm now delete the spring music app. Yes, I want to scan and I'm in the repository where the spring music app is. I push it and I'm happy. Because now my app is pushed to cloud front re. There's a route attaching it. I don't have to care. That's our first IQ we had. So, that's what we all know. But now I have to face, I pushed it. I made my code. I have a working version. Now I have to have my continuous delivery pipeline for my developers. So, I'm at a prototype stage and now I want to get really on with my working as a developer. So, now the fun starts. But normally I have to come up with a prototype of my concourse or Jenkins or whatever pipeline and I have to make some things like writing some kind of description for that pipeline. And often it's the same thing. I mean, how often have I copy pasted code from an old pipeline to a new one and then came up, oh, I forgot to change that property. I mean, I named the app there but not there. I didn't change that stuff. So, what I really want to do is that app being pushed by my pipeline in the first place. So, what I do is, what we did is we added a wrapper around, for first start, a wrapper around the, you know, MVP wrapper around the CFCLI which should be later on part of the CFCLI or of the plugin and then doing the stuff for me. So, what I'm now doing is calling that and saying I want a careless deployment. How are we doing that? I'm not sure if I'm a careless deploy. I have to look it up. Wait, it's a demo. It happens. Delivery, I want a careless delivery to the cloud. Okay, I have to provide that name. Cool. Let's start with that. So, I want to careless delivery my spring music app. I have a pipeline. Cool. Let's have a look. Oh, cool. There's a pipeline. Let's start that. Okay, it didn't change something on the code. So, I have to start it by hand first place. As wise, it is already triggered by the code repository. Where does the CLI get that from? I'm in the codes repository. I checked out the code locally so my CLI can read that into formation to get, oh, there's the code. I get that there. In a more productive environment later on, in a later MVP, you maybe want to add the agent for the client's ID of that, of your CICD platform part into the repository. So, it is access to private repository, but for the here, it's okay. So, we're assuming now it's a public accessible repository and now we're pushing the code. What we're doing here is with that part, that task managed CF is accessing the manifest file of the pushed app by using CF create app manifest, reading it and adding that to the pipeline. So, we're targeting that app and saying, I want to that thing be provided later on by the pipeline. The idea is that we know already quite a lot about the app, so we can reuse that information to create the pipeline. We'll find that service because the service already bind to that thing. It's part of the manifest. The create app manifest is updated to the state of what you pushed for that app. So, we have the actual version of that pushed app. How it is, even... You can push first before I use your... Yeah, it's the idea. You may start with an POC. So, we have a proof of concept. You're okay with that? It's the CF push idea. Maybe you could change that later on. If it's... I mean, it's the first draft of our idea. So, okay. I don't have to look. I don't know. It's taking some time. The service in France, so... It's my infrastructure. It may take some time. And by the way, there's an eye-blink because the CF is the easy foundry that was the point when you're on half a go at the... But it's going on. So, it was not the managed CF. It's the part where we're pulling the stuff. No, we're... Okay. It's a little bit slow today, yes? Yeah. Let's step a look back. What would be the next step? We assume that the pipeline will work. We will look after that later. What would be the next step in my development cycle? I pushed several versions now of my application with that pipeline. Okay. Now product management says, you're right on the spot. We want to go to production. Shit. To production. I need another version of my pipeline. I have to extend it. Do I need a new pipeline for production? Or do I extend the pipeline with a new stage? What should I do? Oh, more copy and paste fun. Yes. Or I simply use CF. I know the short version already. But I have to look up the version. Oh, yeah. I want to spin up production. Catchy. Spin up prod. It's a wrapper. You're right. Wait for it. Spin up prod. Okay. What have I to do? Okay. I need a different route than for development. That's for sure. I maybe want to go to another organization or another space. Okay. And what else? Oh, that's all. Cool. It's all duplicating the stuff I wanted to have. And then running that. Cool. Let's try that. Let's have a look first. If the pipeline threw. We fetched the manifest. It's pushing the app now. Okay. The CI is a little bit slow today. Let's prepare the command. We also did that with shorties because we are lazy developers and don't want to tip that. So we are trying to make a new route. Maybe test it. You have to help me if I get it wrong. Easy foundry. Prototype. Prototype. Or let's name it prod. Because it's production. Yes. Okay. And the app name. Don't forget the app name. And space. We can do that. Maybe we push it to prod. But I think I do that there because I know what I'm doing now. So let's have a look. Did we push the app now? Cool. Never was so slow. That's a problem with demo environments. Resources. So this is the push of our app with a fetched manifest. The first call we started. Now it pushed the app. Like you see, it's got all the information about the stack, the routes we had before, and so on. It's repushing that app really. We are waiting for this to finish because the idea of change environments is that the app first is first deployed to the first environment. And then if this succeeds, it can be promoted to the next one. So we have to respect that process. And it's also that we, exactly with the second pipeline, we get that commit which worked in production. So we are referencing now the version which works in that staging context. We want that version of code be pushed to production. And it's done. Cool. And now we can start with our production. Is the space product existing already? Yeah, I did that. Okay. It's there. Now we have a new pipeline which pushes our code to production. I mean, it's a copy of the old one. It's the same. It's nearly the same build. It's the same build pipeline build pack version. So it's the same pipeline pack with a little bit of difference because it knows. Oh, I'm on a, I'm a staged version of the, of the other one. So if I start that T minus S prod CFH CF delete spring music. Yes. CFA. No apps in prod already runs. The time is the download of the docker image for the concourse workers because we want to have some CLI tools in that because it's part of the pack. And we did that in the background because we assume in that case, the CI CD2 should be part of the platform. So it knows where to target on depending on your, your user token for cloud primary it use which space. So it knows which team you are in. So you're essentially your, your pipeline has to go to your team space. So that should be something which is, is handed in, but we maybe could do that with a, with an authentication in the CLI. So it could be a command to, to go to a different target. I mean, it's a rough draft. Yeah. In the background, it's bash at the moment, which runs fly CLI. So what would be fantastic would be to leverage a single authentication, GitHub authentication so that I have a GitHub account. And magically I can push to the CI and CF with that authentication. Or some under SS, another SSL for my company or something. So I don't want to care. I'm a developer. The platform knows what I want to do. Yeah. So after this, you have more. It's the spring app in the prod. Yeah, we can do that. We can do that. So, so we have the demo. What's beyond that? What you, what we are talking about a much is about how is Kubernetes and cloud foundry and functions going together. But from a developer's perspective, it shouldn't be that different. I mean, you have to bring up your, your app to cloud foundry. You have to bring up your containers to Kubernetes. You have to bring up your functions to your functions service, whatever. But after that, for all of these things, you have pipelines. So I'm starting not, we have started with a pushed app, but we could also start with a pushed container to Kubernetes or pushed function to our function service and then say, wrap that up and deliver it for me in a pipeline and look up, up what you want, what you have to do for that, for me. And so we could have this overall experience, which could be cloud foundry. So it doesn't depend on where to push my stuff. I only have my source code. I want to have pushed and then going and having pipeline, you knew pipeline user experience from that. And after that, having overview of my microservices, I pushed to maybe different things. Maybe I added different applications to the same pipeline by my commands and say all these things come up together. I want to have that in one pipeline and it bootstraps them and then prints me out the things, which we're nearly to your idea, I think. So that could be something which comes out of it at the end. So we have an overall full stack feeling with the same painless interaction. And one thanks to Dr. Jules for that because he came up with the idea in the unconference two days ago. So this would be the answer to the ultimate question of life and universe and everything. And that's what we call Team 42.