 So, hello everyone. Hope you have a nice time here at GitHub's con. Today I'm going to talk about GitHub's with captain. So, at first, I think many of you might not know what captain is. So, captain is a control plane for an application lifecycle. So, a bit of password bingo. So, it can combine a lot of tools in your whole deployment chain and yes, help you, helps you combining all of these tools and can help you taking decisions based on SLOs and based on not only one metric, but on many metrics. So, yes, long story short, so why am I here? This doesn't have anything to do with GitOps. So, we think that keep captain and GitOps is better together. So, why do we think this? At first, we can use our GitOps tools and frameworks to detect changes and reconcile our deployment. On the other hand, captain itself is very good in unifying workflows and making deployment decisions. As it is very well integrated in monitoring solutions and it can calculate metric, can calculate SLOs and take decisions based on that. So, for example, you can do some kind of performance tests, you can do security tests, but can also do some chaos tests and combine all of this in one SLO, in one metric and captain takes the decision if this is okay for the next stage or not. And yes, we think that captain is good in orchestrating GitOps workflows across multiple stages and across multiple environments. So, yes, I would not be here if we would not have some projects in captain for that. So, currently, we are driving two efforts. The first one is configuring captain itself via Git and the second one is integrating tools like ROCD and flux into the workflow. So, what were the user's challenges until now when operating captain? So, at first, captain is based on imperative commands. So, they had to execute many commands in a defined order, as we all know it from imperative tools. Furthermore, often they ask themselves, how do I update a Helm chart? Because captain itself has an artifact store and you have to upload the configuration. Furthermore, the configuration is sometimes not really reproducible. So, last but not least, we came to the point that we said users want to deliver software, but not to learn captain. So, we thought that it must be an easy way. And so, we wrote some controllers, we integrated something in Git and said the only thing a captain user should have to do is a Qubesidel apply minus F and his configuration to the Git repo. So, in our case, so I think this is pretty small in the slide. We only defined that the captain configuration is in some Git repository. You can add the user names and passwords in an encrypted format. And afterwards, the captain operators do their work. And this is the big picture. I think you don't need to know everything about this, but here you have some kind of configuration repository as we know it from our Git Ops landscapes. We have a Git repository in captain which can reconcile against the configuration repository. This applies everything on QNITUS and pushes something to the captain configuration repo if some artifacts are there. And on the other hand, we have a captain operator which talks to the captain API and reconciles and knows how to deal with captain itself. Okay. So, this was the first thing. And the second thing, and this is the newer part of all of this, is we tried to build some integration into Git Ops tools. And in the first step, this was only Agocity, but it is also doable with Flux, I think. So, at first, yes, we could integrate Git Ops controllers like Agocity and Flux in our workflows. I will come to this later a bit. Furthermore, as we want to have a Git as a single source of truth, we want the current state always in the Git repository. So, we would do the promotion now not workflow-based, but Git-based via the repository. Furthermore, and in a later step, it should be possible for you to use your favorite controller to deploy and reconcile. So, you should have to be able to take the decision if you want to use Argo or Flux or any other tool which will come in the future. And last but not least, captain gives you the freedom to use your favorite tools to test. And you can also use which observability solution you want to use to calculate your decision metrics. So, currently, we are supporting Prometheus, Tynotris and Datadoc. So, how does this integration look like? At first, we have our Git 3.0 and we have our Argo instance and our captain instance. At first, we use Argo in this case to detect changes on the Git repository because we think that the Git Ops tools like Argo and Flux know best how to detect such things. After that, we kick off the deployment process in captain. So, we send some kind of Argo notification to captain. And we also notify captain about the app name because Argo itself does not know about stages. And we take some labels from Argo and also pass this to captain. Later, captain triggers the deployment itself. So, we define a web hook in captain. And this simply triggers the Argo API and sends some information we need in captain. So, as the captain context, which is kind of a correlation ID, and this gets passed through the whole deployment process. And this is the thing which what captain makes out of this. So, we get a stage, we get results and so on. And yes, in the end, after everything has been deployed, Argo triggers Argo, sends the result back to captain. It's also notification, it also sends some variables in configuration. So, that captain can continue its workflow. So, in further consequence, captain can run tests, it can evaluate what comes out of this. And last but not least, captain can raise a PR for the next stage. So, what we see here is what we would see in the demo. So, on the left side, we see the execution of the sequence itself. So, we have a kickoff step. We have an artifact delivery step. We can test everything. We have an evaluation. And we see here how such an evaluation result could look like. And last but not least, we can do the promotion to the next stage. So, what did you learn today? At first, captain can orchestrate Github's deployments. Furthermore, the integration between captain and every Github's tour is based on webhooks and notifications. So, webhooks on the captain's side, notifications on the Argo side in this case. We use Argo flux for deployment, but captain is very good in taking decisions and validation of all of the deployments. And last but not least, we can do some kind of promotion via pull request. And all of this is available on YouTube. So, there are already demos of both prototypes. And if you are interested in watching this in action, feel free to watch this on the captain YouTube channel. So, this was pretty short for all of the content I had to deliver today. If you want to talk about this or if you have better ideas how to deal with exactly this, you can visit us on the booth G18, so on the captain booth. And yes, I can also show you how this looks like and we can talk about this. If you want to take this offline, you can help building better integrations between captain and the Github's landscape. You can find me and us on the captain's leg. And there is a working group for the captain Github's operator, which also contains all of the rest of the Github's efforts. And your ideas are valuable. So, in captain, there is also a concept of enhancement proposals. So, our enhancement proposals for the whole Github stuff and for everything you saw here. So, you can comment on this or I can raise your own enhancement proposals. And yes, this was it from my side. So, I hope you had some kind of fun. I hope I could give you some kind of insight. I hope you had fun. My name is Thomas Schütz. I'm a principal engineer at Dana Trace and head of the CNCF at Captain Lüge. Thank you.