►
From YouTube: Looking for feedback on deck and messaging
Description
In this video William presents a new deck with customer messaging we are testing. Feedback welcome here: https://gitlab.com/gitlab-com/marketing/product-marketing/issues/1371
A
Hello,
my
name
is
William
I
am
part
of
the
product,
marketing
team,
Eket
lab
and
today,
in
this
video
I
would
love
to
test
out
some
new
messaging
that
we're
building
for
our
customer
deck.
This
is
a
slide
deck
that
people
would
use
to
tell
new
folks
about
get
lab
who
are
unfamiliar
with
get
lab
or
that
our
sales
team
would
use
on
calls
or
when
they
go
to
meetings.
A
We
call
this
the
customer
deck
so
we're
playing
around
with
the
slides
trying
to
come
up
with
some
new
messaging
I'm
going
to
pitch
it
to
you
today
and
then
I
would
love
to
get
your
feedback
so
with
that
I'll
share
my
screen,
and
this
is
the
deck
that
we're
working
on
now.
What
I'll
do
is
in
the
description
of
this
video
I'll
post,
a
link
to
the
issue
where
we're
discussing
this
messaging
and
would
love
to
get
your
feedback
on
it
as
well.
A
This
to
you,
as
though
we
were
on
a
video
call
and
I
was
just
talking
through
the
deck,
so
I
get
lab
our
mission
is
everyone
can
contribute,
and
when
we're
talking
to
businesses
and
enterprises,
we
hear
a
lot
about
digital
transformation,
digital
transformation,
disrupting
every
industry,
financial
services.
How
often
do
you
go
into
a
bank
anymore?
These
days,
you
do
it
all
on
your
phone
on
an
app
taxies.
A
You
had
to
assemble
and
kind
of
cobble
together
a
personal
tool
chain
from
a
set
of
disparate
tools,
and
then,
when
you
wanted
to
accomplish
something,
you
had
to
create
a
workflow
from
these
various
tools.
For
example,
if
I
took
a
photo
of
my
family
and
I
wanted
to
share
it,
I
needed
to
take
the
SD
card
out
of
the
camera
I
needed
to
put
it
into
my
computer
I
needed
to
then
send
it
over
via
email,
but
then
smartphones
came
along
and
this
totally
changed
the
way
we
work.
A
Well,
when
we
talk
to
businesses
who
are
driving
digital
transformation,
this
is
kind
of
a
similar
story.
The
engine
that
they
are
using
is
a
set
of
disparate
tools
that
are
cobbled
together
in
order
to
get
them
to
deliver
software.
So
when
they
try
to
id8
and
come
up
with
software
ideas
plan
out
how
they
should
build
them,
send
them
to
an
engineering
team.
A
You
can
take
advantage
of
new,
emergent
workflows
that
didn't
exist
before
and
new
ways
of
working.
So
if
that
sounds
interesting
or
appealing,
I
love
to
just
tell
you
a
little
bit
about
for
the
next
15
minutes.
What
we're
seeing
in
the
industry
and
how
git
lab
is
is
building
response
to
that.
Just
like
to
tell
you
a
little
bit
about
that,
so
when
we
look
at
the
drivers
for
digital
transformation,
when
we're
talking
to
two
businesses,
we
tend
to
see
three
themes
emerging.
First,
they
want
to
increase
operational
efficiencies.
A
So
this
is
something
like
simplifying
that
tool
chain
so
that
they
have
a
load
of
lower
total
cost
of
ownership
across
all
the
things
that
they
manage.
They
want
to
deliver
better
products
faster,
so
they
want
to
accelerate
software
delivery
to
be
able
to
meet
whatever
their
business
objectives
are.
A
So
if
you're
delivering
software
to
customers,
you
the
faster
you
can
get
out
new
features,
the
faster
you
can
drive
revenue
or
if
your
software
is
enabling
critical
internal
business
processes
to
your
employees,
the
the
better
you
can
deliver
that
software
faster,
the
faster
you
can
deliver
that
better
software.
Your
employees
can
then
be
more
productive.
So,
whatever
your
business
outcomes,
we
want
to
deliver
a
better
products
faster,
but
at
the
same
time
we
want
to
reduce
security
and
compliance
risk.
A
So
Mark
Zuckerberg
famously
said,
go
fast
and
break
things
and
the
modern
view
of
product
development,
the
modern
rule
of
product
development,
has
largely
rejected
that
hypothesis,
because
you
can't
just
go
fast
and
break
things.
There's
there's
a
lot
of
people
and
a
lot
of
things
that
rely
on
our
software
and
it
needs
to
be
stable.
So
we
need
to
have
security
checks.
We
need
to
have
compliance
checks.
We
need
to
make
sure
that
is
we're
shipping
you
things
they
don't
they
don't
break
old
things.
A
We
need
to
go
fast
and
not
break
things
and,
at
the
same
time,
with
all
of
those
security
checks
and
all
those
compliance
checks.
We
can't
let
that
hinder
our
speed,
so
we
want
to
both
have
agility
and
resiliency.
We
want
to
go
fast
and
keep
things
up
and
running,
secure
and
compliant
at
the
same
time
and
so
delivering
better
products
faster,
while
also
reducing
security
compliance
risk.
These
are
the
reasons
that
enterprises
and
businesses
are
are
shifting,
from
analog
view
of
the
world,
to
adopting
software
becoming
software
companies
and
going
through
digital
transformation.
A
A
Of
course,
if
you
have
a
lot
of
different
tools
or
manual
processes,
each
of
those
different
tools
can
end
up
being
a
silo,
and
each
of
those
processes
can
end
up
being
a
silo
and
so
DevOps,
which
is
intended
to
break
down
silos,
can
actually
end
up
creating
more
silos,
because
each
of
your
teams
is
running
in
these
separate
tools
and
instead
of
collaborating
with
each
other,
so
they
end
up
waiting
on
each
other.
So
you
have
bottlenecks
and
inefficiencies,
poor
collaboration
between
teams,
because
they
don't
have
the
same
view
of
the
world.
A
There
can
be
periodic
crisis
unsatisfying
trade
offs,
so
you
can
show
up
in
the
news,
because
you
had
a
security
breach
again,
it's
very
important
to
maintain
security
compliance
as
we're
going
quickly
and
a
challenge
is
loss
of
visibility
and
traceability.
How
do
I,
how
do
I
do
auditing?
It's
things
become
more
and
more
complex.
How
do
I
keep
track
of
what
my
system
is
doing?
A
How
do
I,
how
do
I
add
it
in
to
ensure
that
it's
compliant
it
becomes
difficult
as
things
more
become
more
complex
and
as
a
result
of
these
challenges,
it
becomes
very
hard
to
innovate
at
the
speed
that
the
business
demands,
and
so
we
see
these
these
negative
consequences
of
this
state
that
we're
in
which
is.
We
have
poor
quality
products
that
are
over
budget
and
that
unexpected
costs,
so
projects
run
long.
They
take
more
money,
they
take
more
time
than
we
anticipated.
A
That
gives
us
poor
velocity,
which
leads
to
lost
market
opportunities
so
as
we're
trying
to
capture
more
market,
ground
and
and
outpace
competitors.
This
becomes
difficult
if
we
don't
have
a
steady,
fast
pace
of
delivery,
and
so,
if
we're,
if
we're
stuck
and
can't
go
through
digital
transformation,
then
it's
a
lost
market
opportunity.
Additionally,
if
we're
stuck
on
legacy
technologies
and
we're
trying
to
become
a
software
company,
it's
not
enough
just
go
for
digital
transformation.
We
need
to
modernize
as
we
go.
A
It's
digital
transformation
is
a
continual
process
and
what
happens
is
if,
once
upon
a
time,
we
became
a
software
company,
but
we're
on
legacy
technologies.
Often,
developers
and
engineers
will
go
to
the
places
that
they
get
to
work
on
exciting
things,
and
so
companies
that
are
working
on
older
technologies
often
see
developer
turnover.
They
have
very
difficult
time
recruiting
software
engineers
just
one
of
the
greatest
challenges.
So
this
is
a
something
that
we
experienced.
We
have
high
turnover,
poor,
developer
experience
and,
of
course,
whenever
there's
downtime
or
whenever
there's
a
security
breach.
A
This
can
be
business,
service,
disruption,
damaged
reputation
and
lost
customers.
So
these
are
the
negative
things
we
experienced,
but
what
if
we
could
wave
a
magic
wand
and
everything
was
working
the
way
we
wanted
to
work?
What
would
things
look
like
as
we're
trying
to
deliver
software?
Well,
we
probably
would
want
to
a
simplified,
streamlined
and
efficient
tool
tools
and
processes,
something
that
scales
with
the
business
complexity
and
gives
us
security
and
quality
at
speed
without
compromises.
A
We
would
want
teams
to
be
highly
productive
and
be
able
to
collaborate
seamlessly.
We
want
to
break
down
those
silos
and
and
give
cross
team
collaboration.
We
would
want
complete
control
and
visibility
across
the
entire
process,
so
rather
than
things
being
data
and
and
information
being
locked
away
in
different
different
places,
we
would
want
to
have
visibility
into
what's
happening
and
be
able
to
to
monitor
it
and
respond
to
it,
and
we
would
want
to
have
comp
consistent
and
confidence,
a
consistent,
confident,
responsive
business
engine.
This
is
where
I
can
deliver
software
with
confidence.
A
There
is
low
deployment
risk
as
I
ship
new
features.
I
know,
they've
been
security,
tested,
I
know
that
they've
gone
through
all
the
rigor
that
they
need
to
run
and
a
new
piece
of
software
and
production
is
not
going
to
take
the
whole
system
down
so
I'm
going
to
be
up
and
stable,
reliable,
secure
and
compliant
now
to
get
that,
if
or
if
we
had
that,
if
we
had
that
type
of
a
system,
what
would
that
do
for
our
business?
What
what
would
the
business
outcomes
look
like
for
for
your
business?
A
Well,
you'd,
have
projects
delivered
on
time
and
on
budget
you'd
have
increased
team
productivity
and
velocity.
Of
course,
as
you
go
drive
into
new
markets,
you
would
increase
your
market
share
and
revenue
and,
of
course,
increase
customer
satisfaction,
not
just
customer
satisfaction
but
employee
satisfaction
as
well.
These
are
some
positive
business
outcomes
you
could
expect
to
achieve
with
an
ideal
system
and,
of
course,
if
we
wanted
to
get
there,
what
would
we
need?
What
what
would
the
required
capabilities
of
our
tooling
need
to
be
in
order
to
for
us
to
experience
these?
A
Now,
when
we
talk
to
when
we
talk
to
enterprise
businesses,
we
hear
a
lot
of
different
required
capabilities.
We
hear
these
types
of
business
outcomes
they
want
to
achieve.
These
are
just
a
few
examples
of
what
might
be
some
required
capabilities
in
order
to
achieve
these
outcomes,
for
example,
businesses
mainly
tooling,
that
has
a
solution
that
scales
to
match
the
performance
in
the
cost
of
the
organization,
for
example,
in
order
to
support
multi-cloud.
A
We
know
that
today,
80%
of
enterprises
are
running
in
more
than
one
public
cloud,
so
as
enterprises
are
deploying
software
on
premises,
moving
to
the
cloud
using
multiple
clouds,
they
need
the
flexibility
to
be
able
to
deploy
anywhere.
They
want
a
tool,
that's
going
to
be
cloud
agnostic
and
partner
with
all
of
the
cloud
vendors,
so
that
they're
not
locked
into
the
way
that
one
particular
public
cloud
is
viewing
it
and
they
want
the
ability
to
have
flexibility
to
run
the
software
where
they
want
it.
So
they
can.
They
manage
it
themselves.
On-Premises.
A
A
Another
require
where
capability
might
be
one
consistent
view
of
a
collaboration
space
for
development
teams,
operators
and
security
teams.
So
this
would
be
something
like
having
a
consistent
conversation
or
system
consistent
conversation
thread
across
different
stages
of
a
software
development
lifecycle
that
might
be
a
required
capability,
the
ability
for
developers
to
get
immediate
feedback
on
their
code
changes.
So
again,
if
we
want
applications
security,
we
don't
want
to
tack
it
on.
At
the
end,
we
want
to
shift
left
our
security
to
know
as
soon
as
possible
when
there's
a
possible
problem
with
the
security
code.
A
Many
of
our
customers
that
we
talk
to
have
lengthy
security
review
cycles.
Development
chips,
a
feature
they
send
to
this.
This
is
the
security
team
which
takes
some
time
to
review
it
by
the
time
they
ship
it
back
for
the
developer
to
fix
they've
already
moved
on
to
another
project.
They
forgotten
a
state,
it's
very
inefficient,
but
what?
A
If,
while
this
developer,
was
working
on
it,
they
could
see
what
security
vulnerabilities
they
just
introduced
into
the
code
and
go
in
to
fix
those
right
away
before
they
made
it
onto
the
next
step
that
might
be
required
capability
built
in
rather
than
bolted,
on
security
and,
of
course,
centralized
reporting
and
visibility
across
the
software
life.
Often
when
I'm
talking
to
customers
and
users
of
gitlab
I
hear
that
for
their
auditing
and
compliance
is
very
painful.
A
When
you
have
a
disparate
tool
chain,
with
a
lot
of
different
tools
and
you're
trying
to
audit
that
process,
it
can
be
very
difficult.
You
are
pulling
data
out
of
a
lot
of
different
places,
and
then
you
need
to
stitch
it
together
in
order
to
create
a
story
to
understand,
what's
happened
but
required
capability
might
be
having
a
simplified
tool
chain
having
all
of
my
data
in
one
place
so
that
I
have
one
place
to
go,
and
one
audit
log
to
review
what's
happened.
A
So
if
we
had
those
right
required
capabilities,
what
how
would
we
measure
success
if
you
were
to
adopt
a
tool
that
had
those
capabilities?
How
would
you
measure
that
success?
Well,
looking
at
increasing
your
operational
efficiencies,
you
would
want
to
see
your
total
cost
of
ownership.
Go
down
the
amount
that
you
are
paying
to
manage
your
tool
change
to
decrease.
A
Of
course,
your
cycle
time
should
increase
the
time
it
takes
to
from
when
you
start
to,
when
you
finish
a
feature,
for
example,
to
from
when
the
developer
starts
working
on
it
to
when
that's
in
production,
but
that
time
should
be
reduced.
If
you
have
efficient
tooling,
you
should
be
able
to
deploy
more
frequently
we
hear
often
from
research
firms
such
as
Dora
that
DevOps
research
firm.
They
have
metrics
that
they
correlate
to
successful
businesses
and
deployment.
Frequency
is
one
of
them.
A
The
businesses
that
are
the
most
successful
they
have
the
most
market
share
and
the
most
revenue
are
the
ones
that
can
deploy
the
most
frequently
as
they
adopt
DevOps,
and
you
would
see
less
developer
turnover
because
they've
been
working
on
tools
that
they
love
and
they
you
see,
customer
satisfaction,
go
up
or
employee
employee
satisfaction
go
up
as
a
better
products
faster.
You
could
measure
that,
of
course,
in
revenue
in
your
number
of
customers
in
your
market
share.
A
You
can
also
measure
that,
as
the
percentage
of
on-time
on-budget
releases,
you
could
measure
that,
in
terms
of
your
cycle
time
also
the
time
spent
per
stage
waiting
and
the
throughput
of
each
developer.
Our
potential
metrics
and,
of
course,
mean
time
to
resolution
when
something
goes
wrong.
How
long
does
it
take
you
to
be
able
to
fix
that
and
get
things
back
back
to
normal?
That's
the
mean
time
to
resolution
when
you're
talking
about
reducing
security,
compliance
risk,
look
at
percentage
of
code,
scan
percentage
of
critical
vulnerabilities
that
escaped
and
actually
made
their
way
out.
A
What
is
your
audit
pass
rate
and
how
much
time
do
you
spend
on
audits
and
again
looking
at
the
MTTR
for
those
security
vulnerabilities?
These
are
metrics
that
we
would
want
a
baseline
and
then
look
at
to
say
this
is
what
we
want
to
go
and
prove
and
how
we're
gonna
measure
success.
Well,
let
me
tell
you
a
little
bit
about
gitlab
about
how
we
do
it
about
how
we
do
it
a
bit
better
than
everybody
else
or
quite
a
bit
better
than
everyone
else,
and
what
other
folks
are
saying
about
us.
A
So,
as
I
mentioned,
gitlab
is
a
complete
DevOps
platform
delivered
as
a
single
application,
so
for
managing
all
the
way
to
monitoring
and
defending
across
the
software
development
lifecycle
across
the
DevOps
lifecycle.
There's
a
single
application
providing
all
of
these
capabilities.
What
this
does
is
gives
you
a
single
conversation
across
the
cycle.
One
place
to
go.
Look
at
data
one
place,
take
a
look
at
auditing.
It's
secure
because
there's
a
single
permission
model
you're,
not
trying
to
manage
permissions
in
different
places,
there's
a
single
interface
for
governance
security.
A
You
have
teams
that
can
collaborate
together
and
you
can
get
some
some
good
metrics
about
what
is
happening
with
your
software.
So
what
this
looks
like
in
practice
is
we
have
these
DevOps
best
practices
built
in
the
git
lab?
This
is
an
example
flow
of
how
a
feature
might
be
built
in
an
ongoing
product
life
cycle.
It
might
start
with
an
issue.
That's
created
that
defines
a
new
feature
that
needs
to
be
built.
A
A
That's
going
to
run
on
testing
on
that
code,
but
not
just
unit
tests
and
integration
tests,
but
also
application
security
built
in
so
that
at
the
time
of
that
code
change,
the
developer
is
getting
that
security
review,
so
they
can
fix
that
immediately,
Wallis
and
development,
and
not
later
on,
of
course,
right
as
part
of
that
branch
and
what
we
call
a
merge
request.
There's
a
review
application,
so
they
have
a
staging
environment
for
every
single
branch
that
way
their
changes,
don't
conflict
with
other
changes
in
a
way
a
traditional
staging
environment
works.
A
You
can
now
have
peer
review
discussion
with
both
engineers
and
non
engineers
who
can
go
and
introspect
the
code.
You
can
go
and
look
at
how
the
application
behaves
review
it
collaborate
and
then
there's
a
an
approval
process
so
that
you
can
make
sure
that
only
the
right
changes
get
out
when
that
code
is
then
merged
back
into
the
main
branch.
The
infrastructure
is
configured
appropriately
to
run
it
and
the
continuous
delivery
pipeline
runs
now.
A
You
can
do
either
manual
deployment
or
continuous
deployment
into
production,
and
that
code
makes
its
way
in
a
boring,
automated,
safe,
reliable
way
into
production
where
it's
then
monitored.
You
are
capturing
feedback
and
the
feedback
inspires
you
to
go
and
then
improve
the
product
again
and
get
lab.
Does
all
of
this
get
lab?
Has
this
entire
process
in
a
single
application?
In
fact,
our
aim
and
our
vision
is
that
get
lab
would
be
able
to
replace
multiple
vendors
across
the
lifecycle.
A
Today
we
do
an
amazing
job
and
several
of
these
categories,
where
you
can
one
for
one
replacement,
lab
and
get
let's
going
to
do,
an
even
better
job
will
be
best-in-class.
Then
perhaps
what
you
were
using
today
and
in
some
parts
of
get
lab
that
are
a
bit
newer
and
we're
growing
we're
growing
them
very
very
quickly,
and
our
aim
is
that
we
would
be
your
single
application
for
the
complete
DevOps
lifecycle.
Of
course,
get
lab
is
very
uniquely
transparent.
One
attribute
of
our
company
is
that
we
share
almost
everything
publicly.
Our
roadmap
is
public.
A
Our
issue
tracker
is
public
not
only
for
our
open
source
code,
but
also
for
our
paid
code.
We
have
it's
the
open
issue
tracker
and
we
put
out
all
kinds
of
information
that
is
available
to
you
in
a
very
transparent
way.
So
this
is
a
screenshot
from
our
website
that
our
product
maturity,
you
can
see
some
parts
of
it
are
very
mature
and
robust
and
loved
by
our
customers,
and
other
parts
are
new
and
growing,
but
we're
transparent.
So
you
can
follow
along
the
way
in
this
way.
A
Our
aim
is
to
be
the
best
in
class.
In
all
ten
of
those
categories
you
might
say.
Well
how
can
you
do
that?
Well,
one
is
the
powered
convention
with
over
a
hundred
thousand
organizations
across
the
world
using
gitlab
we're
implementing
those
best
practices
back
into
the
product
so
that
everybody
takes
advantage
of
them.
The
idea
that
everyone
can
contribute.
We
have
a
passionate,
vocal,
global
community
of
over
2,200
people
that
are
contributing
to
get
lab.
A
These
are
just
contributing
the
code
there's
a
much
much
broader
community,
that's
even
contributing
issues
and
ideas
in
conversation,
so
we
are
very
passionate
about
the
the
idea
of
customer
co-creation
we're
not
just
building
a
product.
We
build
it
together
with
our
customers.
In
fact,
there
are
large
enterprises
that
hire
engineers
to
work
for
them
that
their
job
is
to
build
features,
forget
lab
that
they
need,
and
then
they
contribute
those
features
back
upstream
and
all
the
other
enterprises
get
to
take
advantage
of
it.
A
A
We
recently
raised
a
268
million
series
e
round
and
are
growing
our
company
and
engineering
force
at
a
very,
very
quick
pace.
So
all
of
this
translates
into
faster
delivery
of
features
and
capabilities.
As
we
as
we
move
forward
now,
some
folks
might
say:
does
that
mean
I
need
to
rip
everything
out
and
then
plug
it
lab
in,
and
the
answer
is
no
actually
most
of
our
customers
are
docket
lab
gradually.
A
So
what
they'll
do
is
in
one
place,
they
might
start
with
source
code
management,
which
gives
them
version,
control
and
and
code
review,
and
then
they
would
branch
this
to
CI
and
add
in
continuous
integration.
Then
they'll
do
CD
and
what
we've
seen
is
over
time
as
folks
adopt
more
of
gitlab.
The
return
on
their
investment
becomes
greater
and
greater,
in
fact,
there's
a
correlation
between
the
amount
of
capabilities
they're
using
in
a
single
application
and
their
DevOps
maturity
and
the
return
on
investment
they
get
so
that
that
grows
over
time.
A
As
you
dock,
you
lab,
of
course,
don't
take
my
word
for
it.
We
have
customers
across
every
industry
vertical
because
we've
seen
digital
transformation
is
happening
in
every
industry.
Devops
and
agile
software
development
practices
are
going
across
every
industry
and
get
lab
applies
in
every
issue.
Industry,
including
yours,
where
we
have
customers.
In
fact,
just
a
few
of
our
stories
are,
for
example,
Ticketmaster
ticket
master
had
pipelines
that
were
taking
a
long
time
to
run
over
two
hours
to
do
a
build.
A
They
had
problems
like
engineers
were
staying
late
on
Friday
night,
instead
of
getting
home
to
their
friends
and
family
they're
having
to
stay
late,
just
to
watch
the
pipeline
complete
because
it
was
taking
so
long
to
make
sure
it
was
successful
when
they
implemented
get
lab
that
shrunk
from
2
hours
down
to
just
10
minutes.
So
things
can
run
very
very
quickly
and
the
reason
they
were
able
to
do
this
is
because
get
labs
pipelines
and
our
get
lab
runner
part
of
our
that
runs.
A
Our
CI
CD
is
a
modern
architecture
that
allows
it
to
scale
very
quickly
and
run
things
in
parallel,
so
they
were
able
to
run
their
pipelines
15
times
faster.
Another
business
using
git
lab
is
worldline,
whose
global
financial
services
based
in
France
over
11,000
employees
globally,
and
they
were
on
some
very,
very
legacy
technologies
or
what
is
legacy
today,
which
is
things
like
subversion
version
control,
Jenkins
and
these
legacy
technologies
we're
making
it
very
very
hard
for
them
to
do
code
review
in
code
collaboration.
A
They
wanted
their
engineers
to
be
able
to
review
code
so
that
code
that
makes
its
way
onto
production
is
of
higher
quality
and
they
wanted
to
be
able
to
collaborate
to
get
the
best
ideas
out
to
production.
The
problem
was,
if
you
and
I
were
working
on
code
together
at
worldline
and
I
wanted
to
go
review
your
code
in
order
for
me
to
get
everything
that
I
needed
to
get
a
branch
and
everything
set
up
so
that
I
could
just
go
in
review.
Your
code
actually
was
a
process
that
took
two
weeks.
A
This
was
extremely
painful,
as
you
can
imagine.
Very
little
code
was
actually
reviewed
well
when
they
implemented
gitlab
and
they
move
from
subversion
to
get
using
git
lab.
They
actually
were
able
dramatically
speed
this
up
so
much
so
that
if
you
and
I
were
collaborating
on
code
and
I
wanted
to
look
at
your
changes,
I
could
get
them
in
a
few
seconds.
So
I
could
instantaneously
see
what
your
changes
are.
A
I
could
instantaneously
go
into
get
lab
and
start
reviewing
on
on
each
part
and,
as
you
can
imagine,
the
amount
of
code
review
that
they
did
shot
up
by
a
hundred
and
twenty
X
one
other
customers.
I'll
mention
is
Goldman
Sachs.
The
investment
firm
and
they've
adopted
collab
across
several
parts.
They've
replaced
several
tools
with
yet
lab,
including
their
source
code
management
and
their
CI
and
their
CD,
and
by
reducing
that
tool
chain,
they've
been
able
to
accelerate
their
DevOps
adoption.
This
increased
thing
increased
their
deployment
frequency
from
once
every
two
weeks
to
once.
A
Every
few
minutes,
they're
now
doing
over
2,000
builds
per
day
using
git
lab.
So
this
level
of
automation
and
DevOps
maturity
has
come
by
using
a
modern
tool
designed
for
DevOps,
but
it's
not
just
our
customers.
Talking
about
us.
The
industry,
analysts
are
also
impressed
with
git
lab.
The
IDC
is
call
us
an
innovator,
get
labs
call
us
at
visionary.
Foresters
is
released
us
as
a
leader
in
their
reports
and
across
multiple
parts
of
our
tool,
from
our
CI
to
our
enterprise,
agile
planning.
In
fact,
it's
not
just
folks
like
Forrester
and
Gartner.
A
Talking
about
us,
but
even
our
customer
reviews,
as
you
look
at
sites
like
Gartner
pure
insights,
we
were
the
customer
Choice
winner
for
best
central
planning
tools
and
the
best
application
release
orchestration
software
as
voted
by
our
users
on
the
pure
insights.
So,
as
you
can
see,
gitlab
is
a
complete
devops
platform.
Deliver
it
as
a
single
application.
It's
the
leading
source
code
management
and
CI
in
one
place,
so
you
don't
need
those
in
separate
Jools.
It
has
built-in
security
compliance
with
end-to-end
insight
and
visibility.
A
You
can
deploy
your
software
anywhere,
you
want
and
you
can
deploy
gitlab
anywhere.
You
want
with
flexible
hosting
options.
This
gives
you
rapid
innovation,
the
ability
for
everybody
contribute
and
a
collaborative
process,
a
business
partner
who
is
going
to
work
with
you
not
just
today,
but
in
the
future.
So
that's
to
say
is
one
of
the
next
steps.
A
What's
going
on
with
them,
or
this
might
be
that
the
first
15
or
20
minutes
of
a
customer
meeting
that
goes
for
an
hour
or
two
hours
where
we
talk
a
little
bit
about
what
gitlab
is,
but
then
we
we
dig
in
after
this,
then
we
go
and
talk
about
what
are
they
experiencing?
What
are
your
specific
challenges?
What
are
the?
A
What
are
the
negative
things
that
are
happening
in
your
business
and
the
consequences
of
those,
and
if
you
could
make
the
wave
the
magic
wand?
What
would
what
would
things
look
like,
and
maybe
we
can
figure
out
how
good
laughs
can
help
you?
So
with
all
that,
thank
you
for
watching
the
video
I
would
love
your
feedback
as
we
are
working
through
this
messaging
iterating
it,
as
I
mentioned,
I'll,
link
the
issue
to
go
and
check
it
out
in
the
description
this
video
and
have
a
very
wonderful
day.