At GitLab, we believe there's something magical about a video demo as a way to convey strategic vision. We've created this video to internally align where we're going; and since we're transparent by default, you get to see it as well!
So sit back, watch the video, follow along with the presentation, or read below for a lightly edited transcript of the video. You can also play with the prototype yourself (click the header to move to the next page, click the left sidebar to move back) or follow our progress.
Introduction
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:
- We’re going after the complete DevOps lifecycle, and specifically,
- we want Operations and Security to use GitLab as a primary interface, and
- 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 entire DevOps lifecycle.
{: .shadow}
From Dev to DevOps
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 and Business needs (such as project managers). Rather than coming up with some crazy DevSecBizOps name, we’re just calling it DevOps, and putting it all into a single application.
{: .shadow}
No DevSecBizOps; a single application for DevOps
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, 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.
{: .shadow}
New product categories in 2018
Interactive prototype
For this, I’ll switch over to an interactive prototype. [Note: if you want to try it for yourself, click the header to move to the next page, click the left sidebar to move back.] 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.
Development flow
I’ll start by showing a merge request.
{: .shadow}
Developer Flow: 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 or your code's dependencies, 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, 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.
{: .shadow}
Code coverage and alerts
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 this is a good idea of the direction we’re going in to help Developers get their ideas into production faster.
Operations flow
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 primary interface.
{: .shadow}
Operations flow: operations health dashboard
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 Apdex 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? 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 should really just be that 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 the customer feature requests.
Security flow
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?
{: .shadow}
Security flow: security audit
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 an overall success rate in hitting our own internal SLAs for security vulnerabilities.
Full circle
Let’s drill down on one of these vulnerabilities.
{: .shadow}
Automatic updates for security 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 merge request fixed the vulnerability, the merge request was automatically merged by the Bot as well.
But, to bring it full circle, l’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 to more than five percent, 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.
Summary
So, wrapping it up:
- We’re going after the complete DevOps lifecycle,
- 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!
