►
Description
Learn about our journey to the 12.0 release and find out what we're planning next as we delve deeper into DevSecOps. We'll also have an Ask Me Anything session with GitLab CEO Sid Sijbrandij!
Read more about our product vision: http://bit.ly/2IyXDOX
Learn about FOSS & GitLab: http://bit.ly/2KegFjx
Get in touch with Sales: http://bit.ly/2IygR7z
A
Hello,
everyone
and
welcome
to
the
gitlab
12m
livestream.
My
name
is
John
Jeremiah
and
I'm
gonna
be
hosting
today's
livestream.
While
we
share
and
celebrate
some
of
the
accomplishments
of
our
journey
of
building
gitlab
and
moving
from
11.0
to
12.0,
today's
livestream
is
going
to
consist
of
a
couple
of
different
segments.
We're
gonna
share
a
little
bit
upon
the
journey
of
what
it's
taken
to
go
from
11
.,
o
to
12
ato.
We
want
to
talk
a
lot
about
our
community
and
a
community.
That's
helped
to
contribute
to
make
gitlab
what
it
is.
A
We
will
have
a
panel
discussion
we'll
talk
about.
Why
is
security
and
operations
so
important
to
the
DevOps
lifecycle?
Well,
spend
a
little
time
talking
with
a
customer
and
and
to
close
it
all
up.
Sid
is
going
to
share
some
time
and
give
some
insight
in
an
AMA.
So
if
you
have
questions,
please
post
the
questions
into
the
YouTube
chat
and
share
your
questions
and
we'll
have
questions
for
Sid
at
the
end
of
the
session.
A
So,
let's
dive
in
the
journey
from
12.0
has
consisted
of
a
number
of
key
releases
where
we
have
gone
from
auto
dev
ops,
to
building
out
capabilities,
supporting
security
and
operations,
all
in
a
single
application
to
support
the
entire
DevOps
lifecycle.
The
journey
has
been
fantastic:
we've
had
over
400
different
features
and
improvements
shipped
over
the
last
year.
A
In
addition
to
that,
we've
seen
massive
rep
growth
of
DevOps
on
gitlab
comm,
where
we
had
over
a
million
merged
monthly
merge
requests
last
month,
absolutely
amazing
growth
and
the
growth
is
not
just
of
people
adopting
and
using
git
lambeth,
but
our
team
is
growing
as
well
as
I.
Look
back
from
last
year
to
today
we
have
over
400
new
team
members
who
are
part
of
the
team
helping
to
build
and
make
it
lab
awesome
we're
not
doing
it
ourselves.
It's
a
community,
that's
making
it
happen.
A
There's
been
over
2000
community
contributions
over
the
last
year
and
it
continues
to
grow
based
upon
the
community,
offering
input
and
insight
and
helping
to
make
gitlab
even
better.
It's
not
just
that
it's
about
developers
and
security
and
operations
all
coming
together
and
that's
the
theme
that
we're
talking
about
with
12.0,
where
we
see
12.0
in
the
future.
A
As
how
does
dev
sack
ops
come
together
and
when
we
made
our
announcement,
we
the
release
post,
we
talked
about
specific
capabilities
and
that's
the
purpose
of
today's
livestream
is
to
double
click
into
and
talk
about
where
we're
going,
what
we're
doing,
but
before
we
do
that
I
want
to
ask
Emily
to
share
some
insight
about
the
community
and
how
the
community
has
contributed
to
where
we're
going.
So
to
that
Emily
cook,
our
senior
community
advocate
Emily
I
turn
it
over
to
you.
Hi.
B
Everyone,
my
name,
is
Emily
cook
I'm.
The
senior
community
advocate
at
get
lab.
Our
goal
on
the
community
relations
team
is
to
ensure
everyone
is
heard
and
feels
welcomed
into
our
community
I
joined
just
before
11.5
and
in
the
seven
months
that
I've
been
here.
I've
definitely
noticed
very
impressive
growth
in
engagement,
so
next
slide
Jen.
Thank
you.
So
for
our
wider
community
contributions,
gitlab
has
been
open
source
since
day.
One
and
we've
always
had
a
lot
of
wider
community
members.
Who've
helped
improve
gitlab.
B
When
the
co
contributor
program
was
started,
one
of
our
main
goals
was
to
lower
the
barrier
to
entry
for
new
contributors
and
to
develop
a
closer
sense
of
community.
Among
our
contributors,
we
were
able
to
highlight
ways
to
make
contributions
easier
and
to
bring
people
together
through
contributor
blog
posts
or
monthly
core
team
meetings
and
our
quarterly
hackathons,
if
so,
to
look
at
the
metrics
between
1100
and
1200
you'll
see
that
we
have
more
than
600
wider
community
contributors
and
had
over
2000
M
R's
merged.
B
Also
wider
community
members
make
contributions
to
more
than
fifteen
gitlab
projects,
including
C
e
EE,
R
runner,
our
omnibus
and
our
shell
projects,
so
yep
next
slide.
Okay,
so
for
our
community
growth,
we've
had
a
great
global
community,
but
we
thought
there
was
an
opportunity
to
provide
them
with
better
support.
So,
since
a
lot
of
not
six,
our
focus
has
been
on
improving
our
support
for
meet-up
organizers.
B
We
want
to
send
a
special
thank
you
to
our
meetup
community
in
Hamburg,
who
are
streaming
this
together
right
now
and
all
of
our
other
meetup
groups
who
will
be
gathering
to
watch
this
recording
at
a
release
party
in
the
coming
weeks.
Since
Alvin
ah-oh
we've
supported
more
than
160
meetups
as
speakers
organizers
or
sponsors,
our
meetup
community
has
grown
to
more
than
3500
members.
It's
not
a
lot
of
fun.
Just
watch
the
community
grow
and
we
have
plans
to
continue
to
improve
our
support
for
meetup
groups
and
help
them
become
even
more
successful.
B
So
an
example
of
this
is
our
heroes
program,
which
will
help
better
engage
support
and
thanks
members
of
the
wider
gitlab
community
who
serve
as
advocates
of
--get,
lab
and
tech
communities
around
the
globe,
we're
still
putting
on
the
final
touches
to
that,
but
we
expect
to
launch
it
in
mid-july
so
more
to
come
in
the
months
following.
Ok,
next
next
slide,
so
we
now
have
10
official
crew
team
members,
including
Sid.
B
So
next
we
have
a
get
lab
connect,
which
is
a
regional,
hosted
event
that
brings
together
customers
and
prospects
to
share
stories
and
lessons
learned
about
get
lab.
In
2019,
we
held
nine
connect
events
with
over
400
in
attendance,
and
we
have
it
does
a
more
plan
for
the
remainder
of
the
year.
We
also
hold
monthly
community
community
advisory
board
meetings.
Virtually
we
now
have
over,
we
are.
B
We
now
have
28
cab
members
and
we
had
our
first
in-person
meeting
in
April
in
New
York
City,
and
we
have
our
next
one
planned
in
October
in
Seattle.
Ok,
so
next
slide.
So
every
release
ticket
lab
team
members
select
a
wider
remember
as
an
MVP,
and
you
can
see
them
listed
at
that
top
link.
We
have
an
MVP
contributor
who
is
just
hired
into
the
company,
actually
Marcel,
so
we'd
like
to
take
this
time
to
thank
everyone.
Who's
helped
get
us
to
where
we
are
today.
So
you'll
see
there
on
the
slide.
That's
everyone.
B
Who's
been
a
MVP
contributors
since
the
11th
release,
so
just
take
a
second
thanks.
Thanks
contributors.
Ok,
so
next
slide,
so
we'd
like
you
to
join
us
with
our
community
without
our
community
get
lab
would
not
be
where
it
is.
Today
our
company
and
product
may
be
growing,
but
as
one
of
our
core
team
members
has
said,
it's
never
been
easier
to
contribute
on
this
page,
which
should
be
shared
and
YouTube
in
the
description.
B
You'll
find
some
links
to
help
you
get
started
if
you're
considering
contributing
to
get
lab,
we
try
to
make
the
barrier
to
entry
as
low
as
possible,
because
we
really
understand
that
an
open,
welcoming
community
is
vital
to
the
success
of
the
open
source
software
model.
So
thank
you,
everyone,
that's
it
for
the
community,
so.
A
Awesome
Emily,
thank
you,
so
very
much
I
think
it's
amazing
what
the
community
has
done
together
and
that
what
the
work
that
you
and
the
team
do
to
bring
people
together
is
amazing
as
powerful
as
we
as
we
grow
together.
Thank
you
so
much
so,
let's,
let's
pivot,
I'd
like
to
talk
a
little
bit
and
and
share
and
bring
mark
and
Kenny
and
Kathy
on
mark
leads
our
product
strategy.
Kenny
is
responsible
for
product
for
our
products.
A
Around
operations,
products
and
Kathy
leads
our
security
efforts
here
at
get
lab
to
ensure
that
we
have
solid
and
robust
information
security.
So
to
kick
it
off.
I'd
like
to
throw
a
question,
perhaps
mark
to
you
to
ask
you
about
your
perspective
of
the
vision
and
strategy
for
us
and
how
we're,
including
in
both
security
and
operations
in
to
get
lab,
mark
sure.
C
Thanks
John
yeah,
we
started
off
really
focus
on
developers
with
version
control
for
your
code
and
issue
tracking
and
a
while
back
we
added
CI
or
continuous
integration
and
testing,
and
it
really
opened
up
a
large
door
to
increasing
the
scope
of
the
work
flows
that
we
handled.
Then
we
went
further
and
actually
started
focusing
on
how
to
help
developers
go
faster
from
idea
to
production.
But
we
didn't
stop
at
production.
C
We
then
added
configuration
and
monitoring
of
your
production
apps
and
without
we
really
entered
the
world
of
DevOps
and
we
actually
won
a
little
bit
further
than
just
DevOps.
We
added
security,
but
we
don't
call
it
a
cops.
Usually
we
just
call
it
DevOps,
but
in
the
beginning
this
was
all
still
centered
around
the
developer,
really
how
the
developer
did
operations,
how
the
developer
looked
at
security
with
twelve-point.
C
Oh,
it's
a
huge
milestone
in
our
transition
to
not
just
doing
dev,
SEC
and
Ops
for
developers,
but
serving
operations,
people
and
security
people
with
dashboards
and
workflows
customized
around
getting
those
jobs
done,
and
that's
really
a
huge
part
of
our
broader
mission.
You
know
our
vision.
Our
mission
is
to
have
everyone
contribute,
there's
tons
of
people
involved
in
software
development
and
delivery,
and
we
want
to
support
all
of
these
people
in
their
journey
of
collaborating
together.
D
Amazing
Kenny
go
ahead,
oh
I
was
gonna,
say,
mark
I,
agree
and
I.
Think
you
know
part
of
our
vision
of
everyone
can
contribute.
We
start
thinking
about.
You
know.
Typically,
the
developer.
Devops
lifecycle
is
really
about
creating
new
features
and
responding
to
the
features
that
a
customer
might
want.
So
building
that
kind
of
like
feature
capabilities
of
an
application,
but
I
like
to
think
about
how
you
can
consider
other
capabilities
of
an
application
like
its
security
or
its
manageability
or
its
resilience
in
production,
as
just
as
critical
and
building
new
DevOps
leaps.
D
For
the
same
thing,
we
think
about
adding
the
design
or
the
kind
of
user
experience
of
your
application,
adding
that
into
the
DevOps
lifecycle.
So
it's
really
cool
how
we
have
this
very
expansive
view
that
doesn't
just
stop
at
the
developers
and
creating
and
shipping
features,
but
really
also
shipping
and
improving
and
iterating
on
the
capabilities
of
your
application.
Yeah.
E
C
Sorry,
just
and
say
it's
really
great
that
when
they
do
loop,
you
in
you
can
actually
still
use
that
same
same
information
like
one
of
the
big
challenges
with
point
solutions
is
you
know,
you're.
The
security
team
often
has
a
different
set
of
tools
to
do
their
audits
and
everything
else,
and
the
developer
is
a
different
sort
of
tools
and
you're
sort
of
crossing
each
other's
paths
and
not
really
talking
together
and
having
a
single
solution.
C
E
And
you
know
we
do
a
lot
of
dogfooding,
but
right
now,
frankly,
were
more
in
the
contribution
mode
than
dogfooding
and
we'd
like
to
ramp
up
the
dogfooding.
But
if
we
look
at
it
from
both
perspectives,
they're
both
useful,
for
example,
for
our
own
compliance
requirements
that
we're
looking
to
do
for
our
frameworks.
We
have
access
to
requests
which
we
make
great
use
of
yet
lab
issues
to
implement
that
and
have
that
audit
record
for
future
compliance
chefs.
We
also
have
recently
rolled
out
an
escalation
engine
using
soviet
lab
issues.
E
D
D
Is
this
pain
of
kind
of
integrating
and
we
typically
think
of
it
as
like,
switching
context
between
tools,
but
there's
another
also
value
point
that
we
have
the
opportunity
to
provide
that
we
do
in
in
many
cases
today
and
that's
that
we
can
immediately
give
you
the
correct
context
because
we're
aware
of
that
information.
So
it's
not
just
oh
there's
less
pain,
but
it's
also
super
value.
D
A
That's
awesome
I'd
like
to
continue
talking
about,
though
one
of
the
things
Kay
that
you've
been
working
on
a
lot
has
been
about
release
management
and
release
orchestration.
It's
it's
incredibly
important
for
operations
teams.
How
do
you
see
that
evolving
over
the
next?
You
know
several
releases
and
into
the
future
yeah.
D
Thanks
John
I'll
say
you
know:
I
started
similar
to
Emily
in
11.5
release
cycle,
and
so
most
of
this
work
predates
me
and
and
Mark
and
the
rest
of
the
team
have
a
lot
to
do
with
our
capabilities
here,
as
Mark
mentioned,
we've
entered
into
this
CI
CD
world
many
years
ago,
and
today
it's
astounding
customers
talk
about
how
they
love
their
our
CI
capabilities.
It's
a
great
place
for
me
as
a
product
manager
to
come
and
talk
to
customers
and
have
them
use
words
literally
like
love.
D
Let's
talk
about
these
capabilities,
but,
like
everything
I
give
up,
we
don't
stop
there,
we're
always
moving
forward
and
always
progressively
iterating,
and
so
for
us.
You
know
we
take
the
capabilities
that
we
have
today
around
being
able
to
define
your
pipeline
in
code,
as
are
what
we
call
github
CI
that
yamo
file
we've
started,
presenting
those
in
dashboards
and
John
I.
Think
you
have
a
slide
to
show
the
dashboards.
The
dashboards
are
meant
to
give
you
a
view
across
multiple
projects
of
the
current
pipeline
status.
D
D
Compliance
for
teams
that
require
it
as
imperative.
All,
while
remember
keeping
in
mind
that
the
number
one
thing
we
don't
want
to
do
is
add
more
friction
to
the
process.
So
it
has
to
be
easy,
so
you
can
continue
to
ship
faster.
So
those
are
some
of
the
things
that
we're
working
on
in
the
STI
CD
world.
A
D
In
the
in
the
tool
itself,
we
have
you
know,
and
this
is
a
testament
to
the
team
and
our
the
team
spirit
of
iteration.
During
the
course
of
the
11
auto-release
series
11
release
series,
we
added
a
whole
suite
of
security
scanners,
SAS
task
dependencies
scanning
container
scanning
secret
detection,
all
as
part
of
get
lab
that,
then
we
took
this
very
shift
left
approach
that
you
get
that
scan
as
a
result
of
a
pipeline,
so
you
get
it
on
every
commit.
D
So
as
a
developer,
every
time
you
make
a
commit,
you
get
the
results
of
these
security
scans.
So
you
see
it.
You
know
very
quickly
before
you,
even
before
the
code
is
even
merged,
so
it's
really
about
enabling,
as
Kathy
mentioned
the
developers
to
be
more
self-service
on
the
security
scanning
and
the
security
teams
to
only
be
alerted
when
it's
critical
and
we
alert
the
security
teams
via
dashboards.
We
create
dashboards
that
show
the
overall
vulnerabilities
the
recent
pipelines,
the
trends
in
those
vulnerabilities,
so
that
in
the
future
teams
can
can
highlight.
D
Oh,
you
know
here's,
maybe
some
developers
that
need
some
review
of
their
security,
best
practices
or
here's
the
trend
lines
for
whether
or
not
we're
adding
new
vulnerabilities
to
an
application
or
not.
But
we
don't
want
to
just
stop
there.
We
want
to
continue
to
add
more
robustness
in
the
workflows
that
mark
and
Kathy
mentioned
around
if
there
needs
to
be
some
approval
of
vulnerability
and
who
can
dismiss
vulnerabilities
within
a
merge
request.
But
then
also
you
know,
there's
we
are
I
was
recently
talking
to
a
heavy,
get
lab
secure
user.
D
Who
is
mentioning
that
we
have
this
ability
to
move
beyond
just
running
our
security
scans
on
a
merge
request
basis,
but
also
running
them
kind
of
continuously
on
the
on
the
project
or
on
the
repository?
It's
important
that,
especially
as
a
security
professional
that
they
can
answer
the
question
of.
E
And
I
think
that's
really
important
and
what
I
want
to
emphasize.
Is
that
not
sure
if
everyone
realizes,
but
it
is
much
more
expensive
to
fix
a
security
vulnerability
after
the
fact
than
get
in
early
on
that
process
and
make
sure
that
due
diligence
is
taken
at
the
beginning?
So
not
only
is
there
that,
but
there's
that
self-service
of
allowing
developers
to
help
themselves
which
in
the
end
also
adds
more
awareness
to
security
culture
at
a
company.
So
I
think
that
is
all
really
good.
A
Awesome
so
Kathy,
you
know
it's
a
security
executive
and
a
leader
here
at
get
lab.
You
you're
involved
in
helping
to
shape
our
direction,
our
vision
as
to
where
we
go
as
a
company
and
building
that
out.
How
do
you
see
the
future
of
the
intersection
of
DevOps
and
information
security
or
application
security?
Where
do
you
see
that's
about
it?
So.
E
You
know
increasingly
more
and
more
companies
are
becoming
cloud
native
focus
and
they're
moving
towards
trying
to
do
more
agile
security,
and
that's
the
start
of
being
empowered
and
enabled
by
the
right
tools
and
capabilities
as
well.
You
can't
really
tell
a
legacy
environment
that
you
gotta
be
agile
tomorrow
and
not
provide
them
with
the
right
application
or
tools
to
use.
So
this
is
all
part
of
it.
The
other
part
is
that
increasingly
companies
are
becoming
more
and
more
remote
and
there's
more
global
and
more
remote
workforces.
E
So,
given
all
that
there
has
to
be
a
lot
of
care
in
how
applications
are
being
accessed
remotely
and
how
credentials
are
being
managed,
because
you
can
no
longer
set
a
perimeter
and
monitor
an
environment
that
is,
you
know,
going
to
be
a
given
people
move
from
one
environment
to
another,
but
they
still
need
to
access.
So
security
is
very
important
to
get
right,
that
user
experience
factor.
You
want
to
be
able
to
empower
people
and
let
them
scale
in
so
ship
products.
E
E
Absolutely
so,
first
of
all,
let
me
just
clarify
that
frictionless,
it's
not
going
to
be
possible
with
security
right.
We
try
to
make
as
frictionless
as
possible,
but
it's
never
going
to
be
a
hundred
percent
fiction
list,
because
you're
always
adding
a
new
staff
to
the
process.
That
said,
there's
a
lot
that
we
can
do
to
really
make
sure
people
feel
that
this
is
a
usable
solution
for
them
and
part
of
all
dogfooding.
The
security
team.
E
Strong
looting
of
get
labs
features
is
to
make
sure
that
just
is
usable
for
us
and
if
it's
not
usable
for
us
them,
then
we
work
with
pion.
Do
we
work
with
developers
to
figure
out
how
this
can
be
more
usable?
So
that's
a
very
important
feedback
loop
that
many
products
have
not
quite
incorporated
that
we
want
to
do
here
and
also
do
better
than
we're
currently
doing.
So.
That's
all
very
important.
A
Very
cool,
so
question
Kenny,
you
don't
one
of
the
Thank
You
Kathy
and
really
the
questions.
I
think
that
also
has
come
up
as
well
has
been
a
question
about
and
where
we're
going
from
you
know,
we've
added
incident
management
capabilities
to
to
get
lab
is
something
that
we're
building
in.
How
do
you
see
that
evolving
and
how
will
it
affect
both
your
operations
and
security
together?
A
D
It's
a
great
question:
thanks
John
I'll
say
you
know.
The
the
current
state
of
the
industry,
in
my
opinion,
is
that
there
are
still
a
lot
of
disparate
tools
in
that
end
stage
of
the
DevOps
lifecycle.
That
means
we
really
don't
have
a
lot
of
great
best
practices
for
driving
feedback
from
those
end
stages
back
around
the
loop
to
the
kind
of
plan
stage
and
I.
Think
there's
a
real
opportunity
that
we
get
lab
is
well
positioned
for
because
you
you
can
complete
that
loop
by
having
things
in
code
right,
you
have
your
pipelining
code.
D
D
Our
user
has
a
feature
request.
It's
also
about
other
capabilities
in
it
that
one
of
those
capabilities
are
really
important.
Is
security
right,
I
I
have
found
a
security
vulnerability
in
my
in
the
production
operations
of
my
application.
I
can
then
immediately
recognize
that
and
create
an
incident
and
drive
that
back
and
so
I
think
it's
really
important
that
we.
We
are
well
positioned
to
take
advantage
of
closing
this.
This
DevOps
loop
and
really
it
has
to
do
with
again
there's
potentially
non
feature
capabilities
of
an
application.
Yeah.
E
And
penny
I
really
like
the
point
that
you
made
about
SL,
OS
and
incidents,
is
security,
we're
very
operational.
So
when
there's
a
security,
vulnerability
or
an
incident,
we
need
to
really
take
care
that
we
scale
our
ability
to
escalate
an
incident
if
it
hasn't
been
resolved
within
an
SLA
adaptation.
So
to
that
end,
my
team
has
been
dogfooding
and
contributing
an
escalation
engine
recently,
which
I
mentioned
earlier,
but
to
get
into
it
a
little
bit
more.
E
The
escalation
engine
helped
to
drive
more
accountability
and
ownership
across
all
of
the
gate,
lab
issues
that
are
related
to
Incident
Response
and
also
to
SL
age
of
fixing
security
vulnerabilities,
it's
very
hard
for
us
to
manually
chase
down
what
needs
to
happen
next
in
an
issue,
but
with
automation
and
escalation.
We
do
that
so
much
more
effectively
and
so
we're
very
excited
about
contributing
what
we
learned
from
dogfooding
this
process
and
everything
to
making
it
part
of
a
future
yet
lab
feature.
D
Yeah
and
I'll
just
say
it's
something
you
need
to
give
up
in
my
experience
that
we
have
this
great
dog
fruiting
culture
of
not
just
hey,
we
there's
like
a
forest.
You
have
to
use
this
tool,
but
also
that
the
teams
are
because
everyone
can
contribute
here
at
get
lab.
The
teams
are
fully
capable
of
adding
stuff
back
into
the
product
and
building
on
to
the
product
in
teams
that
are,
you
know
like
outside
of
your
traditional
products.
Team
I,
love
that
about
about
gala.
D
A
Good
example
that,
and
this
release
was
get
live,
insights
Macan
the
quality
team
they
build
in
sizes,
so
they
can
track
how
they're
doing
from
a
testing
and
defect
perspective,
and
now
it's
it
shift
as
part
12.0,
which
was
an
exact
example
of
that
mark.
You
know
one
of
the
things
I
want
to
share
something
to
go
back
to
the
slides
quickly.
One
of
the
things
that
you
did
and
the
team
did
recently
was
you
published
the
category
maturity.
Page
I've
got
two
slides
of
this
I'd
like
to
understand.
A
C
Of
course
yeah,
it
actually
turns
out
to
be
really
really
helpful
for
people
to
understand
where
we're
at
and
if
you
I,
don't
know
if
you
can
scroll
down.
But
if
you
look
at
that
page
yourself
at
some
point
below
that,
it
also
gives
the
plan
for
how
we're
going
to
evolve
all
of
those
categories
so
not
just
where
we're
at,
but
where
we're
going
and
then
so.
C
The
thing
we
just
recently
introduced
is
sort
of
not
just
talking
about
the
categories,
the
features
and
how
they're
going
to
mature,
but
how
the
stage
itself
matures
and
so
we've
come
up
with
this
sort
of
seven-point
scale
of
describing
how
a
stage
kind
of
matures
well
really
step.
Zero
is
not
nothing
exists
at
all,
but
then
it
starts
with
usually
we'll
create
something
in
the
stage
and
we'll
use
it
internally.
Then,
at
some
point
you
know
a
few
more
users
really
use
it.
C
Our
version,
control
and
verify
is
where
CIA
lives,
and
so
those
are
really
mature
going
forward.
The
next
really
big
stage
that
we
see
and
thus
we're
prioritizing,
is
release
and
that's
where
the
big
focus
on
CD
so
being
able
to
continuously
deploy
to
production.
You
know
the
kubernetes
or
wherever
is
you
put
production
and
then
also
the
release,
orchestration
and
management
that
Kenny
talked
about
earlier
release
is
not
only
really
important
just
for
our
customers
generally,
but
it
also
really
opens
up
a
lot
of
the
rest
of
the
DevOps
lifecycle.
C
Once
you
are
deploying
with
gate
lab
to
production.
Well,
then
it's
a
lot
easier
to
monitor
and
configure
your
production
applications,
and
so
that's
kind
of
a
it
really
just
opens
up
the
rest,
it's
kind
of
a
barrier.
Sometimes,
if
you
haven't
done
deployments
there,
it's
hard
to
do
the
monitoring,
but
then,
conversely,
once
you
do
that
and
you
open
it
all
up
now
you
really
got
this
single
application
that
goes
way
beyond
just
you
know
CI
into
your
full
operation
side,
and
so
that's
that's
a
big
big
big
focus
for
us
beyond
that.
C
The
next
two
big
priorities,
our
plan
with
project
management,
we've
got
a
lot
of
great
features
there,
but
we
really
want
to
continue
to
invest,
especially
on
the
sort
of
Kanban
side
and
the
compound
issue
boards
now
that
we
call
them
and
then
secure
for
application,
security
testing.
Obviously
a
big
topic
today,
that's
just
that's
a
big
priority
for
us
over
the
next.
While.
D
Yeah
and
I
think
you
might
I
totally
agree
like
I'm
super
excited
about
this
stuff.
That
comes
as
we
mature
these
categories.
I
do
want
to
make
the
meta
point.
John
John
mentioned
this,
but
I'm
really
proud
to
be
a
git
labra
on
so
many
fronts,
but
the
fact
that
we
are
so
transparent
with
where
our
product
stands
and
its
maturity
is
just
kind
of
a
breath
of
fresh
air.
D
We've
all
encountered
products
where
they
claim
to
do
everything
under
the
Sun
or
are
better
than
sliced
bread,
but
I
love
that
we're
transparent,
we're
honest
with
ourselves,
where
we
are
always
strive
to
be
our
best
critic.
Is
this
this
page
and
the
fact
that
we're
open
in
public
with
where
we
are
with
our
different
maturities
and
is
just
super
inspiring
to
me
so
yeah.
C
We've
had
the
roadmap
transparent
in
public
for
a
long
time.
The
homepage-
maybe
not
a
long
long
time,
but
for
quite
a
while
it
listed
like
here's
where
we're
going.
These
are
the
categories.
It's
only
recently
that
we've
then
been
so
transparent
with
the
maturity
and
say:
okay,
yes,
we've
got
these,
but
even
these
other
ones.
We
have
already
yeah
they're,
still
in
really
early
stages,
and
now
from
our
homepage.
There
is
a
link
to
look
at
the
category
maturities
right
from
there,
and
so
everybody
can
see
it.
It's
a
great
page.
I
do.
A
C
E
This
is
great
personally.
I
can
share
that
I
used
to
do
a
ton
of
technical
product
evaluations
for
security
products
in
particular,
and
it's
always
very
hard
for
me
as
an
evaluator,
to
look
at
a
product
page
and
get
a
sense
of
where
they
are
in
maturity
or
even
if
they
deliver
what
they
promise
by.
So
this
is
really
really
refreshing
for
me
to
see.
I've
never
seen
anything
like
this
seeing
all
the
product,
the
belt
I've
done.
A
It
it
is,
it
is
awesome
and
as
it's
all
I'm
going
to
say
with
it,
but
one
last
question
I'd
like
to
hear
your
thoughts
on
this
yeah
we're
different
because
of
the
way
we're
open
core
with
a
community.
That's
making
contributions
to
get
lot
of.
How
does
that
influence
and
shape
the
priorities
that
you
have
as
you,
you
know,
lead
the
product
side
of
the
team.
D
I'll
share
my
first
one.
You
know
one
of
the
first
things
I
meant
I
noticed
when
I
joined
was
I
was
interacting
on
issues
with
all
sorts
of
people
and
I
had
never
even
stopped
to
question
whether
that
was
a
get
lab
team,
member
or
a
customer
or
a
contributor,
or
it
just
it
doesn't
occur
to
you
and
the
fact
that
we
operate
so
transparently.
You
know,
and
in
conjunction
with
our
open
community,
is
really
this
great
kind
of
cycle
that
feeds
on
itself,
because
we
continue
to
be
transparent.
D
It
makes
community
more
aware
of
what
we're
doing
and
where
we're
headed
they
can
react
and
respond
and
also
contribute
to
that
direction.
So
it's
really
empowering
to
me,
as
a
product
manager,
to
have
both
an
active
community
that
were
a
part
of
as
well
as
have
the
in
terms
of
contributions,
but
also
as
the
sounding
board
as
a
stakeholder
and
where
were
where
we're
headed.
A
Fantastic
I
I
agree.
It's
it's
one
of
the
things
that
I
think
makes
us
special
it's
about
how
we
are
in
this
together.
It's
not
us
and
them
it's
all
of
us
together
and
so
with
that
I'm
going
to
move
forward.
Thank
you
all
so
very
much
for
your
inputs
and
for
your
your
sharing,
also
as
a
reminder
to
everyone
on
the
livestream
that,
after
my
short
after
my
conversation,
my
next
conversation,
we
have
questions
with
CID.
A
So
please
post
your
questions,
since
it
will
share
his
insight
but
I'd
like
to
move
forward
and
introduce
Russell
levy.
Russell
is
a
co-founder
and
CTO
of
Korus
and
he's
a
git
lab
user
and
I
wanted
to
ask
Russell
a
little
bit
of
a
few
questions
about
how
he's
using
git
lab
and
what
they're
doing
Russell.
Could
you
share
a
little
bit
about
about
chorus
introduced
chorus
to
those
of
us
who
haven't,
who
don't
know
chorus,
I'm
going
to
go
back
to
no
sharing
screen,
so
you.
F
F
It
helps
sales
teams
and
support
teams,
increase,
win
rates
and
coach
reps
much
more
effectively
and
we
have
live
transcription
and
AI
based
analytics
and
with
that
course
is
able
to
tell
you
why
you
win
more
deals
or
why
your
team
wins
more
deals
and
why
some
reps
are
more
than
100
percent
on
their
quota.
You
can
also
use
course
to
share
call
moments
internally
externally,
to
get
the
company
aligned
too
short
in
a
deal
cycle.
A
So,
thank
you
and
I
agree.
I
think
you
know
I
find
course
to
be
incredibly
powerful
and
it
helps
me
it
helps
us
to
learn.
We
learn
more
from
listening
to
calls
and
listening
babies.
It's
just
amazing.
So
tell
me
a
little
bit
about
your
development,
delivery
practices
and
processes.
How
do
you
go
about
building
Corvis.
F
We're
using
an
agile
methodology
like
any
startup
claims
to
do.
We
do
it.
Well,
probably
not,
but
we
try
to
so
what
do
we
do?
We
have
our.
We
have
Sprint's
and
we
start
off
with
a
sprint.
We
have
our
sprint
planning
at
the
beginning,
we
create
our
epics
in
gitlab
after
we
have
epics
that
the
product
team
creates
they're
going
to
be
broken
down
by
the
engineering
team
before
the
sprint
starts,
and
then
we're
using
the
we're
basically
using
get
lab
for
the
whole
development
cycle
through
the
release.
F
So
it
means
that
we
have
the
issues
that
are
in
get
lab,
we're
using
that
using
it
for
capacity
planning.
I
know
you
guys
have
a
few
features.
We're
still
waiting
for
on
capacity
planning,
I,
see
it
on
the
on
the
roadmap.
Would
we
sit
there
waiting?
Is
it?
Is
it
going
to
be
12.3
yet
or
not,
and
we
go
through
capacity
planning?
And
then
the
team
just
works
on
the
issues,
we're
using
a
get
lab,
CI
we're
using
it
for
CD
as
well.
A
Thanks,
Russell
and
I
know
that
internally
we
have
teams
waiting
on
the
capacity
planning
feature
as
well
they're
looking
forward
to
using
it
so
you're,
not
you're,
not
alone
and
I,
know
it's
coming
soon.
Yes
using
git
lab
at
Korres.
How
does
it
brought
together?
Has
it
helped
you
to
bring
together
operations
and
security
and
developers
to
have
a
common
view
and
to
eliminate
the
friction
between
the
teams?
Yeah.
F
Completely
I
mean
just
given
the
we
give
access
internally
to
everything
to
everybody
in
the
organization,
so
everybody
is
able
to
see
when
there's
merge,
requests
coming
in
when
there's
features
that
may
need
to
be
flagged
for
security.
We
have
a
few
components
that
we
both
contract,
there's
a
few
components
contractually
if
they're
ever
changed
that
we
have
to
it
has
to
go
through
an
extensive
security
review.
We
have
a
few
other
components,
we're
recording
all
these
conversations.
Some
of
that
has
a
personal
information
on
it.
F
If
we
do
anything,
we
have
some
some
features
that
scrub
personal
information.
If
you
make
any
changes
to
that,
it
just
has
to
make
sure
that
it
works
well
and
from
the
security
point
of
view
that
we
have
we're
doing
it,
we
have
the
we
have
that
visibility
we're
using
the
security
dashboard.
We
just
start
to
use
it
a
month
ago
to
be
able
to
see
if
there's
new
security
issues
that
are
coming
up
and
it
really
helps
the
developers
just
to
say.
Why
is
this?
F
Why
is
this
issue
that
I'm
claiming
is
a
security
issue,
really
a
problem
just
pointing
to
the
Bandit
the
bat
pointing
to
the
external
sources
through
the
Bandit
code
of
why
this
is
an
issue?
How
you
would
exploit
it?
How
this
could
be
a
problem?
It
just
creates
the
the
the
feedback
loops
are
so
much
shorter,
being
able
to
have
all
this
in
one
tool
and
not
having
to
go
to
17
different
sources.
F
A
F
We
I
mean
we
love
I
love,
the
good
lab
community
I've
been
using
good,
lab,
I
think
even
before
chorus.
So
we
start
a
course
or
in
four
years
ago,
in
2015
I
think
I
started
using
I
can't
remember
the
year.
I
started
to
use
it
for,
for
a
previous
startup
I
was
at
usually
with
2013
2014
I,
don't
think
it
thought
was
a
company
and
it
was
just
an
open
source
project
that
sin
had
started.
F
F
The
Ruby
staff
is
a
definitely
is
a
completely
foreign
language
to
me,
but
it's
just
amazing
to
be
able
to
see
the
openness
that
you
guys
how
you
interact
with
the
community
when
we
have
feature
requests
we're
now
like
an
ultimate
customer.
So
we
pay
you
guys
lots
of
money
for
it,
but
even
before
that
that
we're
able
to
get
put
in
feature
requests
were
able
to
comment
on
stuff
we're
able
to
see
the
visibility
on
why
you're
prioritizing
different
features
and
be
able
to
say
maybe
maybe
this
isn't.
F
This
is
something
you
should
be
putting
a
higher
priority
on.
Maybe
this
doesn't
fit
your
priorities
for
how
you
define
different
tiers.
It's
amazing
to
see
the
feedback
when
something's
premium,
and
you
see
the
community
members
say.
Maybe
this
shouldn't
be
in
your
premium
category
and
it
goes
back
down
to
community
because
you
guys
realize
the
community's
right,
it's
unbelievable
or
even
when
the
community
develops
features
that
you
were
planning
on
putting
in
premium
but
because
the
community
develop
it.
A
F
Over
the
past
year
or
so
we've
we
used
to
measure
velocity
very
very
carefully,
and
it
was
always
really
hard
to
improve
velocity,
because
you
try
to
do
something
and
the
last
day
is
really
the
output
of
many
other
metrics.
So
we've
moved
over
to
I
can't
even
remember
the
name
of
the
book,
but
there's
one
book
that
gave
four
metrics
that
we
should
be
measuring.
One
of
them
was
was
a
change.
Failure
rate
mean
time
to
recovery.
Those
are
two
of
them
MTTR
and
CFR.
F
Another
one
is
the
size
of
each
change,
trying
to
remember
the
acronym
for
it.
But
how
big
is
each
emerge
request
or
how
big
is
each
push
to
production
and
the
last
one
is
the
lead
time
how
long
from
the
time
you
start
developing
a
feature
until
it's
on
production
and
those
are
what
we've
been
measuring
and
we're
we've
started
to
measure
this
using
get
low.
You
have
a
future
cycle
analytics.
F
We
actually
built
that
stuff
internally,
instead
of
using
your
psychedelics
just
so
we
could
get
the
metrics
exactly
the
way
once
and
no
one
could
say
that
it's
not
true,
so
it
we
have
all
the
metrics
being
calculated
internally
and
yet
lab
has
really
really
really
helped
us
move
those
numbers
being
able
to
have
the
merge
request.
Having
our
test
results
sitting
in
the
merge
request
to
be
able
to
see
what
failed,
what
didn't
fail?
The
security
review,
the
performance,
the
the
performance
test,
the
code
climate,
everything
they're
just
on
the
merge
request.
It's
amazing!
F
What
do
you
guys
that
have
done
with
Auto
DevOps,
with
just
a
few
lines
in
our
in
our
gate,
lab
CI
file,
and
it's
really
helped
us
be
able
to
shorten
our
short
in
the
lead
time,
which
has
really
affected
every
single
one
of
those
other
metrics.
It
means
that
we're
having
some
are
we're,
having
more
pushes
to
production,
we're
having
smaller,
pushes
toward
actually
moving
more
of
them
we're
having
fewer
failures
in
production,
because
we
have
ways
to
test
the
application.
F
A
F
Reviews
that
feature
like
we're
building
like
that's,
we
have
a
sprint
starting
next
week.
That's
one
of
the
top
features
on
the
sprint
to
get
that
in
there
just
be
able
to
close
this
cycle,
to
be
able
to
get
things
done
before
it
gets
to
production
and
to
do
it
very
fast.
It's
get
lab
has
really
really
helped
us
with
that
awesome.
A
A
Thank
you
so
much
for
spending
some
time
in
your
afternoon
to
join
us.
I,
love
hearing
your
stories
about
what
people
are
doing
and
the
stories
from
people
in
the
in
the
front
lines
of
actually
building
and
doing
software
and
using
it
Labs
is,
is
really
it
motivates
me
so
much
more
of
what
we
do.
Thank
you
so
much
so
with
that
Emily
is
going
to
help
us
facilitate
our
next.
Our
next
stop
in
this
livestream
is.
We
have
time
set
aside
for
a
may,
was
Sid
Emily
and
Syd?
B
G
Yes,
and
no
so
if
you're
talking
about
do
we
are
we
gonna,
go
hands-on,
compete
with
github
try
to
move
everyone
over,
probably
not
not
today,
more
social
I
would
love
a
better
explore
page
in
get
get
lab.
I
think
that
that
one
is
not
looking
as
good
as
it
should
be,
we're
open
to
ways
to
make
it
more
social.
We
got
some
companies
using
get
labid
over
10,000
people.
They
wanted
to
be
more
social.
We
kept
Debian
and
KDE
using
get
laughs.
G
They
want
it
to
be
more
social,
so
we're
definitely
open
to
changes
and
fixes
there.
One
thing
we've
been
discussing
today
is:
maybe
make
it
more
social,
where
there's
a
way
to
message.
The
company
directly
from
gitlab
so
use
a
technology
like,
for
example,
send
bird
to
to
make
it
easy
to
chat
with
people
inside
the
company
and
open
up
a
communication
channel
that
way,
so
that
those
are
a
few
of
those
social
changes
who
are
discussing.
G
G
That
is
a
sign
that
it's
not
usable
by
anybody
else
and
we've
seen
again
and
again
that
until
we
use
it
ourselves,
there's
just
scores
of
bugs
that
we
we
should
be
able
to
prevent
we've
seen
that
when
we
use
get
lab
geo
to
transfer,
get
lap
from
Azure
to
DCP
I
think
we
found
20,
maybe
the
40
different
books
that
we
solved
and
that
way
our
customers
don't
have
to
find
out.
We
saw
it
again
when
we
were
now
using
elasticsearch
ourselves.
G
We
found
well
these
seven,
maybe
even
10
bucks,
huge
performance
problems
that
were
there
that
we
only
solve
now
and
we're
seeing
it
with
products
that
we
don't
use.
For
example,
we
don't
use
our
own
monitoring,
we
use
something
we
use
go
fana
which
is
awesome,
but
because
we're
not
using
our
own
metrics.
That
meant
that
product
doesn't
make
sure
it
as
well
as
it
should
and
I
knew
of
very
few
customers.
That
are
using
that.
G
That's
because
we
haven't
kind
of
taken
away,
all
the
bugs
that
we
should
have
ourselves
so
we're
getting
all
the
teams
and
get
lab
to
recognize
that
look.
We
have
to
use
it
ourselves
and
that
doesn't
mean
an
API
integration
that
doesn't
mean
about
integration.
That
means
actually
having
it
in
the
product
as
we
ship
it
to
customers
using
that
exact
same
way,
using
the
defaults
and
get
loud.
If
it's
not
usable
for
us,
then
then
it's
probably
not
going
to
be
useful
for
other
people.
B
G
For
now
all
the
analytics
and
get
lab
cycle
analytics
and
DevOps
scores
and
insights
and
contributing
metrics
those
are
things
we
make
outside
of
Montano.
You
get
why
we
use
something
called
a
charts
to
make
them.
We
have
no
plans
to
integrate
Milano
we'd
get
laugh
at
this
moment.
Ml
tano
is
a
separate
product
for
the
data
lifecycle
mostly
used
for
getting
all
the
way
from
an
API
to
a
dashboard,
it's
written
in
Python
and
it's
aimed
at
a
different
audience.
G
So
no
plans
to
integrate
for
now
predictive
analytics
I
think
are
gonna,
be
a
huge
part
of
gitlab
I.
Think
there's
a
lot
that
kind
of
machine
learning
can
do
already
exciting
things
to
think
about
it.
For
example,
if
you
submit
code
to
get
one,
maybe
we
can
already
tell
you
how
likely
that
code
is
to
fail.
They
sound
like
what
part
of
the
code
base
that
we
changed
by
foo.
How
long?
How
much
time
did
they
spend
on
it?
Who
reviewed
it?
How
long
did
the
read
you
take?
G
How
many
comments
were
there
cetera,
and
that
is
like
probably
ten
other
factors
we
can
probably
predict.
How
likely
is
that
code
is
to
cause
an
outage,
can
also
predict
labels
like
which
the
labels-
should,
you
probably
add
so,
instead
of
giving
you
a
list
of
all
labels,
give
a
few
suggestions
for
people
or
maybe
add
the
ones
you're
pretty
sure
about
there's
many
more
things
we
can
do.
We
now
run
all
the
get
lab
tests.
Every
time
we
push
a
bit
of
code.
Does
it
make
sense?
G
B
G
There's
always
a
balance
between
like,
but
do
we
monetize
and
what
don't
we
monetize
I
think
for
security.
That's
actually
being
a
topic
yesterday
between
me
and
Michael
McBride,
because
one
of
our
promise
is
that
if
one
thing
in
every
stage
is
open-source
and
that's
not
the
case
for
secure
and
we
can
wiggle
out
of
them
and
say
well,
it's
all
part
of
the
DevOps
lifecycle.
G
It's
separate
but
I
think
legged
I
understand
that
promise
to
be
like
every
stage,
every
stage
that
is
on
on
our
homepage,
so
we
should
open
source
at
least
one
thing
there
and
we
discussed
yesterday
and
we
think
the
thing
most
useful
to
people
is
dependency
scanning,
so
we're
thinking
about
making
that
open
source.
One
thing
we're
still
considering
is
like
how
how
to
give
kind
of
access
to
that
data.
If
you
have
the
self
managed
to
get
live,
you
still
need
kind
of
the
data
store
of
like
who
else
like.
G
Who
is
what
what
are
the
vulnerabilities,
so
you
probably
will
need
to
create
some
kind
of
an
API
T
and
we're
probably
gonna
kind
of
collect
email
addresses
and
make
sure
that
we
have
a
bit
more
visibility.
What's
happening,
we'd
get
lab
downstream
one
of
the
major
problems.
It
might
be
a
bit
of
an
exchange.
B
G
Thanks
for
that
so
far,
the
kubernetes
integrations
have
been
a
huge
success
and
good
love
is
now
the
most
common
way
to
deploy
to
kubernetes,
but
we
can.
We
can
always
do
better.
One
of
the
ways
we
can
do
better
is
making
it
easy
to
create
a
cluster
right
now
you
can
create
a
cluster
on
tcp,
but
we
want
that
troll.
The
other
cloud
platforms.
G
You
can
already
add
any
cluster
to
get
lab
by
the
way,
and
we
just
improved
that
in
12
thought.
Oh,
it
automatically
checking
kind
of
the
credentials.
You
also
want
to
make
sure
it's
kind
of
usable.
However,
you
use
kubernetes
so
making
sure
we
set
the
permissions
in
the
correct
way,
making
sure
it's
super
easy
to
kind
of
deploy.
Things
like
crew
key
is
to
get
metrics
out
of
your
applications,
kind
of
making
it
very
easy.
You
just
push
your
code
and
get
letters.
G
The
right
thing
by
default,
I
think
it's
going
to
be
a
continuing
thing.
It's
pretty
cool
to
see
how
fast
we
were
able
to
do
server
list
and
that's
already
kind
of
quite
usable
in
30
minutes
you
can
get
set
up
with
servers
on
top
of
kubernetes
use
and
get
loud.
We
won't
get
loud
to
become
kind
of
the
default
thing
you
use
in
conjunction
with
kubernetes
to
do
older.
They
had
the
busy
work
for
you
in
order
to
deploy
your
apps
and
scale
them
and
progressively
deliver
them.
B
G
G
Until
now,
we've
relied
on
kind
of
managed
services
to
do
that,
and
so
we
assume,
when
you
deploy
your
app
with
all
our
DevOps,
that
you're
for
things
you
want
to
retain
like
a
database
that
you
use
something
like
a
cloud
serve
is
like
RDS
or
you
run
your
own
database
I
think
we
have
to
get
a
bit
better
at
that
we're
seeing
with
kubernetes
operators
that
it's
more
possible
more
and
more
to
use
kind
of
those
operators
to
for
the
stateful
services.
We
should
probably
start
thinking
about
that
Marc.
G
So
yeah
interesting
a
very
open
to
to
discussing
that,
and-
and
we
look,
if
you
have
a
contribution-
I
think
that's
are
pretty
interesting
in
order
to
do
more
of
that.
Also
I
think
we
need
better
strategies,
for
example,
for
testing
rollback
procedures.
I
know
a
lot
of
companies
that
want
to
see
a
rollback
before
they
even
deploy
something
to
production.
I
think
that
should
be
almost
like
part
of
our
default
pipeline
database
change
back
up,
Sandra,
sort
of
testing
things
like
that.
So
that's
another
way
to
improve
our
kubernetes
integration.
B
G
Yeah
I
think
you
can
already
I
think
what
what
was
in
the
twelve,
the
dough
blog
post
was
that
we're
you
to
switching
from
kind
of
using
CMD
the
old
command
line
thing
to
PowerShell.
So
we
should
be
able
to
kind
of
scrape
get
lap
with
PowerShell
to
do
continuous
delivery
and
we're
getting
more
and
more
like
Windows
users.
So
if
there's
something
we
can
improve,
we'd
be
glad
to
hear
it.
I
think
the
the
running
now
supports
Windows
environments
properly
that
took
a
while,
and
we're
really
excited
about
that.
G
Yes,
most
people
don't
know
that
there's
already
team
performance
metrics
in
get
lab,
so
I
think
it's
contributing,
analytics
or
contributor
analytics
or
you
can
see
of
your
team
like
who's
I
want
the
activity
is
14
memory
and
there's
a
great
way
to
find
out.
If
someone
is
really
stuck
on
something
because
those
numbers
show
up
very
easily,
we
want
to
get
better
at
that.
For
example,
I'd
get
lab.
We
have
we
ever
met.
G
You
can
select
two
options:
I
won't
mind
if
that's
like
20
different
ways
in
which
you
can
view
productivity
all
the
way
from
kind
of
cycle
time
to
mean
time
to
resolution
average
size
from
request
number
of
merger
ly
time
before
you
start
doing
something
I
think
that's
all
things
that
get
lap
shoot
given
we're
adding
more
to
that
also
trying
to
improve
cycle
time
and
the
devil
scored.
And
then
we
will
not
rest
before
we
have
things
like
value
stream,
mapping,
insight,
get
maps.
G
In
the
same
query,
is
cluster
I
think
you
can
I
hope
we
said
set
them
up
right
by
default
so
that
the
runners
get
evicted
from
the
cluster
is
get
lap
is
getting
affected,
but
I
think
that's
the
case
and
I
think
there's
a
button
link
at
lab
to
deploy
to
the
runner.
So
it's
a
so
called
get
LAN
managed
application,
so
should
certainly
be
be
possible.
C
B
A
G
I
we're
here
at
the
DevOps
DevOps
summit
in
London.
It's
been
great
hearing
everyone
using
get
lap
and
it's
great
to
see
like
a
couple
years
ago.
We
did
this
version
control
we
added
CI
and
now
people
are
using
get
lab
to
deploy
their
applications
and
we're
getting
closer
and
closer
to
delivering
the
full
DevOps
lifecycle.
A
Awesome,
thank
you
so
much
Syd
and
and
that
wraps
up
our
livestream
today,
I
on
behalf
of
the
entire
team
who's
joined
us
I
want
to
reinforce.
You
know
we
believe
everyone
can
contribute
and
that
bringing
these
different
teams
together
we're
better
together
as
a
community,
we're
better
together
building
gitlab
and
thank
you
so
much
for
joining
us.
I
look
forward
to
seeing
all
of
you
in
a
future
event.
Take
care.