►
From YouTube: 2021-01-13 AMA about GitLab releases
Description
AMA with the Delivery team discussing GitLab releases and deployments
A
Hey
everyone
I'll
just
give
a
few
more,
maybe
a
minute
or
so,
and
just
see
if
there's
any
more
people
joining
in
but
good
to
see.
You.
A
A
Fantastic
right
I
get
started
so
welcome
to
this
ama
with
the
delivery
team.
For
those
of
you
who
don't
know
us,
I'm
amy,
I'm
the
engineer
manager
for
the
team
and
we've
also
got
alessio
and
myra
on
the
call
who
are
in
the
team
as
well
and
delivery
are
responsible
for
releasing
all
features
and
bug
fixes
out
to
get
lab.com
and
also
to
our
self-managed
users.
A
So
this
will
be
helpful
in
improving
site
reliability,
but
it
also
gives
us
kind
of
additional
options
on
deployments
as
well.
A
So
at
the
top
of
the
agenda
item
just
highlighted
here,
we've
got
an
issue
which
you
can
kind
of
review,
which
is
our
2020
in
numbers.
So
it
looks
back
over
all
the
things
that
changed
in
the
last
12
months.
Quite
a
lot
actually.
A
So
hopefully
that
gives
you
a
little
bit
of
an
idea
of
the
sort
of
things
we're
working
on
a
bit
of
a
direction
for
us
next
year
as
well.
Well,
this
year,
sorry
as
well!
A
So
as
we
go
through,
if
people
could
help
out
writing
notes,
that
would
be
very
helpful.
Does
anybody
have
a
question
they'd
like
to
start
us
off
with.
A
Or
is
there
something
like,
maybe
what's
the
perhaps,
what's
the
like
least
clear
thing
about
this
team,
that
would
be
helpful.
We
can
maybe
try
and
clear
up
a
little
bit.
A
So
how
about
I
tell
you
a
little
bit
about
this
2020
numbers.
So
last
year
we
made
some
big
changes
to
the
way
we
were
doing
daily
deployments,
and
you
can
really
see
that
reflected
in
the
mttp.
So
early
in
the
year
we
were
around
100
hours
of
mttp.
So
that
means
that
code
that
is
effectively
ready
to
be
used
by
users
is
taking
100
hours
to
actually
reach
those
users
and
through
the
work
the
team
did
over
the
last
year.
We've
got
that
right
down.
A
We
now
have
a
target
of
12
hours,
so
that's
quite
a
big
big
difference,
and
that
means
like
I
say
not
only.
That
features
are
reaching
users
much
earlier,
but
also
it
means
that
if
we
have
bug
fixes
and
things
like
that,
they
can
also
go
out
much
more
quickly.
A
So
that
was
quite
a
big
defining
change,
and
that
was
one
that
also
then
led
us
to
our
next
big
significant
project,
which
was
around
removing
the
blocking
nature
of
security
releases.
So
security
releases
are
super
important
and
have
a
very
special
process
to
to
make
sure
we
don't
release
anything
before
we
should,
but
by
their
nature
it
meant
that
they
also
impacted
on
our
daily
gitlab.com
deployments
much
more
than
we
wanted
them
to.
A
So
we
had
a
big
project
running
for
quite
a
lot
of
months,
maybe
the
whole
of
last
year,
actually
but
quite
a
lot
of
last
year
to
remove
those-
and
that
was
the
other
big
step
change
for
us
on
mttp.
A
So
those
were
two
quite
exciting
changes
and
as
we
go
through
this
year,
the
big
exciting
changes
will
be
around
progress
through
the
kubernetes
migration,
so
we're
seeing
the
further
through
the
migration
we
go,
the
more
so
the
faster
the
deployments
to
gitlab.com
are
running.
It's
just
it's
faster
to
deploy
to
kubernetes,
so
we'll
see
continued
improvements
there
and
then
also
the
next
big
goal
for
us
on
our
mttp
journey
is
enabling
rollbacks.
So
that
would
be
a
big
goal
that
we'll
be
working
towards
as
well.
Throughout
this
year,.
A
Is
there
anything
else
I
can
helpfully
explain
or
answer
or
give
any
more
sort
of
color
around?
That
would
be
interesting
for
people.
B
B
B
So
to
answer
my
own
question,
I
think
it
could
be
deploying
directly
from
master.
So
as
soon
as
I
merge
a
merge
request,
it
would
be
deployed
to
master
so
one
hour.
Mttp
sounds
great.
B
A
Yeah,
both
great
suggestions,
yeah,
I
think
mine-
is
sort
of
a
linkedin
into
those
as
well
like.
I
think
it's
going
to
be
the
auto
rollbacks,
because
I
think
once
we
have
that
safety
net,
then
it
opens
up
quite
a
lot
of
opportunities
for
increasing
the
deployment
window.
A
I
kind
of
imagine
in
my
mind
as
a
as
a
time
where
I
can
come
online
and
actually
the
release
tools
tell
me
like
there
was
a
deploy
and
the
new
stuff
happened.
It
went
out.
There
was
a
problem
detected
before
any
users
saw
it
and
it
rolled
back
to
the
safe
thing.
So
you
kind
of
come
online
and
immediately
have
the
here's
the
task
I
need
to
pick
up,
because
I
mean
it
just
means
that
not
only
will
deployments
be
able
to
go
through
more
frequently.
A
But
you
know
it's
it's
much
closer
to
the
kind
of
fully
automated
approach.
So
I
think
for
me,
that
would
be
the
really
exciting.
A
One,
what
about
anyone
else
like
is
anyone?
Are
there
any
like
changes
that
would
be
helpful
for
engineers
or
like
design
or
anyone
else
who's
on
the
call
like?
What's
what
are
the
kind
of
sort
of
dream
items
for.
A
Cool.
Okay-
that's
great
hello!
I
think
I
suppose
we
also,
interestingly,
are
going
to
expect.
I
think
that
mttp
stays
around
12
hours
for
some
time.
We
have
it
in
our
on
our
handbook
page
that
the
next
time
we
focus
on
changing
the
target
time
will
be
once
we
have
three
months
continuous
achievement
of
the
12
hour
goal,
whilst
also
having
roll
backs
in
place.
C
Yeah,
just
looking
at
to
see
if
there'd
be
a
way
to
get
amazon
linux,
to
support
on
our
main
install
page
and
then
possibly
we
could
do
the
amazon
ami
on
amazon,
linux
2.,
it's
technically
centos
binary
compatible
sent
us
7.
So
I
think
we
have
that
on
the
page.
So
I'm
not
sure
if
we
actually
prepare
that
or
not
or
do
we
do,
we
do
we
test
on
the
centos
7.
I
guess
that's.
I
don't
know
the
answer
to
that.
A
C
Cool
yeah
we're
getting
more
and
more
demand
from
the
amazon
community
and
amazon
continues
to
improve
a
lot
of
optimizations
in
in
their
version
of
centos.
Seven.
A
Okay,
yeah,
that's
interesting,
well,
yeah,
I'll
I'll,
ask
over
in
distribution
and
see
if
we
can
get
you
an
answer
for
that.
A
Cool
excellent:
are
there
any
other
questions.
D
Yeah,
I
actually
have
a
question
sorry
about
the
background
noise.
It's
my
time
here
so
with
frequent
deployments
to
production,
how
is
delivery
ensuring
that
production
stays
stable
because
the
more
frequent
we
deploy,
the
more
we'll
probably
be,
maybe
requiring
rollbacks
or
we're
seeing
issues
that
we
would
see
less
frequently
for
deploying
this
less
frequently.
E
Want
me
to
take
this
yeah
sure,
yeah,
so
great
question
thanks
for
asking,
so
there
is
first
of
all,
there's
also
the
cons.
We
also
have
to
consider
that
when
we
release
with
more
frequents
like
like
we're
doing
now,
we
release
less
changes,
so
it's
easier
to
test
them
to
detect,
identify
a
problem
and
eventually
roll
back
or
roll
forward,
just
removing
that.
So
what
is
actually
what
we
are
actually
doing
to
prevent
this
is
is
this
so
we
added
new
metrics,
so
we
have
this.
E
We
call
them
deployment
metrics,
which
are
based
on
error
rate
and
the
our
slo,
so
the
abducts
in
our
application,
so,
instead
of
using
the
same
accuracy
that
we
are
using
for
paging
on
calls,
we
we
are
our
metrics
are
more
sensible
sensitive.
So
what
happens
is
that
we
deploy
to
to
staging
first,
then
we
run
a
qa
on
it
and
when
qa
completes
we
start
rolling
out
to
canary
on
canary,
we
run
qa
again
and
we
keep
checking
those
numbers.
E
So
after
that
point
in
time,
we
have
a
baking
time
of
one
hour
where
we
keep
monitoring
those
numbers.
And
if
everything
is
fine
and
there
are
no
active
incident,
then
a
risk
manager
promotes
the
build
to
production
and
yeah.
I
can
tell
you
that
it's
actually
working
well
and
having
smaller
change
set
gives
us
more
confidence
in
promoting
things,
and
we
we
ended
up
having
less
incident,
because
there's
also
a
kind
of
psychological
side
effect
here.
D
D
I
have
one
more
question:
does
the
delivery
team
ensure
that
production
is
identical
to
canary
and
staging
and
development
and
the
dev
environment?
Because
if
these
environments
are
not
identical,
then
the
qa
would
pass
and
in
one
of
the
environments
but
then
wouldn't
pass
on
the
other
one?
So
who
is
who
is
doing
that
delivery?
Or
what's
the
deal
with
the
difference
between
the
different
environments.
A
Yeah,
that's
a
fantastic
question,
so
infrastructure
as
a
whole
owns
this
really
as
we're
all
kind
of
responsible.
On
the
whole,
I
mean
they're,
never
fully
identical.
I
suppose
one
of
the
biggest
changes
is
as
we
as
we
deploy
new
services
or
you
know,
continue
through
the
kubernetes
migration.
They
begin
on
the
staging
environments
and
we
sort
of
gradually
roll
them
out
through
the
canary
environment
through
to
production.
So
those
points,
then
the
environments
are
quite
different.
A
So
I
suppose
it's
us
knowing
what
the
differences
are
and
kind
of
making
changes
to
the
environments
carefully.
But
it's
also,
I
suppose,
a
key
part
of
when
we
have
when
we
do
have
incidents
or
near-misses,
where
we
actually
kind
of
consider
was
there
something
here.
A
So
I
think
probably
the
biggest
change
is
not
just
infrastructure
related,
but
we've
over
the
last
few
months
there
have
been
quite
a
lot
of
improvements
to
the
data
that
exists
in
the
databases
on
say,
staging
to
enable
us
database
migrations
to
be
tested
more
effectively,
and
things
like
that
will
often
be
quite
like
corrective
actions
that
come
out
of
incidents
so
that
we
can
actually
bring
these
things
closer
together.
F
Sure
you
just
mentioned
in
the
goals
for
2021
option
three
was
to
change
the
direction
towards
shipping
git
lab
features
instead
of
the
manual
tooling.
That's
kind
of
interesting,
so
I'll
just
provide
some
more
details
on
what
the
the
goal
is
with
that
one.
A
Yes,
thank
you
for
asking.
So
yes,
through
necessity,
at
the
moment
we
run
most
of
our
deployments
and
release
tooling,
is
custom,
built
and
sits
outside
of
the
actual
gitlab
product.
A
So
now
we
have
a
lot
more
features
available
to
us
in
the
product
that
we
can
be
starting
to
move
over
to
and
also
we've
simplified,
a
lot
of
the
deployment
and
release
process.
So
actually
it's
a
little
bit
more
standardized
than
it
used
to
be
so
the
goal
is
the
end
goal
is
to
have
our
deployments
entirely
running
from
within
the
gitlab
product.
A
There
are
a
few
things
that
are
very
unique
to
gitlab,
so
we'll
like
be
moving
towards
those
incrementally,
particularly
the
way
we
handle
security
releases,
but
for
this
year,
what
we're
starting
to
do
what
we
started
last
year,
we're
continuing
through
this
year
is
identifying
features
that
exist
already
that
we
can
be
moving
over
to
so
one
example
is
last
year
we
did
a
big
piece
of
work
to
rewrite
our
release
code
to
use
the
api
which
got
us
a
bit
closer
and
we're
also
currently
doing
work
to
change
the
way
we
generate
change
logs.
A
So
that
it
sits
more
closely
within
the
product
as
well,
so
we're
looking
through
this
year
to
actually
identify
additional
features
that
either
exist,
or
you
know
we
could
be
close
to
getting
so
we're
working
very
closely
with
releases
at
the
moment
on.
How
could
we
move
over
to
the
deploy
freeze
feature
or
how
could
we
adopt
the
rollback
feature
that
already
exists
and
how
we
can,
actually,
you
know,
take
a
bigger
part
in
those
things
as
well.
A
No,
if
not
well,
thank
you
so
much
for
everyone
for
coming
along
and
for
asking
questions
and
yeah
we'll
look
forward
to
seeing
you
all
in
a
bunch
of
time,
cool
thanks
for
everyone.
Bye.