►
From YouTube: 2021-04-14 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
Okay,
so
let's
begin
so
welcome
everyone.
This
is
the
april
14th
ama
with
the
delivery
team.
So
we'll
be
answering
any
questions
you
have
about
get
lab
releases
and
deployments
so
stan.
You
have
the
first
question.
B
Sure
I
was
just
curious.
You
know
you've
been
doing
the
migration
for
a
while
and
I'm
just
curious.
If
there's
anything
that
sticks
out
about
what
surprised
you
about
this
migration
about
kubernetes
and
is
there
anything
you
might
have
done
differently?
Having
known.
C
I'll
try
to
start
a
little
bit.
I
think
what
has
surprised
me
the
most
is
just
the
length
of
time
it
requires
to
do
the
necessary
investigation,
learning
and
application
of
that
knowledge
to
migrate
a
service
into
kubernetes.
C
I
wish
it
was
kind
of
faster.
You
know
I
learned
it's
not.
You
can't
compare
a
virtual
machine
to
kubernetes
pod,
like
apples
to
apples,
they're
significantly
different
ways
that
the
infrastructure
is
running
significantly
different
methods
in
which
the
pods
are
executing
compared
to
the
way
our
applications
execute
inside
of
our
virtual
machines.
C
It's
kind
of
changed
or
we've
been
able
to
take
away
a
lot
of
changes
that
we
need
and
bring
them
into
our
chart
to
introduce
changes
that
better
our
chart
for
the
most
part
but
yeah,
just
the
ability
to
like
learn
our
application
and
figure
out
how
to
best
take
those
and
build
that
same
thing
into
kubernetes
has
been
the
most
difficult
part.
A
Yeah
and
I
think,
from
sort
of
joining
part
way
through
for
me,
it's
been
interesting.
I
think
it's.
The
surprise
is
some
of
the
unknowns,
so
you
know
there
are
definitely
things
which
we
just
can't
anticipate
and
then,
when
we
start
serving
traffic
on
staging,
for
example,
we
suddenly
uncover
a
whole
new
thing.
So
it's
sort
of
tempting
to
feel
like
if
we
sat
down
up
front
and
thought
about
this
we'd
definitely
caught
it,
but
there
are
so
many
things.
A
We
definitely
would
it's
it's
only
when
we
actually
see
how
the
application
runs
on
kubernetes
that
we
we
catch
a
lot
of
these
things.
So
maybe
I
suppose,
my
probably
my
biggest
surprise,
I
suppose,
coming
in
sort
of
part
way
through,
is
just
learning
how
complicated
the
application
is,
because
that's
really
there's
so
many
moving
pieces
and,
like
so
many
aspects
of
this
migration,
it's
certainly
been
a
lot
bigger
than
sort
of
like
previous
ones.
I've
seen.
C
Yeah
I
wish
jarv
was
here
to
answer
this
precise
question,
because
there's
a
lot
of
learning
that
I
need
to
do
just
the
application
stack
in
general.
That
jarv
would
know
a
lot
better
than
I
would,
and
he
probably
saved
me
from
a
lot
of
potential
mistakes
during
the
migration
process,
which
I
greatly
appreciate.
A
A
D
Yeah,
so
everybody
now
knows
jihoo,
so
they
are
going
to
start
building
their
own
releases
from
13
11.
So
basically,
this
upcoming
release
and
moving
forward.
They
will
all
the
releases
themselves.
So
I'm
just
wondering
because
of
the
two
repo
setup
I'm
wondering
if
we
have
any
facilities
for
them
to
automate
the
process
as
much
as
possible.
For
example,
one
challenge
is
like
for
our
security
releases.
We
decided
the
workflow,
is
they
cut
their?
They
cut
their
release
after
we
publish
our
release.
D
So
if
we
can
shorten
that
window,
that
will
certainly
help
to
reduce
the
risks
to
the
jihoo
specific
customers.
D
So
I'm
just
wondering
if
we
have
any
tooling
or
facility
or
any
hooks
available
for
them
to
see
here
is
the
event
trigger
that
they
can
automate
their
process
as
much
as
possible.
I
know
automating,
the
entire
process
may
not
be
feasible,
but
something
is
better
than
nasty.
So
I'm
just
wondering
if
we
have
any
facilities
to
automate
that
or
do
we
consider
to
make
something
available
for
them.
B
D
B
E
B
E
Okay,
now
I
was
going
to
ask
another
question
on
top
of
this,
which
is
do
they
so
what's
their
deployment
schedule,
so
they
are
they're
building
on
top
of
target
release
and
say
they,
I
suppose
they
have
their
own.
I
know
they
have
their
changes
their
their
their
their
own
features.
So
the
idea
is
that
they
pack
things
together
after
we
tag
any
stable
release
and
deploy
it
or
are
they
kind
of
doing
some
something
more
likely
to
our
auto
deploy
so
more
continuous
deployment.
D
Oh
yeah,
so
this
is
more
about
the
self-managed
releases
because
you
know
they
cut
their
self-managed
releases.
They
use
get
to
to
do
their
their
sas
deployment
and
they
the
the
sas
still
not
available
yet,
but
they
plan
to
use
sketch
to
deploy
a
hybrid
environment.
But
this
question
is
more
about
the
self-managed
releases
because
the
patch
and
the
security
releases
they
have
to
wait
until
you
know
the
delivery
cuts
the
release.
E
Okay,
thank
you
for
clarification.
I
wasn't
really
aware
of
this
details,
so
I
think
that
the
so
what
what
we
have
right
now,
which
act
some
in
some
way
of
our
notification
system,
is
our
versions.getlab.com,
which
is
exactly
the
same
thing
that
tells
in
your
instance,
if
needs
to
be
upgraded.
So
maybe
just
because
I
don't
know
the
details
of
how
this
is
implemented.
E
D
I
think
it's
just
some
trigger
or
some
event
notification
that
they
can
grab.
So
that's
a
signal.
Okay.
If
the
code
is
ready,
then
they
can
start
the
downloading
process
or
the
pulling
process
then
crank
the
builds
after
the
poor
start.
F
So
a
building
on
top
of
what
alessia
said.
Every
time
we
publish
a
security
release,
we
immediately
sync
the
canonical
repository
with
the
security
changes,
so
if
they
are
always
pulling
from
this
canonical
repo,
they
should
have
like
the
security
changes
once
they
are
ready
to
be
or
when,
when
they
were
published
and
when
it
comes
to
a
specific
notification,
I
think
we
can
probably
ask
someone
from
security
marketing
because
they
are
the
ones
that
handle
like
emails
and
the
social
media
notification.
So
that
might
be
also
another
idea.
C
Yeah
I
had
this
is
mostly
a
follow-up
question,
because
I
haven't
really
been
paying
attention
to
why
we
have
a
secondary
repo
in
the
first
place.
So
I
was
wondering
if
we
had
an
idea
of
what
kind
of
changes
they
would
ever
need
that
wouldn't
be
included
in
our
main
code
base
repository,
as
is
like.
Is
it
going
to
be
something
specific
to
maybe
their
infrastructure,
or
maybe
there's
like
some
feature
sets
that
may
be
incapable
or
some
do
that
along
those
lines
or
something.
D
Yeah,
I
can
give
a
very
high
level
description,
so
they
are
going
to
contribute
to
rc
and
the
ee
code
base
just
as
a
community
contributor.
So
that's
one
way
to
contribute.
They
also
have
a
jiho
jh
folder,
that's
a
jiho
specific
features
or
implementation.
That's
pretty
much
is
their
all.
D
I
mean
we,
I
don't
know
if
we
are
going
to
put
that
to
into
our
releases,
but
that's
that's
a
very
much
jiho
specific
and,
of
course,
the
though
the
way
it
works
that
they
contribute
as
a
community
contributor.
Then
we
push
back
all
the
changes
from
our
ripple
to
them,
so
they
can
kind
of
release.
That's
a
very
high
level
description
of
the
working
process.
A
And
do
we
do
we
have
somewhere,
where
the
other,
if
there
are
any
requirements
for
additional
work
for
delivery
needs
to
do
like,
is
that
it's
not
something.
D
Don't
I
don't
think
there
is
anything
that
the
deliberative
needs
to
work
on
at
this
moment,
and
my
question
is
basically
if
they
want
to
automate
the
release
process,
what
kind
of
triggers
or
event
notification
they
can
grab?
So
they
can
automate
that
because
they
need
to
pull
the
code
from
our
gitlab
inc,
repo
and
start
building
the
releases.
I.
A
See,
okay,
fantastic
and
just
on
this,
are
they
do
you
know
when
they
might
be
starting
to
automate.
D
No
timeline,
I
just
suggested
them
to
do
the
automation.
I
may
ask
them
to
know
to
reach
out
to
you
or
somebody
on
the
on
the
team
to
figure
out
what
is
possible
at
this
moment
or
what
they
need.
Fantastic,
okay
sounds
good.
Thank.
A
Yes,
thank
you
for
asking.
This
is
our
favorite
topic,
so
you
can
come
again
who
would
like
to
answer
about
rollbacks.
E
Yeah,
I
can
take
this
one
if
yeah,
no
one
else
in
the
same
wants
to
talk
about
it.
Okay,
so
yes,
we
are
dealing
with
rollbacks
at
the
moment,
so
it's
I
think
more
than
one
month
now
that
we
are,
we
have
a
weekly
demo
where
we
are
rolling
back
staging.
So
we
basically,
we
spent
the
last
month
working
on
failure
scenario,
just
to
make
sure
that
we
yeah
polished
all
the
rough
edges
around
things
that
can
go
wrong.
E
So
we
are
at
the
point
where
we
are
planning
to
test
dry,
run
rollback
in
production
and
then,
if
everything
works
as
expected,
we
will
run
our
first
roll
back
in
in
production
environment.
It's
well.
I
don't
know
how
much
details
do
you
want
on
this,
but
it's
kind
of
it's
not
a
generic
rollback,
so
you
can
only
roll
back
one
version
reason
being
there
is
the
problem
with
post
development,
migration
and
basically
we
identified
the
points
of
no
returns
in
the
process
which
are
positive,
climate
migration.
E
So
up
until
post
deployment,
migration
or
if
the
difference
between
the
current
version,
the
previous
one
does
not
include
post-deployment
migration,
then
we
can
roll
back
and
yeah.
This
is
briefly
what
we're
doing
so
we're
not
touching
database.
There
are
no.
We
are
not
ruling
back
any
type
of
migration.
Basically,
we
are
flipping
over
what
we
have
when
we
run
cannery
when
we
have
two
versions
running
at
the
same
time,
and
basically
we
we
will
start
going
backward
and
having
the
same
cannery
situation,
and
then
we
will
just
run
the
old
version
yeah.
E
B
Post
deployment
migrations
now:
is
it
just
a.
B
E
That's
that
was
the
plan
at
the
beginning
of
the
quarter.
Then
we
figure
out
that
we
were
kind
of
yeah.
We
still
have
some
road
to
make
before
reaching
a
working
pipeline,
so
we
just
because
we
started
with
this
idea.
We
will
create
an
assisted
rollback
and
then
an
automated
rollback,
and
we
figure
out
that
we
first
need
a
rollback.
E
So
basically
our
entry
point
was
supposed
to
be
identifying
this
point
of
no
return
and
making
it
with
the
production
checks
that
we
have.
So
if
our
metrics
doesn't
look
good,
we
will
not
run
positive
migration,
but
this
basically
is
yeah.
Not
I
mean
it's
far
away
in
the
future
right
now,
so.
A
And
I
think
the
goal
for
the
next
sort
of
once
we
have
this
pipeline
tested
on
production.
The
goal
will
be
to
start
using
it
because
the
main
benefit
from
rollbacks
is
quick
recovery
from
incidents,
so
the
first
use
case
over
q2
will
be
to
try
and
be
able
to
roll
back
incident
rather
than
needing
to
hot
patch
them.
So
that's
what
we're
working
towards.
F
A
Absolutely
I
mean,
even
in
the
time
I
don't
remember
any
of
those
things
you've
mentioned,
but
even
just
in
the
time
I've
been
here
like
we
have
gone
from
deploying
like
you
just
started
to
playing
once
a
day
just
before
I
joined
and
now
we're
like
frustrated
eric
was
complaining
the
other
month
because
he
only
managed
three
deploys.
He
was
like
really
disappointed.
B
Was
so
thanks
thanks
for
all
the
work
there
yeah?
My
question
is
more
of
a
general
one
and
everyone
I
think
at
gitlab,
probably
has
an
opinion.
So
I
want
to
hear
your
opinion.
There's
one
thing
about
at
least
feature-wise.
You
know
ui
whatever
it
is
that
you
could
have
development
fix.
What
would
that
be.
G
C
B
C
This
is
what's
holding
us
up
from
completing
the
sidekick
migration
into
kubernetes.
Specifically,
the
pages
feature
right
now.
As
soon
as
we
get
that
part
fixed,
we
could
finish
up
the
sidekick
migration
and
we
could
also
migrate.
The
web
servers
themselves
into
kubernetes
as
well
and
that'll
be
very
exciting,
because
that
those
are
those
will
be
our
last
few
stateless
services
that
are
preventing
us
from
completing
that
okr.
A
E
E
Everything
to
kubernetes
so
it's
I
know
six
engineers
whatever
compared
to
the
rest
of
the
organization,
at
least
the
engineering
department,
shipping
new
features
that
sometimes
add
new
things
written
on
disk,
instead
of
object,
storage
or
not
properly,
working
in
a
distributed
environment
without
sharing
storage,
or
things
like
that.
So
this.
F
Also
broken
master,
this
is
probably
not
a
gitlab
feature,
but
now
that
we
rely
more
and
more
on
having
master
having
a
green
master
to
you
know
create
the
auto
deploy
branches
create
a
package
when
it
is
red,
it
is
actually
blocking
us,
so
perhaps
having
a
more
faster
broken
master
process
will
be
very,
very
helpful
for
us.
B
Yeah,
that's
a
good
point
like
now
that
actually
impacts
your
deploys.
It
needs
to
be
at
least
the
signal
needs
to
be
boosted
a
lot
louder.
Now
I
think,
right
before
it
was
just
an
inconvenience.
People
were
like.
I
can't
merge
for
a
couple
hours,
but
now
it's
actually
impeding
other
things.
A
Yeah,
I
agree,
mine
is
sort
of
I
guess
related,
but
not
really
a
feature,
but
it's
very
much
about
the
amount
of
I
suppose
the
amount,
the
number
of
pieces
inside
the
pipeline
so
like
the
amount
of
testing
and
sort
of
feature
flags
and
all
the
things
that
take
place
on
staging
needing
to
be
part
of
the
deployment
pipeline.
Like
I'd
love
all
of
those
things
to
be
able
to
happen
outside
of
the
deployment
pipeline.
A
I
think
the
dream
is
like:
there
was
a
article
recently
I
read,
and
it
was
about
deploying
to
you
to
be
able
to
deploy
to
changes
to
production
in
10
minutes.
So
that's
the
new
goal.
A
A
Fantastic,
so
thanks
for
all
the
great
questions
we
have
a
few
minutes
left.
If
anyone
would
like
to
ask
anything
else,.
A
Nope,
fantastic
thanks
so
much
everyone
for
joining
us
today
and
for
the
questions
super
selection
of
questions.
So
thanks
very
much
for
those
and
yeah
we'll
hope
to
see
you
next
month
to
share
more
more
of
things,
we're
up
to
thanks
very
much.
Everyone.