 Hi, I'm Mark Punsock as a 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, the 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, drills 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 flows that paint a picture of how this could look. For this, I'll switch over to an interactive prototype. While this may look like a fully functioning instance of GitLab, it is just a demo, and many of these features have not been implemented yet. 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 artifacts and the 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 our 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 violations of your company's license policy. Now, that's 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 now to see how much we're doing automatically for you. Now, down below is an enhanced code diff, and it'll highlight any code you should pay attention to because of code quality concerns, or because there's no code coverage. Now, 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 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. But 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 primer 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've 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 of 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 go to work in the morning and see an email summary of what happened without 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 plenty 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're reporting on overall success rate in hitting our own internal SLAs for security vulnerabilities. Now, let's drill down on one of those 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, and of course, the security vulnerability has been fixed, 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 CICD pipeline started automatically deploying 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 pass, we still saw the error rate jump by more than 5%. So we automatically stopped the rollout process and automatically 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.