►
From YouTube: 2020-11-11 AMA about GitLab releases
Description
The Delivery team answers questions about the GitLab deployment and release process
B
A
A
Okay,
I'll
get
started.
Welcome
thanks
everyone
for
joining
this
is
the
ask
me
anything
from
the
delivery
team.
So
we
spend
our
time
making
sure
we
can
deploy
and
release
to
get
abusers
and
building
up
tooling
and
processes
around
that
and
where
possible,
also
like
dog
fooding
as
much
as
that
in
the
product
and
building
it
out
so
get
up.
Users
can
have
the
same
experience
as
us,
so
I
am
amy
phillips,
I'm
an
engineer
manager.
A
A
C
C
I'll
go
first
of
all
having
been
here
for
ages,
it's
so
much
better
than
when
I
started,
and
I
just
want
to
either
praise
that
every
time
I
can,
but
at
my
at
my
last
job,
the
deploy
process
was
always
really
painful.
We
kind
of
in
a
similar
way
generated
a
debian
package
and
sent
it
out
to
serve
a
bunch
of
servers
at
that
place.
C
A
D
D
We
deployed
the
back
end,
which
is
a
big
java
monolith
for
the
most
part
that
we
were
breaking
apart
slowly
daily,
but
then
a
decision
we
made
as
the
application
evolved
in
architecture
was
that
the
big
java
back-end
originally
was
more
like
a
struts
app
where
again,
a
lot
of
rendering
was
done,
server-side
and
then
we
realized
the
power
of
the
rest.
Api
was
the
main
thing
and
I
know
you
know
rust
versus
graphql,
I'm
not
going
to
get
into
that.
I
don't
want
to
deal
with
it.
D
That's
that's
not
the
point,
but
if
we're
architecturally
moving
in
a
similar
direction,
a
direction
we
ended
up
moving
when
I
saw
the
last
place
was
we
said.
Okay,
great,
you
know
the
monolith
on
the
back
end
across
all.
The
servers
is
an
effortful
thing
to
deploy,
but
we
had
people
on
the
front
end
that
wanted
to
iterate
faster.
So
we
decoupled
the
ui
from
the
back
end
since
the
back
end
was
really
becoming
effectively
a
rest
api
and
the
front
end
was
becoming
meaning
to
be
mostly
implemented
in
javascript
and
css.
D
We
then
change
that
so
we
deployed
the
javascript
in
css
five
or
six
times
a
day,
and
I
didn't
know
what
I'd
be
curious
to
know
was
because
we
were
able
to
decouple
that
allowed
us
to
iterate
quickly
on
the
ui
when
we
felt
like
it
was
being
done.
Have
you
heard
any
requests
coming
around
to
my
question
like
trying
to
answer
your
question
and
then
ask
the
question:
have
you
heard
any
requests?
Have
we
thought
about
doing
something
similar.
A
A
That's
a
fantastic
question
and
it's
really
interesting
because
yeah
I've
worked
in
places
in
the
past
which
have
don't
know
if
I've
worked
anywhere.
That's
actually
made
that
move,
but
certainly
it's
been
a
conversation
topic
quite
frequently.
Alessio.
Have
you
come
across
any
of
these
requests
or
do
you
have
any
thoughts
actually.
E
Sure
so
I
was
exactly
thinking
of
this
question.
What
david
was
mentioning
it?
So
I
think
that
so
we
came
from
so
we
have
this
idea
of
the
single
application,
which
is
very
important,
which
kind
of
restrained
us
in
forcing
under
the
coupling
side.
So
I
have
worked
on
projects
outside
of
gitlab,
where
we
were
we
actually
for
having
the
same
situation.
We
actually
introduced
a
backhand
for
front-end
technology,
so
we
had
the
real
end,
which
was
more
stable,
more
mature,
more
monolithical
and
or
even
just
a
composition
of
those
things.
E
E
D
Yeah
exactly
and
that's
why
I
was
asking
the
questions
hypothetically,
I'm
actually
not
advocating
for
that.
I
was
just
trying
to
express
the
difference
to
answer
amy's
question
and
the
the
pressure
we
felt,
and
you
know
again
it
was
that's
where
I
totally
agree.
It
depends
architecturally,
where
you're
going
and
making
a
decision
as
an
engineering
team,
but
what
we've
seen
is:
we've
gotten
them
so
decoupled
that
we
got
to
the
point
that
people
doing
that
front-end
development
and
said,
like
I
just
want
to
move
this
button
down
over
here.
D
Why
do
I
need
to
wait
for
the
back
end
to
deploy
and
the
team
that
I
was
on
at
the
time
on
that
was,
like
you
know,
as
we
talked
to
like,
I
don't
have
a
good
answer
for
you.
We
don't
need
to
deploy
the
java
monolith
to
get
your
change
out,
so
let's
decouple
it
and
that's
where
you
know
what
we've
done
with
gitlab
static
assets
and
the
way
we
actually
architect
the
network
path
to.
D
That
was
the
first
step
in
how
we
did
that,
because
then
we
were
able
to
change
the
deploy
process
of
like
just
go
to
play
this
bucket
for
the
javascript
and
css
version
it
every
time,
and
then
you
know
that
also
gave
us
a
very
quick
rollback
of
if
something
happened
just
on
the
javascript
side
and
we're
like.
Oh,
we.
D
It
was
very
quickly
easy
to
say
all
right.
You
know
just
re-pin
the
back
end
and
reserve
the
javascript
from
the
older
version,
so
it
was
an
interesting
difference
that
I
noticed
like
we
may
want
to
go
that
way.
But
I
appreciate
your
answer
because
that
makes
a
lot
of
sense
of
like
we
have
to
consciously
decide.
That's
what
we
want
and
you're
right
if
we
already
see
the
value,
but
if
we're
getting
there
fast
enough
with
the
way
we're
doing
it,
then
maybe
that's
not
a
problem.
We
need
to
fix.
E
I
want
to
have
something
because
we
were
talking
about
front
and
back
end,
but
we
can
expand
the
same
problem
to
just
component
in
our,
so
we
could
think
about
gisely
versus
workers
versus
everything.
So
what
I'm
thinking
here
is
that
moving
toward
kubernetes
will
give
us
more
freedom
in
this
regard.
Exactly
something
like
this.
So
if
I
change
something
in
italy,
why
should
I
have
to
redeploy
everything?
E
But
when
we
have
virtual
machines
with
omnibus
and
packaging,
there
is
it's
monolithical
at
the
level
of
packaging
right.
So
we
have
a
a
single
package
that
contains
everything,
and
I
mean
it's
a
big
effort
to
to
re-architecture
these
things,
and
I
don't
see
the
a
company
drive
in
that
direction
at
the
moment.
So
probably
we
will
have
it
for
free.
Once
we
completed
the
kubernetes
migration.
D
Yeah,
it
gives
us
a
lot
of
power
if
nothing
else,
to
target
how
we
deploy
first
and
learn,
learn
some
things
about.
Do
we
always
need
to
do
the
web
fleet
first
before
we
do
gitly,
or
you
know
like
if
you're
changing
the
order,
because
we
want
to
understand
the
importance
of
getting
a
hotfix
out.
Those
are
good
things
to
learn.
A
Yeah
absolutely-
and
this
is
interesting
on
the
sort
of
the
front
end
thing
and
how
the
speed
like
one
of
the
ways
I've
seen
previous
places,
handle
that
is
feature
flags
and
like
actually
separating
the
kind
of
visibility
of
changes
from
getting
code
out
to
production.
So
that's
also
another
interesting
one.
D
A
A
I
could
say
that's
a
good
sign
like
great
success.
How
about
sorry,
it's
my
around
the
corner.
Myra.
Do
you
want
to
talk
a
little
bit
about
the
improvements
that
you
have
in
mind
like
we've
made
loads
of
improvements
to
the
security
process,
but
you
want
to
give
a
little
bit
of
a
kind
of
overview
of
some
of
the
other
ones
that
we
we're.
Maybe
gonna
try
and
work
on.
B
B
But
this
causes
a
lot
of
confusions
for
developers,
because
it
is
not
always
clear
what
kind
of
what
release
we
are
targeting
and
what
branch
do
we
need
to
use
and
what
milestone
do
we
need
to
use?
And
if
the
black
person
needs
approvals
so
so
far,
creating
the
backboards
is
a
manual
process
and
well
it
is
time
consuming
also.
B
A
Awesome
thanks
for
that
so
yeah
like
we're
continuing
to
we
spent
time
over
summer,
making
it
so
that
we
could
run
daily
well
more
frequently
auto
deploys
to
gitlab.com
alongside
the
security
ones
and
also
make
the
process
easier.
But
now
we've
kind
of
got
some
other
bits
to
make
it
even
easier.
So
yeah
awesome
thanks
for.