►
From YouTube: 2020-09-09 AMA about GitLab releases
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Oh
hello,
everyone!
So
thanks
for
joining
us
for
our
september
ama
releases
and
deployments.
So
don't
have
any
questions
in
the
agenda
at
the
moment,
but
is
there
anything
anybody
would
like
to
ask
us
about
or
or
hear
about
or
anything
like.
B
B
D
No
please
go
on.
Thank
you.
B
Yeah,
I
have
a
generic
question
about
deployments.
I've
been
reading
a
lot
more
about
it,
but
I'm
still
newer
in
the
organization
I'm
curious
as
to
how
much
the
terraform
integration
matters
in
terms
of
structuring
customer
deals.
A
That's
a
great
question
and
not
one,
I
know
the
answer
to
draft.
You
know.
C
Yeah,
as
far
as
I
know,
there
aren't
that
many
customers
that
are
using
it.
Yet
I
mean
based
on
the
data
that
I've
seen,
because
we
this
is
backed
with
object,
storage
and
it
just
doesn't
look
like
it's
a
popular
feature.
Yet
we
aren't
using
it
internally
or
dog.
Food
is,
as
far
as
I
know,
either,
but
it's
something
that
we've
been
looking
into.
B
So
if
they're,
not
using
our
terraform
integration,
are
people
just
stopping
at
the
end
of
the
ci
functionality
at
gitlab
are?
Is
it
like
they're,
using
the
script
field
in
your
gitlab
ci.emo
to
like
invoke
ansible
and
then
deploy
using
that
or
something
like
that
like?
So?
How
are
people
using
deployments
in
the
absence
of
terraform,
then.
C
Sure
yeah,
so
we
do
use
terraform
internally
and
the
way
that
we,
how
it
like
links
to
our
deployments
is
that
we
have
two
pipelines,
one
for
deployment
and
one
for
like
provisioning
infrastructure.
So
we
have
a
terraform
pipeline
that
provisions
infrastructure.
It
doesn't
use
the
terraform
integration
of
gitlab,
it's
just
basically
because
it
was
built
before
that
was
available
it
just
it's
just
a
ci
pipeline
that
runs
terraform.
You
know,
terraform
plan
terraform
apply
and
then
after
the
infrastructure
is
provisioned,
then
we
deploy
to
it
separately
using
either.
B
Yeah
thanks
for
that
clarity,
I
I
think
I
could
I
didn't
speak
like
I
could
have
cleared
up
my
question.
I'm
wondering
that
if
people
aren't
using
the
terraform
integration,
are
they
not
using
gitlab
for
deploys,
are?
Are
they
just
like
you
know,
building
out
their
own
stuff,
using
like
the
script
parameter.
C
I
assume
the
latter,
like,
I
assume
that
people
are
using
gitlab
for
deploy
it's
just
like
we're
using
it
for
deploys,
but
they're,
just
using
the
flexibility
of
you
know,
ci
within
gitlab
to
define
their
own
pipeline
a
deploy
pipeline.
That
just
does
whatever
needs
to
be
done.
That
could
be
running
terraform,
it
could
be
invoking.
Ansible
could
be
running
home.
B
C
If
the
like,
how
many
customers
have
applications
run
on
kubernetes,
I
assume,
like
a
lot
of
people,
are
running
their
applications
on
kubernetes.
I
don't
think
a
lot
of
people
are
using
the
integration
to
kubernetes
just
because
it
doesn't,
it
doesn't
offer
a
lot
of
people,
the
flexibility
that
they
need.
I
think
they're
like
a
lot
of
outstanding
issues
with
regard
to
that,
but
as
far
as
customers
using
kubernetes,
I
don't,
we
don't
really
have
a
good
way
of
tracking
that,
like
we'd,
have
to
inspect
everyone's
ci
pipeline
to
see.
A
And
just
to
probably
add
a
little
bit
more
context
for
you
as
well
on
christopher,
like
so
one
interesting
thing
at
the
moment.
In
the
way
we
have
in
gitlab
is
delivery,
is
our
sort
of
remit
is
around
releasing
of
gitlab,
and
at
the
moment
we
do
quite
a
lot
of
that
with
sort
of
self-built
tooling.
A
Part
of
that
is
the
complexity
of
of
how
gitlab
is
and
how
the
releases
need
to
work.
So
a
sort
of
like
future
goal
will
be
to
build
all
that
or
to
work
with
the
releases
team
to
actually
build
this
stuff
into
the
gitlab
product.
So
actually,
at
the
moment,
quite
a
lot
of
the
tools
we
use
to
release
git
lab
and
not
in
the
product,
so
hopefully
in
the
future,
they'll
converge
together.
A
Cool
and
thanks
very
much
for
for
asking
the
question
felipe.
D
Yeah
thanks.
I
was
wondering
if
there
was
any
big
change
inside
anything
that
would
affect
walk
floors
or
anything
that
you
should
anticipate
and
I'm
sorry
if
it
has
been
shared
already
somewhere
in
the
links
over
there
lazy
here.
A
No,
that's
great,
thank
you
so
much
for
asking
so
within
delivery.
We've
got
loads
of
stuff
going
on
that
we're
very
excited
about.
So
we've
got
obviously
the
kubernetes
migration,
which
is
exciting
from
a
kind
of
git
lab
point
of
view.
It
will
be
exciting
for
customers
once
we've
got
things
up
and
running,
that's
kind
of
the
point
of
doing
the
work,
and
it
also
gives
us
great
benefits
from
sort
of
like
a
release
perspective
as
well
and
sort
of
site
stability
on
the
releases
side
at
the
moment.
A
We're
working
on
two
things
that
are
really
exciting
for
us,
so
one
is
around
security
releases
and
we've
made
sort
of
recent
lots
of
sort
of
improvements
to
the
way
the
process
around
how
we
like
create
these
security
releases
and
how
we
can
do
that
alongside
deploying
to
gitlab.com
so
making
great
progress
there,
which
is
very
exciting
to
us,
and
also
we
see
great
benefits
there
right.
A
It's
a
little
bit
more
invisible
say
to
customers,
but
where
you
end
up
with
gitlab.com
being
much
more
secure
than
it
previously
was
we're
able
to
get
security
vulnerabilities
fixed
out
much
more
quickly,
which
is
exciting
and
we're
also
at
the
moment
working
on
something
which
called
assisted
deployment.
So
we
have
a
couple
of
steps
in
our
daily
deployment
process
where
we
make
like
manual
decisions
and
we're
putting
in
automation
to
remove
that.
So
it
becomes
much
more
reliable,
we'll
be
using
a
lot
more
metrics
and
sort
of
system.
A
Health
checks
to
actually
assess.
Whether
now
is
a
good
time
to
do
a
deployment,
and
is
this
particular
build
a
good
one
to
be
pushing
out
to
production.
So
once
we
have
that
stuff
in
place,
that
will
also
be
the
sort
of
time
when
we
can
begin
speeding
things
up,
so
we're
releasing
pretty
frequently.
So
gitlab.com
is
picking
like
it's
getting,
maybe
two
or
three
deployments
a
day,
but
we
really
need
to
have
more
automation
in
place
to
make
that
much
faster
and
safer
as
well.
A
So
all
of
that
stuff's
in
progress,
which
should
be
pretty
exciting
and
it
means
that
we're
well
on
track
for
later
this
year,
increasing
the
number
of
deployments
we
can
do
each
day
as
well.
A
D
We
have
improved
a
lot
of
the
release
process,
especially
when
it
comes
to
security.
Is
there
anything
else
that
that
that
is
remaining
to
improve?
You
know
I
mean:
do
we
still
have
some
roadblocks?
I
understand
that
we
improved
a
lot
of
the
process
and
it's
a
lot
faster
than
it
used
to
be,
but
is
there
a
next
step
to
that?
That's
my
question.
A
Yeah
absolutely
yeah.
We've
made
huge
progress,
so
I
think
we
still
have
quite
a
lot
of
things
that
we
want
to
improve.
So
at
the
moment
we
have
been
validating
kind
of
the
approach
and
we
have
several
different
types
of
deployment
that
we
do
so
we
have
like
daily
deployments,
which
are
the
sort
of
we
call
them
auto
deploys
to
gitlab.com.
A
We
have
quite
a
lot
of
tooling
and
validation
around
those.
We
also
do
the
monthly
release
on
the
22nd
tour
of
self-hosted
customers,
and
we
have
security
releases
and
patch
releases
around
those,
so
we're
making
huge
progress
on
all
of
these,
but
we're
certainly
by
no
means
do.
A
We
have
like
all
the
tooling
and
automated
sort
of
checks
in
place
around
all
of
those
different
releases,
so
the
release
managers
still
have
quite
a
involved
job
of
there's
tools
to
do
most
the
steps
for
each
of
those
releases,
but
it's
very
manual
process
to
make
the
decision
points
around
them,
coordinate
them
and
you
know,
make
sure
we're
doing
things
in
the
right
place
and,
as
I
mentioned,
like
an
awful
lot
of
this
stuff
still
happens
outside
of
the
product.
A
So
we're
working
closely
with
releases
to
actually
also
find
ways
that
we
can
like.
Ideally,
we
build
a
lot
of
this
tooling
into
gitlab,
so
that
customers
can
also
benefit
from
from
these
the
same
tools.
So
we've
got
lots
of
work
going
on
there
in
terms
of
actually
releasing
things
and
then
the
other
side
is
about
making
it
safer.
So
at
the
moment
we
push
things
out
to
production
and
particularly
on
the
auto
deploy
side.
At
the
moment,
we
we're
looking
at.
A
We
push
things
out
and
we
rely
on
usually
it's
the
sre
on
call
or
other
people
to
identify
like
keep
an
eye
on
metrics
and
spot
when
things
aren't
going
well,
that
should
all
be
automated
right,
so
we
should
have
safer
checks
in
place
to
know
this
deployment
like
gradually
roll
it
out,
be
monitoring
the
system
and
know
when
we
should
stop
out
of
when
we
should
roll
that
back
to
make
the
site
more
stable
so
that
stuff's
in
progress
and
actually
alessia.
E
Sure
I
mean
so
basically
what
we
have
in
place
at
the
moment-
and
we
are
kind
of
testing-
is
this
new
metrics.
So
basically
we
have
metrics
at
the
moment
they
are
the
one
that
are
paging
our
own
calls.
They
are
designed
for
not
waking
up
people
in
at
night,
but
what
we
want
is
more
sensitive
metrics
that
just
prevent
an
automated
deployment
to
start.
E
If
the
system
is
not,
let's
see
close
to
perfect
so
right
now
we
are
kind
of
validating
this
matrix
and
we
are
adding
this
on
top
of
our
automated
checks
for
it's
still
a
manual
promotion,
but
it
will
also
add
this
check
and
then
we
will
start
moving
toward
more
automation
around
this.
So
we
will
add
baking
time
to
our
cannery
deployment
so
that,
let's
say
after
one
hour
of
release
running
on
cannery.
If
the
system
is
okay
and
also
the
new
metrics
are
okay,
we
can
start
rolling
out
the
deployment.
E
So
the
basic
idea
is
that
what
we
want
to
do
is
having
hands
off
deployment
and
notifying
people
involved.
If
something
goes
wrong
instead
of
just
having
to
babysit
pipeline.
Because
what
we're
doing
right
now
is,
we
have
to
closely
check
everything
and
make
sure
that
the
system
is
behaving
correctly,
and
we
want
this.
The
system
to
self-check
and
just
involve
people
when
it's
when
they
are
needed.