 Hi, everyone. Good morning. Thank you all for being here today. My name is Jesse Suan, and I'm the co-founder and CTO of ArgoQt, and also one of the original creators of the Argo project. If you haven't heard of Acuity, we are a team made up of Argo creators, leads, and maintainers of the Argo project. And we help companies implement GitOps with Argo. Acuity offers a platform for running a more scalable, secure, and easy to manage version of Argo CD. And we also offer solutions and support for the Argo projects. So today, we'll be talking about some of the limitations and challenges you might be facing implementing GitOps with Argo CD and how an open source tool we're building called Cargo complements Argo and helps fill those gaps. All right, so first, let's talk a little bit about Argo CD and why it often isn't enough. So we built Argo CD as a tool to help users deploy to Kubernetes while practicing GitOps. And Argo CD is great at deploying changes from Git to a single environment. But there's a lot of things that it doesn't do. First, it has no concept of a pipeline that can orchestrate deploy across your environments. It doesn't even help you write changes to Git. It expects some other process to do that ahead of time. And finally, once it syncs an app, it doesn't do any form of verification of the update after the fact, such as running any form of tests or analysis. So Argo CD is CD, but with some limitations. So what most people end up doing is using their CI system to drive their promotion pipeline. But fundamentally, CI and CD have different goals. And we feel that these CI systems are being overleveraged trying to do the work of CD. For CI, your primary goal is given some code, build and produce an artifact. With CD, your goal is given an artifact, roll it out as safely as possible. CI pipelines tend to be short-lived. You have this predefined beginning and end. And your pipeline is done once your job completes. When you define your CI pipeline, you do it in this rigid top-down definition like a Jenkins file. This is fine for short, repeatable tests, like unit tests or EDE. But it becomes tedious to run and debug when you have longer, more complex, and dynamic pipelines. On the other hand, CD is often this long, drawn-out process that might run indefinitely with things like canarying, manual testing, and approvals. And these days, CD requires a lot more flexibility. For example, your deployment process might involve the AB test, where you might not even know which version will end up in production. And over the years, a number of techniques, small features, and projects have popped up to deal with some of Argo CD's limitations. And I call these spot solutions because each one of these techniques or features solve one small piece of the overall puzzle. And so with all these approaches, it feels like we're just trying to brute force Argo CD into doing something it was never designed to do. So after helping a lot of users practice GitOps with Argo CD over the years, we realized there needed to be a better developer experience around multi-stage promotions in this new world of GitOps, microservices, and deploying to many, many environments. And so we created Cargo. So what is Cargo? Cargo is a higher-level tool that integrates and is layered on top of Argo CD. That brings a couple of new things to the table. First is the ability to create a flexible pipeline for defining how changes are promoted between your environments. Cargo has a dashboard with a UI that gives you visibility across all your environments. Cargo hides the nuances of GitOps to developers who really don't care about GitOps. And most importantly, Cargo helps you practice safer deployments by enforcing proper processes as well as being able to perform testing and verification between your stages. So with Cargo, you get better visibility into your promotion process by seeing all your environments at a glance. And you can understand what's running where and what's safe to deploy. You will be able to see the differences between environments and how far back different stages are from each other. And we built Cargo with the GitOps use case in mind. And one of the unique features about Cargo is its ability to promote Kubernetes manifests and not just image tags. Cargo will actually make Git writebacks and rollbacks really easy with a click of a button. And it even supports the option for opening pull requests instead of writing directly to Git. Cargo enables you to start practicing progressive delivery by running your tests and analysis as part of the deployment process. And these can be enforced so that you can only promote things that have been verified in earlier stages. And in terms of where we see Cargo going forward, we feel the benefits of Cargo actually extend beyond Kubernetes. And so we wanna make Cargo a solution to integrate with other technologies in configuration languages, such as AWS lambdas and Terraform. And we want Cargo to integrate with other well-established tools aside from Argo CD, such as HashiCorp or Atlantis and promote other non-Cubernetes configuration such as Terraform HCL. So if you're interested in Cargo, please check out our GitHub repository, join our Discord, and also just stop by the Acuity booth and we'll be happy to answer any questions you have about the project. Thank you.