 In 2018, we're taking GitLab from being a development tool to a DevOps tool, a single application for the complete DevOps lifecycle. Customers have seen the value of integrating GitLab CI into the core GitLab, and we want to extend that. I'll start by showing a merge quest. At the top, we see a test summary, which shows a deeper understanding of your test results than the job level. Using standard JUnit XML output, we can tell exactly which tests fail and provide that information in a nice summary format. We also see links to the artifacts and container images associated with this merge quest. As I scroll down, we see a lot of information about the extensive collection of tests we've run on the code. First we see the code quality section, which has been around for a while. And the relatively new security section, with static application security analysis to find vulnerabilities in your code, dynamic application security analysis to find vulnerabilities while actually running your app, and an analysis of any vulnerabilities in your underlying Docker layers. We'll also be checking your dependencies for any violations of your company's license policy. And lastly, we show how your application's performance has changed. This is a lot to cover for every merge request, so we have separate issues to redesign for all of this new information, but I wanted to show it all to you now to see how much we're doing automatically for you. And this is all part of the shift left movement, where important quality security and performance tests may have once been run manually, if at all, and usually much later in the development cycle, are now being run automatically as soon as the first code is written. There's a lot more planned, but this is a good idea of the direction we're going in to help developers get their ideas into production faster. Actually one last thing is down here, I'm also showing an enhanced code coverage view where we can show the code coverage. If you're looking at a new test, you can see that this test hasn't been covered. And if there is other kind of code quality announcements or warnings, we can put them directly in line with your code as well. But all this only covers a part of our vision, because the other side is from the operations point of view. And a big milestone for our complete DevOps vision is when operations start using GitLab as their primary interface. There's a long way to go here, but let's start by looking at an operations dashboard. Here we see an overview answering the question, how is production doing? In this case, we're seeing a group with four projects in it and a quick green-yellow-red indicator of how those projects are doing. We've tentatively put a graph of the aptX score there to represent the one metric to watch. Below the projects is a view of the cluster, including CPU and memory usage, possibly indicating when you need to scale up or down the cluster size. Now if there was an indication that something was wrong, you'd be able to drill down and see more details and rectify the situation. But that's only the first level understanding of operations. I mean, if we've got the data about how things are doing, why not proactively alert you to the problem? So that's the second level, and a natural step. But we're not going to stop there. The third level is to automatically detect and resolve any issues. If your app needs more resources, just autoscale it. If you then hit a limit on the cluster, well, add a node to the cluster automatically. The operation's experience then should really just be, I go to work in the morning and see an email summary of what has happened without me having to do anything. But autoscaling is just scratching the surface. As operations involves a lot more, from application, infrastructure and network monitoring to security patches and beyond. After we introduce this, we look forward to the feature requests.