We recently went live to discuss the
news of our Series D funding
and what the future holds for GitLab. You can watch GitLab's Head of Product,
Mark Pundsack, present our vision with some previews of what's in the works
below:
Watch the recording
View the slides
Summary of our product vision
Our strategy is to double down on what's working: while we already cover the
entire DevOps lifecycle, we want to increase depth in some of our existing
features, transitioning from minimum viable change to minimum loveable feature.
I thought @Jobvo had me at "Minimal Viable Change". But then @MarkPundsack comes out with "Minimal Lovable Product" and I'm awestruck #GitLabLive
— Brendan O'Leary 👨🏻💻 (@olearycrew) September 20, 2018
We're also going to continue to increase our breadth, building out new
capabilities across the entire DevOps lifecycle.
And finally, because we believe everyone can contribute, we're going to add more
roles to the scope of product, including executives, designers, product
managers, and essentially anyone who is involved in software development and
delivery. Our goal is to get everyone working concurrently in a single product,
with nine best-in-class categories.
Coming up...
We're working on building out 26 new capabilities, but because you don't have
all day, below are three examples to give you a taste of what's in the works.
Obligatory disclaimer: These are mock-ups and the features may turn out
looking a little different, or may not ship at all
Executive flow: Value Stream Management
At its heart, Value Stream Management
is about understanding your teams' work and their workflow on the way to
delivering value to customers. The way we're approaching it is to extend
something development teams are already using to track their work, namely issue
boards, and bring it into the bigger picture by having a board that covers the
entire workflow necessary to get ideas into production.
Because GitLab already covers that entire scope, we can automate it too. We know
when a feature is scheduled. We know when you push your first commit. We know
when code review starts. We know when you deploy your code to production. So we
can move the cards to the right spots automatically, so not only can you track
your progress and communicate it to your team, you can track it all
automatically and more accurately. Neat, huh?
The above mock-up demonstrates a situation where someone was able to dive into
the time spent on various areas, and see that the time spent waiting for someone
to even start QA was really high, and they managed to shave off a few days just
by rearranging some internal processes. The same goes for the code review cycle.
Ops flow: Incident management
This is an operations flow based on a new product capability:
incident management. We
monitor your production apps and detect an anomaly, alert you, and then open an
incident. Then in one place you can see: what triggered the alert, who's
involved in responding, quick links to the Slack conversation, Zoom call, and
where to update your public status page. There's also a timeline of all
activity. Because this is part of the same application that developers are
using, it’s not just operations people using this tool, so when you’re working
together on problems, you’re looking at the same data, and GitLab knows not only
what metrics are alerting, but what code was recently deployed that might have
caused it, and who was behind that code. When the incident is resolved, you can
easily follow up with your users with a postmortem, pulling in all the relevant
data and timeline of events. Of course, with all that data comes great power for
analytics, to help the team learn from the incidents and improve.
Mock-up showing an Incident open with timeline view, including Slack messages and Status page updates
Security flow: Auto remediate
A common security task is watching for new vulnerabilities in your project’s
dependencies. If a module you depend on has a vulnerability, there’s usually a
patch update to go along with it. When that patch is released, you then need to
test your software again with that patch, to make sure everything still works
before you deploy it. That’s a pain!
Instead of making anyone do all that repetitive, but necessary security work,
we want to automate it all away.
In our vision, a bot detects that a dependency has a new version, and instead of
alerting someone, automatically creates a merge request that bumps the version
number for you, and runs the test suite to make sure that everything still
works. The CI pipeline passes, and confirms that the security vulnerability is
now gone, so the bot automatically merges the changes. If all goes well, your
security and development teams just get an email in the morning saying that all
the projects with that dependency were automatically fixed.
By why leave a known, security vulnerability live any longer than it needs to?
To bring it full circle, after merging, the CI/CD pipeline starts incrementally
deploying to production. If the production error rate jumps, we automatically
stop the incremental rollout, and go ahead and roll back to the last-known good
version immediately. The bot detects this and automatically reverts the merge
request so we can leave master in a good state. This, we can finally alert the
teams about, so instead of having to test 20 projects manually, they can focus
on the few that can’t be automated.
Mock-up showing a merge request reverted automatically following detection of production errors
As always, our plans are in draft and we welcome your feedback and input!
