 Hi, it's Mark Punsock, head of Product at GitLab, and I'm going to show off an idea we have for Auto DevOps. At GitLab, we believe in learning the best practices from around the industry and making them available to everyone in an easy and default way in our integrated platform. Auto DevOps is our vision for doing just that for the intersection of development and operations. What I'm going to show is our vision that hasn't shipped yet, so some features may change or some may not ship at all. I'm starting off with a plain vanilla Rails app, literally Rails New. Now we'll just check it in Diversion Control, and now we add the GitLab remote. Now we push it up, GitLab detects the new URL and Auto creates a project for me. And then without any further action, it starts a CICD pipeline, starting with AutoBuild. If you have nothing specified, it'll use Heroku Buildpacks to detect the language and build an appropriate Docker image. If you have a Docker file, it'll use that instead. Then it kicks off AutoCI by running Heroku TestPacks for your language. And then when everything looks good, it auto-deploys to production. If you have nothing configured, it'll use a default Helm chart to deploy to Kubernetes. If you have a Docker compose file, it'll use that instead. Or if you have a Helm chart in the repo, or if you specify a Helm chart in a project variable, it'll use your custom chart. Now let's go and make a code change. Here I'll just make a trivial change to the read me, put it in a new branch, and create a merge request. So now in addition to AutoBuild and AutoCI, it's running auto-code quality to make sure you're not introducing bad code practices in the merge request. And it's creating AutoReview app, so you can see those changes live. Back to the merge request, we see a link to the new review app, right on the merge request. So that's it. AutoDevOps complete with AutoCreate, AutoBuild, AutoCI, AutoDeploy, AutoCodeQuality, and AutoReview app. Thanks for watching.