►
From YouTube: TT101: Introduction to GitLab
Description
This is a Tanuki Tech session on 11/3/2021.
For more on Tanuki Tech, see here: https://about.gitlab.com/handbook/marketing/revenue-marketing/sdr/tanuki-tech/
For more on the speaker, see here: https://www.linkedin.com/in/christopher-wang-0835b226/
A
All
right
good,
so
today,
what
we're
going
to
be
talking
about
is
stories
are
important
right,
so
everyone's
joined
a
company
in
which
it
was
on
a
really
great
successful,
trek
very
exciting,
really
great
holiday
parties
and
maybe
you've
also
joined
a
company
in
your
career
in
which
it
was
in
the
decline
right.
So
there's
a
atmosphere
of
fear.
So
we'll
talk
a
little
bit
about
the
story
that
you
just
joined
gitlab.
What
are
we
trying
to
do?
A
A
Yep,
all
right
sounds
awesome.
So
does
anyone
know
who
this
gentleman
is
in
the
top
right,
and
this
is
zion.
C
He's
thought
to
be
the
next
lebron
james,
we'll
see
he's
a
pretty
incredible
athlete
so
far.
What
a
young
nba
player,
yeah.
D
C
D
B
A
So
basically,
one
of
my
analogies
is
that
gitlab
is
like
zion
williamson.
In
another
words,
we
are
trading
at
a
hugely
a
really
high
multiple.
We
have
a
lot
of
potential
there's
a
lot
of
investor
expectations
on
the
company,
and
one
of
the
big
thing
that
we're
trying
to
do
now
is
that
we're
trying
to
meet
those
expectations.
Just
like
zion,
was
number
one
in
the
nba
draft
right.
A
We're
kind
of
interesting
in
the
sense
that
we
only
sell
one
product
which
is
get
lab.
The
last
companies
that
you
work
for
like
how
many
products
they
sell.
Oh.
D
B
A
We
only
sell
one
product
here
kind
of
interesting,
so
we
have
a
lot
of
potential
we're
winning
a
lot
of
awards,
but
we
still
got
a
lot
of
work
to
do
right
now.
Our
reputation
is
a
little
bit
higher
than
what
we've
actually
achieved,
and
what
we're
trying
to
do
in
the
next
three
years
is
to
become
that
next
great
player
in
the
technology
space
right
so
on
a
financial
level
we're
trying
to
get
to
one
billion
dollars
in
annual
reoccurring
revenue
all
right.
So
this
is
just
an
example.
A
B
A
Onboarding,
because
a
lot
of
the
assets
that
we
make
you
read
is
from
marketing
we
kind
of
spin
a
narrative
that
get
lab.
Success
is
inevitable
right,
but
we
have
some
very
real
competitors.
So
let's
actually
take
a
look
at
where
we
are
with
respect
to
some
of
these
other
companies
in
the
market
and
one
way
that
you
can
do
that
is
you
can
look
at
job
postings
right.
So
what
I
did
over
here
is.
I
went
on
a
job
posting
site
in
the
united
states.
A
Jenkins,
forty
thousand
so
four
x,
we're
at
and
then
github
two
point
like
23
000..
So
what
does
this
tell
you
about
our
market
position.
B
A
That's
true
like,
but
where
everyone's
trying
to
grow
your
competitors.
A
A
All
right,
so
what
does
gitlab
do?
This
is
really
important
to
understand
that
we
try
to
basically
do
everything
for
software
development
and
delivery,
and
I
want
to
talk
a
little
bit
as
someone
who
was
an
engineer
for
half
a
decade
about
how
this
usually
works.
A
A
You
might
have
many
different
tools
for
security
scanning,
so,
let's
just
say
like
sonar
cube,
and
then
you
have
to
save
your
software
somewhere,
so
you
might
get
another
tool
for
that.
Something
called
like
nexus
right
and
then
so,
if
you
want
to
create
an
automation,
if
you
want
to
automate
your
workflow
for
something
like
this,
you
can
almost
think
about
like
a
big
conveyor
belt
like
have
you
ever
been
in
a
brewery
with
like
a
really
big
conveyor
belt,
like
horrors
brewery.
A
Yeah
anyone
ever
see
something
like
being
in
a
factory
like
this
yep
all
right,
so
that's,
basically
what
most
people
are
trying
to
do
with
their
software.
The
thing
is
that,
because
you
have
one
vendor
that
builds
this
part,
another
vendor
that
builds
this
part,
a
third
vendor
that
builds
this
part.
You
have
to
basically
put
everything
together
on
your
own,
so
this
is
our
big
conveyor
belt
for
software
development
and
delivery.
A
We
have
to
basically
get
all
the
tools
to
work
together,
and
the
challenge
with
this
is
that
it's
five
tools
to
maintain
five
tools
to
install
upgrade
five
tools
to
train
all
of
our
employees
on
and
five
tools
to
stitch
together.
So
the
more
tools
that
you
have,
let's
just
say
that
we
have
to
update
jira
right.
So
we
have
to
turn
this
com,
these
computers
off
and
turn
them
back
on.
C
A
D
A
Exactly
yeah
so
real
example
is
maybe
10
to
15
tools
that
are
involved
10
to
15
tools,
to
train
your
employees
on
10,
to
15
sales
teams,
to
talk
to
right,
they're
all
trying
to
upsell
you
that's
kind
of
annoying
too
five
to
10
10,
to
15
tools
to
install
upgrade,
monitor,
integrate
together
and.
A
What
would
be
much
better
is
if
one
vendor
built
out
this
entire
thing
for
you,
it
was
always
designed
to
work
together
and
you
have
like
a
maintenance
contract
by
one
vendor,
as
opposed
to
like
15
different
vendors
right.
So
we
want
to
be
the
universal
system
for
software
development
delivery,
and
so
what
do
we
try
to
do?
Basically
everything.
A
Basically,
right
now,
engineers
are
actually
rewarded
for
going
out
and
finding
some
cool
new
thing
to
put
in
here
and
literally
that's
part
of.
Sometimes,
you
can
just
show
leadership
by
finding
new
technologies
to
implement
into
your
software
delivery
life
cycle.
So
what
we
are
proposing
from
going
from
10
to
15
tools
into
one
is
very,
very,
very
counter.
Cultural.
Most
people
don't
understand
the
value
of
doing
this.
It's
just
something
that
we
have
to
explain
to
the
people
that
we
talk
to.
A
You
could
literally
have
a
two
billion
dollar
company
that
focuses
on
this
one
thing,
and
we
are
trying
to
do
basically
everything
here,
but
this
is
a
chart
that
shows
how
good
we
are
at
each
of
these
product
categories.
The
heart
means
that
we're
great
at
it.
We
think
that
we're
one
of
the
best
three
solutions
in
the
entire
world
at
this
place.
A
The
half
circle
means
that
we're
okay
at
it,
we're
still
working
on
it,
there's
better
stuff
than
where
we're
at
and
the
quarter
circle
basically
means
that,
like
you,
probably
really,
if
you
don't
have
anything,
you
might
want
to
use
our
stuff,
but
it's
not
a
real
solution
yet
right.
So
what
is
the
most
common
shape
that
you
see
in
this
chart?.
D
A
We're
super
broad,
and
that
means
that
some
places
of
our
product
were
very
thin
right.
You
literally
have
a
company
that
they
have
a
hundred
engineers
they're
spending
a
whole
hundred
engineers
on
these
two
things
right-
and
this
is
maybe
just
like
two
percent
of
where
we're
spending
our
engineering
and
that's
very
important
for
us
to
understand.
A
So
one
of
the
things
I
want
to
talk
about
is
that,
as
we
complete
our
product
vision,
then
our
ability
to
go
into
any
customer
meeting
and
say
we
genuinely
replace
this
entire
conveyor
belt.
The
value
prop
is
just
going
to
increase
increase
as
we
build
out
the
product
right
and
some
places
right
now,
we're
mature,
but
in
some
places
like
this
one
we're
just
getting
started
right.
This
is
not
like
mature
in
any
capacity
whatsoever.
A
Over
here
is
an
example
of
a
very
ambitious
roadmap,
so
some
companies
are
really
great
at
sales.
Some
companies
are
really
great
at
engineering.
Gitlab
is
very,
very
good
at
engineering
and
product,
and
you
can
see
that
this
is
the
roadmap
that
we
want
to
achieve
in
the
next
year.
Right
now
we
have
three
hearts.
A
We
have
seven
full
circles
and
literally
34
of
these
half
circles
and
26
of
these
quarter
circles
right
so,
like
only
80
percent,
only
20
percent
of
our
product
really
is
complete
in
any
capacity,
but
let's
scroll
one
year
out
into
the
future.
Now
one
year
after
the
future,
we
want
to
be
50
full
circle,
our
heart,
and
at
that
point
in
time,
it's
going
to
be
a
lot
easier
for
us
to
sell
gitlab
because
of
how
we've
completed
this
product
vision.
A
A
So
2011
we
add
in
two
things
then
3
3,
3,
4,
6,
9,
12,
15,
20
right,
so
we're
basically
ballooning,
and
this
is
because
of
just
the
fact
that
we
have
a
great
engineering
culture
and
the
fact
that,
where
our
roadmap
is
going
to
be
affected
by
our
ipo
right,
so
using
the
money
from
the
ipo
we're
going
to
use
it
to
improve
our
product.
B
C
Quick
question
yeah:
how
do
we
define
what
we
think
is
like
a
complete
version
of
our
product
or
like
a
like
a
work
in
progress,
or
you
know
minimal?
What
what's
our
criteria
for
that?
Is
it
just
kind
of
how
we
feel
about
it
compared
to
other
options?
Is
there
like
an
actual
like
data
that
we
use.
A
Yeah,
I'm
not
going
to
make
up
an
answer
for
you
for
this.
I
think
my
understanding
of
this
is
that
this
comes
from
our
product
team,
and
what
I
would
say
about
this
is
that
I
think
it's
a
very
brave
thing
to
tell
your
customers
that
we're
not
good
at
this
yet
right,
that's
not
what
most
people
would
say,
so
I
do
think
that
we
are
being
transparent
about
it.
D
It
fits
the
the
overall
idea.
I
think
the
product
too,
though
kind
of
the
open
source
ever
evolving,
where
you
just
up
front
tell
these
people
like
hey.
What
you
have
now
is
great.
Some
things
are
gonna
work
on,
but
in
the
future
you're
already
gonna
have
get
lab
and
when
these
things
are
up
to
speed
and
fully
operational
you're
all
set
like
you
have
it
like
it's
like
that's.
A
Exactly
it
so
we're
we're
very
excited
about
this
next
year,
as
our
product
gets
completed,
it's
basically
going
to
be
a
lot
easier
for
us
to
sell
a
product
and
it's
pretty
easy
to
sell
our
product
right
now
too.
To
be
quite
honest,
I
know
a
lot
of
sales
people
that
say
that
gitlab's
the
easiest
thing
that
they've
ever
sold
so
that's
important
to
understand.
A
Okay,
so
it's
all
in
one.
We
talked
a
little
bit
about
this
already
when
I
was
an
engineer,
we
used
github
docker
hub
jenkins.
We
also
used
ansible
and
some
terraform,
and
then
we
basically
want
to
replace
all
of
that
stuff
and
to
be
this
conveyor
belt
right.
So
git
lab
would
replace
all
of
this
and
be
your
ones
system.
A
A
It's
not
something.
That's
super
visible
for
people,
because,
in
all
honesty,
like.
A
D
Yeah,
I
think
I
was
thinking
when
I
would
speak
to
like
you
know
I
had
to
say,
like
upper-level
directors
or
like
ceos,
that
don't
really
use
the
tools
for
cyber
security.
They
just
want
to
know
that
if
they
get
a
report
or
they
look
at
something,
it's
all
under
one
app
so
to
them.
It's
like
I'm
dumb,
but
I
need
to
know
what
works
where,
like
you
said,
engineers
actually
kind
of
care
and
find
it
interesting.
So.
B
B
A
Cool
awesome:
how
often
do
you
guys
go
out?
You
know
your
friends
or
somewhere
without
your
phone.
B
D
A
We
basically
want
to
be
that
universal
tool
for
software
development
and
delivery,
and,
as
we
basically
complete
our
product
roadmap,
we
can
more
authentically
do
this.
So
it's
almost
like
your
phone
is
what
you
do
for
email,
but
also
it's
your
gps.
It's
also
how
you
communicate
with
other
people.
You
check
the
weather
stuff
like
that,
and
that's
what
we're
trying
to
do
right.
A
So,
as
we
build
out
our
app
more,
we
want
to
become
basically
the
iphone
for
software
developers
all
right.
Okay,
so
can
I
help
clarify
anything
or
I'll
talk
about
why
people
buy
gitlab
good
right
now,
it's
pretty.
A
B
A
A
Number
two
is
we
know
you
have
tight
deadlines.
We
will
help
you
to
deliver
your
product,
better
products
faster
right,
so
all
those
apps
you're
developing
the
projects
that
you
have,
we
will
help
you
to
make
better
output
faster
with
gitlab
number
three
is
that
we
help
to
reduce
security
and
compliance
risk.
So
this
is
really
great,
because
our
total
addressable
market
is
basically
everyone
in
software
development
right
any
company
with
software
people.
Then
they
have
room
for
gitlab.
We
can
help
them.
A
So
how
do
we
do
some
of
this
stuff?
We'll
talk
about
it,
but
I
want
to
talk
about
some
caveats.
First,
we
already
talked
about
one
is
the
fact
that
this
is
counter
cultural
right
having
a
single
application.
That
does
a
lot
of
this
stuff
is
not
how
people
naturally
think,
and
a
lot
of
these
engineers
are
actually
rewarded
for
going
out
and
finding
this
new
cool
tool
right.
That's
a
very
common
thing.
A
The
other
thing,
that's
kind
of
something
that
we
have
to
deal
with
is
the
fact
that
a
lot
of
people
are
invested
in
their
current
tools.
So,
let's
just
say
that
here's
a
customer
it's
on
the
top
and
they
spent
three
years
getting
this
setup
working
really
well.
They've
had
jenkins
for
five
years,
they've
spent
literally
1
000
hours,
updating,
maintaining
and
building
stuff
out
for
jenkins,
so
to
get
them
to
go
migrate
to
something
else
and
rip
out
some
of
this
stuff.
A
A
B
D
D
A
So
if
they
already
have
a
two-year
contract
with
something
for
monitoring
their
applications
and
they
have
a
one-year
contract
ready
for
the
security
stuff,
then
gitlab
is
almost
like
the
combo,
where
you're
not
using
the
drink.
You're,
not
using.
You
don't
want
the
fries,
but
you
still
gotta
pay
for
it
because
you
get
the
entire
app
right.
We
don't
give
you
the
part
the
ability
to
get
part
of
the
app.
A
So
that's
something
that
we
do
come
up
against
is
is
some
people
already
are
locked
in
for
part
of
this
conveyor
belt?
A
And
the
last
thing
that
we
want
to
talk
about
is
the
vast
majority
of
people
they've
heard
of
gitlab,
and
they
have
a
fundamental
misunderstanding
about
what
we
do
so
out
of
all
of
this
awesome
stuff
that
we
do.
They
think
that
we
either
do
10
to
20
of
this.
They
don't
realize
that
we
are
platform
for
entirety
of
software
development,
delivery,
right
and
so
one
of
the
big
fundamental
motions
that
we
have
while
talking
to
customers
is
hey.
Did
you
know
that
gitlab
is
a
single
platform
for
software
development?
A
D
D
A
All
right,
another
caveat
that
I
have
is
sometimes
you're
selling
a
tool
that
it's
in
a
new
space.
So
it's
not
really
about
getting
people
to
switch
to
your
product,
it's
about
convincing
them
that
they
need
something.
That's
new
and
sometimes
you're
selling,
into
established
space,
where
there's,
basically
lots
and
lots
of
options
right.
A
C
D
Really
is
that
that
massive
jump
in
price
per
month
so
yeah,
it's
five.
C
A
C
Well,
I
mean
living
where
I
live.
It's
depending
on
the
restaurant
could
be
anywhere
between
11.
If
you
go
cheap
to
like
I've.
Seen
like
25
bucks.
A
B
A
That's
exactly
what
I
was
looking
for
is
that
we
have
a
free
tier,
and
so
one
of
the
also
fundamental
motions
that
we
have
here
is
hey
you're
using
git
lab
free.
That's
awesome,
did
you
know
about
all
this
cool
stuff
in
premium?
Would
love
to
chat
with
you
to
see
how
we
can
go
help
you
out
with
get
more
out
of
get
lab
right?
A
A
A
C
Yeah
self-hosted
is
just
having
it
on
your
own
servers
and
essentially
having
your
you
know,
internal
employees
use
it
that
way
or
sas
is
by
using
like
gitlab's
website.
A
A
We
pick
google
cloud
as
our
platform,
so
that's
important
for
us
to
understand
every
once
in
a
while,
a
customer
is
going
to
ask.
Okay
were
the
servers
that
are
running
google
or
like
our
sas
offering
and
the
answer
is
it's
google
cloud
in
the
united
states
and
then
the
other
thing
is
sometimes
you
want
customers.
A
You
have
customers
that
they
want
to
install
git
lab
on
their
own
hardware.
So,
let's
just
say
it's
a
top
secret
project
right
and
so
they're
going
to
go,
install
git
lab
on
their
own
computer
in
their
own
private
data
center.
So
that's
what
this
picture
is.
It's
not
the
best
picture
all
right.
So
one
thing
to
understand
that
customers
ask
us
all
the
time
is
the
pricing
is
the
same
between
sas
and
self-hosted,
so
you
actually
save
money
with
sas
because
you
don't
have
to
spend
your
own
computers
on
the
sas.
A
B
A
Okay,
awesome-
and
the
other
thing
I
want
to
talk
about
is
that
we
right
now
from
a
revenue
perspective,
we
get
around
55
percent
of
our
revenue
from
self-hosted,
so
we
get
more
money
from
self-hosted
than
we
do
from
sas
and
in
this,
if
your
customer
needs
self-hosted,
we
are
pretty
much
the
best
provider
in
the
market.
At
this
we
are
the
best
at
being
a
self-hosted
like
software
delivery,
like
lifecycle
platform,
so
have
around
79
market
share.
C
A
Github
was
not
architected
really
in
a
way
to
scale
out
very
well.
So
if
you
get
like
20
000
30
000
employees
on
the
platform,
it
gets
really
slow
versus
with
gitlab.
You
don't
really
have
as
much
of
a
problem
with
that.
We
scale
out
better
from
a
speed
performance
perspective,
got
it.
B
A
Right,
cool,
okay,
so
talking
a
little
bit
about
the
value
drivers
that
we
bring.
How
do
we
make
people
more
efficient
help
them
deliver
better
products
faster
part
of
this
is
that
we
help
them
to
implement
best
practices
right.
So
this
is
stuff
that
everyone
wants
everyone
knows
about,
but
it's
almost
like
a
sports
team.
Everyone
knows
we
need
to
have
great
communication.
We
need
to
play
good
defense,
but
the
secret
isn't
what
the
best
practice
is.
The
secret
is:
how
do
you
actually
get
there
right
and
just
like
that?
A
People
in
software
development
today
they
want
what
they
call
agile
workflows.
They
want
this
stuff
called
cicd
if
you
have
mature,
agile
and
ci
cd
workflows,
you're
much
more
efficient
than
your
competitors,
so
it's
not
like
20
30
percent,
more
efficient,
we're
talking
about
like
100
200,
more
efficient
right,
so
it's
a
huge
value
driver
for
these
businesses,
and
one
of
the
things
that
we
do
is
that
we
make
it
very
easy
for
people
to
get
this.
A
So
let's
talk
about
agile,
real,
quick,
so
software
development
is
something
that
is
new
in
the
sense
that
it's
only
really
existed.
For
30
years,
and
because
it
is
newer,
it
takes
time
for
people
to
figure
out
how
to
manage
this
process
right
and
how
to
come
up
with
these
best
practices.
A
So
the
first
way
in
which
people
really
develop
software
is
this
method
called
waterfall
in
waterfall.
It's
basically
me
as
a
buyer,
I
go
over
and
I
say
I
want
a
website.
I
wanted
to
do
a
b
and
c
here's
some
pictures
here,
design
spec.
I
want
customer
reviews
and
I
want
this
other
stuff-
give
me
my
website
right
and
then
I
leave
and
I
come
back
six
months
later
and
then
I
pay
them
thirty
thousand
dollars,
and
then
I
get
my
website
and
the
problem
with
that.
A
Is
that,
because
there's
no
ongoing
dialogue
in
communication,
then
sometimes
there
are
big
misunderstandings
that
happen,
because
maybe
someone
misinterpreted
something
or
there
was
maybe
something
that
was
missing
in
the
design
document.
Let
me
give
you
another
example
of
this.
Let's
just
say
that,
like
using
housing
as
an
analogy,
so
let's
just
say
that
I
am
a
builder
right
customer
goes
to
me
and
says
I
want
this
house
four
bedrooms,
two
bath.
Here's
the
design
document
I
go
out
and
I
build
this
house
there's
no
communication.
A
What's
gonna
end
up
happening
is
either
a
I'm
gonna
make
mistake
b.
Part
of
the
design
dock
is
missing.
Three
the
buyer
actually
doesn't
know
what
they
want
and
then
after
it's
getting
built,
they
realize
that
they
wanted
something
different
right.
That
happens
all
the
time
and
then
so
there
might
be
situations
in
which
the
customer
says.
A
Oh
wait
like
I
didn't
realize
that
what
I
was
putting
down
was
going
to
look
like
this.
Can
you
go
modify
this
room
right?
The
problem
is
that
if
the
builder
comes
back
when
the
house
is
already
built,
if
you
want
to
go
make
a
change
on
the
first
floor,
you
might
have
to
rip
off
the
entire
second
floor
right.
If
you
have
a
problem
in
the
foundation,
you
might
have
to
rip
out
the
entire
house.
A
So
agile
is
a
different
approach
for
projects
and
the
whole
idea
is:
let's
go.
Lay
the
foundation:
let's
bring
the
buyer
back
and
inspect
it.
If
there's
a
problem,
let's
go
fix
the
foundation
before
we
build
all
this
other
stuff.
On
top
of
it
right,
so
the
total
cost
for
revision
is
much
cheaper
in
this
example.
A
So
after
they
like
the
foundation,
then
we'll
put
up
the
scaffolding
they
like
this
great.
If
they
don't
we'll
modify
it
before
we
put
more
stuff
in
and
then
we
keep
on
doing.
This
then
put
in
the
electricity
put
in
the
plumbing,
put
up
the
walls
put
on
the
roof
and
then
finally
we're
done
so.
It's
basically
what
we
call
an
iterative
approach
to
work
and
because
we're
constantly
revising
and
iterating,
we
can
actually
do
work
faster.
A
Awesome
and
so
basically
how
modern
software
projects
work
is
there's
this
thing
called
sprints.
Our
project
is
gonna,
be
sprint,
one
sprint,
two
sprint
three
sprint
four
and
then
sprint
one
will
be
the
foundation.
Sprint
two
will
be
the
scaffolding
sprint
three
will
be
like
the
electricity
sprint.
Four
will
be
like
the
drywall
or
something
like
that,
and
so
that's
how
we
an
agile,
modern,
workflow
works,
is
that
there
are
sprints
and
the
value
add
that
gitlab
has.
Is
that
it's
very
easy
to
do:
agile
in
gitlab,
okay,
so
best
practice.
A
Number
two:
is
this
stuff
called
cicd
and
the
way
to
sort
of
think
about
this
is
that
this
is
automation
that
speeds
up
your
software
development
and
delivery,
and
I
want
to
show
you
an
example
of
this:
here's
the
gitlab
platform
right
now
you
can
see
this
is
all
source
code
for
the
gitlab
application
itself,
and
over
here
I
have
all
of
these
developers
that
are
trying
to
get
new
code
submitted
into
the
platform.
So
we
can't
just
accept
anyone's
code.
A
There
has
to
be
a
democratic
process
for
getting
the
code
in,
or
else
our
competitors
could
come
in
and
just
trash
our
code
right.
There
has
to
be
a
peer
review
process
for
what
gets
into
our
code
base.
Otherwise
it's
just
unmanageable
so
over
here
all
these
developers
are
trying
to
submit
a
code
and
what
they're
doing
is
they
are
saying:
here's
my
request
to
change
the
code
or
merge
code.
A
So
people
have
the
right
to
challenge
me
in
what
I
did
and
that's
what
people
are
doing.
So
people
are
saying,
like
I
love
this
contribution,
but
have
you
considered
this?
I
I
like
what
you
did
with
this
line
of
code,
but
have
you
thought
about
how
this
changes,
how
we
invoke
the
database
right?
So
this
is
a
collaborative
process
and
people
have
the
ability
to
challenge
the
developer,
but
let's
talk
about
ci
cd.
So
what
ci
cd
is
is
that
every
time
someone
submits
new
code
in
the
platform,
then
we
have
all
this
automation.
A
A
D
Is
is
that
something
that's
what
these
cicd
capabilities
is
that
something
that
is
pre-built
into
git
lab
when
you
purchase
it
or
does
the
team
choose
which
functions
they
want
to
be
under
that,
like
scope,.
A
A
All
right,
so,
the
last
thing
that
I
want
to
talk
about
is
that
I
had
a
conversation
with
vice
president
at
red
hat,
which
was
the
last
place
that
I
worked,
and
he
was
this
vice
president.
That
was
in
charge
of
engineering,
and
I
asked
him
I'm
not
going
to
mention
his
name,
but,
like
I
asked
him,
what
is
one
of
the
things
that
you
see
at
your
level?
That
is
one
of
the
biggest
problems
for
engineering
organizations
like
you've
been
a
engineer.
You've
been
a
vp
at
hp.
A
You've
been
a
vp
at
this
other
company.
You
you've
literally
been
at
three
publicly
traded
companies
right.
So
what's
the
biggest
problem
with
engineering
groups
today
and
he
basically
paused
a
little
bit
and
then
he
said
you
know
what
chris
one
of
the
big
things
that
I
actually
see
at
my
level
is
that
teams
don't
communicate
with
each
other
and
because
of
this
literally
one
group
is
doing
what
another
group
has
done
two
months
ago
over
and
over
again,
and
he
basically
said
more
like
this
problem
gets
way
worse
if
you're
globally
distributed.
A
So
if
you
have
a
team
in
poland,
another
team
in
the
uk,
austin,
texas,
portland
and
india,
then
literally
you
could
be
spending
like
20
30
percent
of
all
of
your
engineering
time
wasted.
Because
of
all
this
duplication
and
also
for
me
as
an
engineer,
I
would
estimate
that
maybe
20
to
30
of
all
of
my
work
ended
up
not
being
used
because
people
didn't
communicate
with
each
other.
So
someone
else
changed
this
thing
and
then
so.
A
My
work
is
now
not
useful
anymore
and
they
might
not
even
have
known
that
like
what
they
were
doing.
The
full
implementations
of
some
other
change
that
they
made.
So
what
I
really
want
to
talk
about
is
the
more
tools
that
you
have
part
of.
A
This
is
a
geographic
problem
right,
so
if
you
have
globally
distributed
teams,
that's
a
problem,
but
another
part
of
this
is
that
if
all
of
your
developers
are
using
github
and
your
devops
people
are
using
jenkins
and
then
your
security
people
only
they
have
access
to
sonar
cube
and
some
of
these
other
things.
Then
the
big
problem
is
my
devops
people.
Now
don't
have
visibility
into
what
some
of
the
things
that
the
security
teams
are
doing
right.
A
A
So
what
I
mean
by
that
is
over
here
is
the
code
change
that
we
looked
at
earlier.
There's
a
guy
named
kyle
edwards.
He
is
trying
to
submit
his
code
change,
but
you're
going
to
have
higher
quality
code
being
written
simply
because
you're
not
just
going
to
have
the
developer
feedback.
You
could
also
have
feedback
from
operations
and
from
the
test
team
and
from
the
security
team,
because
you
have
better
inner
team
collaboration
on
the
gitlab
platform.
A
So
that's
what
we
mean
by
gitlab
being
one
shared
table:
it's
not
just
going
to
be
the
developers
on
github,
the
devops
people
on
jenkins
and
the
one
test
person.
I
used
to
be
a
test
engineer,
so
the
test
engineer
on
the
test
platform.
When
you
have
everyone
using
the
same
tooling,
you
can
have
better
ideas
right.
B
B
A
Let
me
talk
about
reducing
security
and
compliance
risk.
This
is
something
that's
really
really
really
important.
A
And
we
already
talked
a
little
bit
about
this.
One
of
the
things
that's
really
important
for
us
to
understand
is
that
we
are
changing
how
software
development
is
working
for
our
customers,
most
people,
they
test
for
security,
all
the
way
at
the
end
of
their
automation
pipeline.
So
you
remember
that
conveyor
belt
analogy.
A
Most
people,
security,
testing's,
either
forgotten
about,
are,
if
they're
haven't
forgotten
about
it.
They
usually
test
software
right
before
they're
about
to
release
software
to
the
public
and
the
big
problem
with
that
is
that
that's
almost
like
you
already
built
the
house
you're
testing
for
security
when
the
house
is
already
built
right
and
then
so
if
the
security
team
comes
back
and
finds
a
problem
with
some
fundamental
part
of
your
app,
you
might
have
to
go
rip
out
a
large
part
of
your
app.
A
So
to
sort
of
rephrase,
this
security
is
often
forgotten
about
if
it's
not
forgotten
about
it's
tested
at
the
end,
that's
like
testing
your
house
after
it's
already
built.
If
you
find
a
problem
with
the
foundation
in
the
house,
you
might
have
to
rip
out
a
big
chunk
of
the
house
right
and
so
what
we
actually
do
that
changes
the
game
for
these
customers
is
that
when
our
ci
cd
runs,
it
runs
testing
for
security,
as
these
developers
are
writing
new
codes,
so
we're
actually
giving
them
real-time
feedback.
A
As
to
the
security
of
the
code
that
they're
writing.
This
means
that
once
they
build
the
foundation
we'll
test
it
once
they
put
in
the
wood
planks,
they'll
test
it
once
they
put
in
electricity,
they'll
test
it
right
and
then
so
we
actually
prevent
the
situation,
help
to
prevent
the
situation
where
someone
builds
an
entire
house
and
they
find
something
foundationally
wrong
with
it.
From
a
security
perspective,
can
I
help
clarify
the
security
point,
or
is
it
clear
for
yale.
B
A
B
D
I
can
go
a
few
minutes
over.
I
may
just
have
to
just
unlock
my
front
door.
Just
to
you
know
let
the
ruffians
in,
but
when.
A
A
So
one
of
the
main
use
cases
that
we
have
from
a
technical
perspective
is
that
we
have
this
thing
called
version
control
and
really
what
this
is
is
that
it's
a
platform
that
stores
your
code
and
the
reason
why
this
is
important
is
because,
if
you
have
like
a
lot
of
people
working
on
the
same
coding
project,
you
basically
need
to
have
a
single
source
of
truth
on
the
current
status
of
your
software
project
and
then
so
that
is
what
version
control
gives
you,
among
other
things.
A
So
even
though
we
have
maybe,
let's
just
say
a
thousand
contributors
from
60
different
countries
all
collaborating
on
this
project,
this
is
the
single
source
of
truth
about
what
the
code
is
that
makes
up
gitlab
today,
and
I
can
see
all
of
this
code
right
here.
It's
all
public.
This
is
just
literally
the
code
that
makes
up
gitlab.
A
The
reason
why
it's
called
version
control
is
that
we
give
you
really
powerful
capabilities
that
help
you
to
manage
this
entire
large
group
of
files
right
so
I'll.
Give
you
an
example
in
this
history
view,
let's
just
say
that
our
start
complaining
about
something
bad
happening
in
our
app,
and
it
happened
about
two
hours
ago
right.
What
ended
up
happening
was
that
the
login
screens
kind
of
messed
up
for
some
people,
so
they
reported
it
about
two
hours
ago.
Let's
see
some
of
these
changes.
A
Okay,
so
this
one
went
through
this
one
went
through
this
one
went
through
two
hours
ago.
This
doesn't
have
to
do
with
the
login
screen
this
also
this
yeah.
This
doesn't
have
to
do
with
login
screen
this
one.
This
as
an
example,
let's
just
say
this-
is
the
one
that
has
to
do
with
the
login
screen.
What
I
can
do
now
is,
I
can
go
undo
this
change
and
my
app
is
going
to
go
back
to
normal
and
then
now
I
can
fix
my
customer
issue
really
quickly.
A
A
All
right
so
use
case
number
two.
This
thing
called
continuous
integration
or
deployment,
what
we
mean
by
ci,
cd
and
really
what
this
is
is
that
this
is
automation.
That's
speeding
up
our
software
development
delivery
and
just
a
sort
of
recap.
A
An
open
source
project
means
that
anyone
can
contribute,
but
that
doesn't
mean
that
we
just
accept
contributions
from
anyone.
There's
a
process
for
getting
something
into
our
project,
and
if
we
don't
like
your
contribution,
we're
not
going
to
accept
it.
Okay,
so
there's
this
thing
called
a
merge
request.
What
a
merge
request
is
that
it's
a
request
to
get
code
merged
into
our
database.
A
Basically,
so
here's
all
of
the
merge
requests
that
are
coming
in
some
of
these
are
get
lab
team
members,
but
some
of
these
are
people
that
we
don't
even
know
right,
because
it's
an
open
source
project
so
over
here
is
an
example
of
one
of
these
merger.
Quests
developer
is
adding
in
this
green
code
taking
out
the
red
code.
The
ci
cd
is
all
of
this
automation.
A
That's
running
parallel
to
that,
every
single
time
someone
adds
in
some
new
code
we're
checking
it
for
all
sorts
of
powerful
things,
making
sure
that
it's
fast,
that
it's
efficient,
that
it's
high
quality,
that
it
works,
that
it's
secure
and
we
do
this
in
an
automated
fashion.
So
this
is
a
really
powerful
efficiency
driver.
A
All
right,
so
next
thing
I
want
to
talk
about
is
this
thing
called
devsecops,
so
the
thing
to
sort
of
understand
is
that
the
vast
majority
of
people
test
for
security
right
before
they're,
about
to
release
software
into
the
wild
and
then
so.
The
big
problem
with
that
is
that
it's
the
just
sort
of
to
recap:
it's
the
house
analogy
right,
so
you're
literally
going
to
go
check
this
house
for
something
right
before
you're,
going
to
give
it
to
the
buyer.
A
Well,
the
problem
with
that
is
that
if
there's
some
structural
issue
or
some
sort
of
issue
with
tubing
or
electricity,
then
you
might
have
to
rip
out
a
huge
chunk
of
the
house.
How
we
change
the
game
is
that
every
single
time
someone
is:
writing
new
code,
we're
testing
for
security?
That's
all
of
this
stuff
here.
So
all
these
vulnerabilities
hackers
bad
things
that
we
need
to
fix,
we're
going
to
give
the
developers
real-time
feedback
in
terms
of
the
stuff
they're
adding
in.
A
Okay
last
use
case
is
something
called
agile
project
management
and
what
agile
project
management
is.
Let's
just
say
that
you
have
a
globally
distributed
team.
You
got
three
people
in
poland,
you
got
two
in
london,
you
got
three
in
portland
and
you
got
two
in
india
right.
So
it's
one
team
that
means
that,
because
they
really
can't
collaborate
like
there's
different
time
zones,
you
basically
need
some
sort
of
process
management
system
for
you
to
find
out
the
current
status
of
work
on
your
team.
So
what
we
actually
have
is
we
have
public.
A
This
is
like
a
big
to-do
list,
so
this
is
like
one
item
of
stuff
to
do.
Then.
This
is
another
like
work
item.
This
is
another
work
item
for
engineers
and
then
so,
because
we
have
a
globally
distributed
team.
If
we're
keeping
this
up
to
date,
then
we
know
what
my
colleague
in
india
might
call
it
in
portland
what
they
did
when
I
was
asleep
right.
So
that's
why
it's
really
important
for
us
to
use
something
like
a
project
management
tool
for
us
to
stay
on
the
same
page,
things
that
this
shows
us
is.
A
I
know
who's
working
on
what
so
this
work
item
is
being
done
by
eric
this
work,
item's
being
done
by
miranda.
I
know
the
current
status
of
this
so
right
now.
We
think
this
is
definitely
deliverable.
We
think
this
might
get
pushed
out
because
it's
too
ambitious-
and
we
can
collaborate
on-
what's
happening
here
too
right,
so
people
can
basically
give
ideas
in
terms
of
this
to
do
list.
Someone
can
say
I
already
did
this.
I
solved
this
two
months
ago,
because
I
did
this.
A
You
should
take
a
look
here
right,
and
so
this
can
be
a
great
driver
for
efficiency
for
an
organization
as
well.
A
Cool
all
right
so
summarizing
everything.
One
of
the
ways
in
which
we
can
talk
about
gitlab
because
it
is
so
complicated,
is
that
we
are
a
devops
platform,
we're
not
a
single
point
tool,
but
we
are
a
platform
for
doing
lots
of
different
things
and
the
business
value
that
we
have
is
that
we
allow
for
fast,
efficient
and
secure
software
development
delivery.
So
that's
one
example
of
an
elevator
pitch
I'll.
Give
you
all
a
couple
more
later
too.