 Hi, I'm with GitLab and I'm excited to show you one of our great new features in GitLab 11 called AutoDevOps. Actually, AutoDevOps is a collection of 12 features. Auto build, auto test, auto code quality, static application security testing, dependency scanning, license management, container scanning, review apps, dynamic application security testing, auto deploy, auto browser performance testing, and auto monitoring. These 12 features not only work seamlessly together, but work together automatically with almost no configuration. We think that's the best way to bring these best practices to everyone involved in delivering software. The best way to show AutoDevOps is to show it in action. We're looking at an installation of GitLab 11.0 and I've created a new project that will be a simple spring app, but it doesn't have any files just yet. Before we get going, let's take a quick look at some settings that enable the new feature so we can understand AutoDevOps a little better. Single click turns AutoDevOps on. Now, if you're administering your own GitLab instance, you can actually enable AutoDevOps for everyone in your organization in the admin settings. And that would change the instance default, which here is still set to disabled. This is the base domain where you'll find your review apps. You can use this generated one if you don't have your own domain. And we can see here that we're set to do continuous deployments to production. We can change it at any time if we want to acquire manual deployments to production. We also have set over here a variable called production replicas. This allows us to define the number of instances you will have running in production. Right now set to one. You can scale it up as needed. And finally, the other configuration which is very important is the Kubernetes service, which allows us to connect to the underlying Kubernetes platform for deployments. So now back to the project. It's still empty, so GitLab gives me some instructions to get me started. I already have a simple app locally, so I'll copy the instructions and paste them into my terminal. And you can see it checked all of my code into a new Git repo and pushed it up to GitLab. So back in GitLab, I see my code is now there. Note, there's nothing special about this app. No CICD configuration, not even a Docker file. Just a simple spring application saying hello world. Let's go ahead and make a change. We'll remove the to-do comment and personalize the message. Then we'll save it to a new branch. And as part of doing that, we'll create a merge request. Now the exciting stuff. We see that it kicked off a CICD pipeline for us. Remember, I didn't actually configure any CICD for this project at all. This is all auto DevOps kicking in. So here we see a pipeline with many jobs. Here it's running auto build. If you have nothing specified, it will use Heroku build packs to detect your language and build an appropriate Docker image. If the project had a Docker file, it would have used that instead. With the build successful, it kicks off static analysis for auto code quality checks. It'll scan our application environment for vulnerabilities in auto container scanning. It'll also check all of our app's dependencies for vulnerabilities. It's checking all our software for open source licenses that don't match our policies. Doing static application security analysis. And finally, it'll auto test by using Heroku build packs specific to the language so it knows how to test the app. And when all that looks good, it automatically creates a review app by deploying the app to Kubernetes for us. Here we see a bunch of steps. It's doing automatically for us. With the highlight being the deployment to Kubernetes using our default Helm chart. If the app had a Helm chart in the project itself, it would have used that custom chart instead. Or it can even add a project variable to point to another chart, but here we're just using the default. To see the beauty of the review app and auto DevOps, let's go back to the merge request. Here we see a new line showing us it was deployed to a review app. And here's a URL to actually see my change running live. And there's a line for the code quality we see here that it likes that we removed the to do. If we had made things worse, it would have shown up here as well. We can also see the results of our security scans. In this case, there's no new vulnerabilities, but we can still get the full report. And also information about our license management scans, no new licenses to be concerned about. So this looks pretty good. So I'll go ahead and merge as soon as the pipeline is complete. Now we see it's kicked off a new pipeline. And inside this pipeline, it looks familiar, but a little different. This one is deploying right into production. This is continuous deployment at its best. Going to environments, we can see production listed there. And I can easily click through to see what it looks like. Now, there is more to this page. Expanding the environment, I can see the status of the last deployment. In this case, it's just a single pod. So let's go ahead and scale that up. I'll go to the CI-CD settings and adjust that project variable that we saw earlier to set the production replicates to five. Now, let's go back and redeploy. Soon, we'll see the deploy board update. And if we wait a bit, we'll see the deploy finish. Without a deploy to Kubernetes, you have visibility into your deployment. Now, that's pretty cool, but wait, there's more. This little graph icon takes us to the graphs where auto monitoring is showing us the performance of our production application. Again, I didn't configure a thing here. All the metrics were detected automatically. We've got error rate and latency and throughput. Further down, we can see the metrics on our infrastructure, the Kubernetes cluster. So that covers AutodevOps from build, test, code, quality, security scanning, review app, deploy performance testing to production and monitoring. That's pretty awesome. But what if you don't want to deploy straight through to production? We can go to our AutodevOps settings and change the configuration to allow automatic deployment up to staging, but then manual deployments to production. Let's go ahead and kick off another pipeline so we can see the difference. We can see it does all of the tests like before and then deploys to staging, but then production uses incremental rollout strategy. Whether you want continuous deployment to production or continuous delivery flow that's more under your control or even if you want to customize and do something else altogether, we've got you covered. That's AutodevOps in GitLab 11.0. Thanks for watching.