 Hi, I'm Mark Punsock, Azure Product at GitLab. Today I'm going to talk about GitLab's product vision for 2018. Specifically, I'm going to show a prototype of what the product might look like. As you can imagine, with a product vision as extensive as ours, there's a lot to cover. So if you only remember three things from this presentation, know that, one, we're going after the complete DevOps lifecycle. And specifically, two, we want operations and security to use GitLab as a primary interface. And three, with a single application covering this entire scope brings emergent benefits, specifically that people can work concurrently on the same data with the same interface. So hopefully it's obvious by now that we're going from covering the development lifecycle to covering the DevOps lifecycle. But traditional DevOps tools only focus on the intersection between Dev and Ops, and GitLab is going to deliver a complete scope for both Dev and Ops. In particular, that means we're not just looking at how developers can get their code into production, but how operations can then monitor and manage those applications and underlying infrastructure. A big milestone for GitLab will be when operations people log into GitLab every day and consider it their main interface for getting work done. But even that's not really sufficient as we're redefining what the scope of DevOps even is. We're also covering security. Rather than coming up with some crazy DevSec QA Ops theme, we're just calling it DevOps and putting it all into a single application. And with that, each group gets an experience tailored to their needs, but shares the same data and interface as everyone else, so collaboration is easy. Imagine Ops person finds an issue in production, thrills down to find the application with the problem, and sees that a recent deploy caused the problem. Simultaneously, a Dev gets alerted that their recent deploy triggered a change in production, goes to the merge request, and sees the performance change right there. When Dev, Ops, and Security talk, they're looking at the same data, but from their own point of view. Now, the scope we're going after is quite large, with a lot of new categories being introduced this year. I won't go into all of these today, but instead I want to focus on a couple of flows that paint a picture of how this could look. I'll start by showing a merge request. One of the new elements we see is a test summary, which shows a deeper understanding of your test results. 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 binary artifacts and container images associated with this merge request. 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 we've had for a while. Then the relatively new security section with static application security testing to find vulnerabilities in your code, dynamic application security testing to find vulnerabilities while actually running your app, and an analysis of any vulnerabilities in any of your underlying Docker layers. We'll also show how your application performance has changed. And lastly, we'll check your dependencies for any violation of your company's license policy. Now, this is a lot to cover for every merge request, so we have separate issues to redesign for all this new information, but I wanted to show it all to you now to see how much we're doing automatically for you. Down below, all of that is an enhanced code diff that highlights any code you should pay attention to because of code quality concerns or missing test coverage. This is all part of the shift-left movement, where important quality, security, and performance tests that may have once been run manually, if at all, and usually much later in the development lifecycle, are now being run automatically as soon as the first code is written. There's a lot more planned, but that's a good idea of the direction we're going in to help developers get their ideas into production faster. That only covers part of our vision, because there's also the operations point of view. And a big milestone for our DevOps vision is when operations start using GitLab as their primary interface. There's a long way to go, but here we're 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 put a graph of the appdex score there to represent the one metric to watch. Below the project 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? Well, 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 operations experience then really should just be, I go to work in the morning, and I 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. After we've got this breadth as a structure, we look forward to the customer feature requests. So that covers dev and ops, but we've got a lot of security features in the product now. How about treating security folks as first-class citizens and giving them their own security audit view? This is your one-stop shop to see what security vulnerabilities have been detected across the group, showing any automatic or manual actions taken to address the vulnerabilities. And of course, letting you click into details. In the top left, we are reporting an overall success rate in hitting our own internal SLAs for security vulnerabilities. Now let's drill down on one of these vulnerabilities. We see that the GitLab bot automatically created a merge request to upgrade one of our dependencies because it noticed that a new version was released. Since the tests all pass, the merge request was automatically merged by the bot as well. But to bring it full circle, I'm showing here that after merging, the CI CD pipeline started deploying automatically to production. I mean, why leave a known fixable security vulnerability live any longer than it needs to, right? But in this case, even though all tests passed, we still saw the error rate jump up by more than 5%, so we automatically stopped the rollout process and actually rolled back to the last known good version immediately. Then the bot detects this and automatically reverts the merge request so we can leave master in a good state. Phew. So wrapping it up, we're going after the complete DevOps life cycle. We want operations and security to be our new favorite users, and we want teams working concurrently. And that's the GitLab product vision for 2018.