 Hi, I'm Mark Punzak, Head of Product at GitLab, and today I'm going to talk about GitLab's product vision for 2018. Specifically, I'm going to show a few mock-ups 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 to go after the complete DevOps lifecycle, and specifically, two, we want operations 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 DevOps. And GitLab is going to deliver a complete scope for both DevOps and DevOps. 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 their main interface for getting work done. But even that's not really sufficient, as we're redefining what the scope of DevOps really is. We're also covering QA and security in a single application. And rather than coming up with some crazy DevSec QAOps name, 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 an 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 and ops talk, they're looking at the same data from their own point of view. Now, the scope we're going after is quite large, with a lot of new areas being introduced this year. I won't go into all of these today, but instead I want to focus on a couple flows, the paint a picture of how this could look. I'll start by showing a merge request. 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 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 to find vulnerabilities in your code, dynamic application security to find vulnerabilities while actually running your app, and an analysis of any vulnerabilities in any of 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 performance has changed. Now, 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 now to see how much we're doing automatically for you. Down below all of that is an enhanced code diff view 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, and 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 this only covers part of our vision because the other side is from the operations point of view. And a big milestone for a complete DevOps vision is when operators 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're seeing an overview answering the question, how is production doing? In this case, we're seeing a group with four projects in it, with a quick green-yellow-red indicator of how those projects are doing. We've tentatively put a graph of the appdex 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 new 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 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 customer feature requests. So wrapping it up, we're going after the complete DevOps lifecycle, we want operations to be our new favorite users, and we want teams working concurrently. And that's the GitLab product vision for 2018.