►
From YouTube: 2021-03-10 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
I
will
just
wait
a
minute
or
so
and
let's
anyone
who
is
joining,
join
and
then
we'll.
A
A
Okay,
so
let's
get
started
so
welcome
everyone.
This
is
the
march
ama
with
the
delivery
team,
so
delivery
team
are
responsible.
We
are
deploying
gitlab.com
and
releasing
our
monthly
releases
and
our
patch
releases
and
security
releases
out
to
our
self-managed
users.
A
So
we
have
a
few
questions
in
here
already.
Let
me
just
see
so.
First
one
is
toshitaka,
I'm
not
sure.
If
he's
on
the
call,
no,
I
will
verbalize
so
first
question
is:
I
want
to
understand
how
to
track
the
delivery
and
deployment
for
gitlab.com
generally.
So
there's
a
few
sub
questions
here.
So
on
the
first
one.
Where
can
I
see
the
deployment
job
pipeline
for
this
release
with
a
tag
there?
B
Yep,
thank
you
for
the
question.
So
the
pipeline
is
for
the
deployment
itself
can
be
fined
in
the
can
be
found
in
the
deployer
repo.
But
if
you
want
to
know
where
dmr
has
been
deployed
to
like,
where
is
the
status
of
dmr,
if
it
has
been
deployed
stage
in
canada
production,
there
are
several
ways
to
do
that.
The
first
one
is
to
execute
the
chat
ups
command
on
the
slack.
So
you
execute
that
chat.
B
Ups
command,
you
grab
the
merge,
request,
sha
and
it
is
going
to
say
to
you
like,
okay,
this
merge
request
has
been
deployed
to
staging,
to
canary
or
to
production
depending
the
other.
One
is
to
take
a
look
at
the
environment
section
on
the
mr
widget,
so
that
part
is
updated.
Every
time
dmr
is
deployed
to
an
environment
and
to
also
follow
the
announcement
channel
for
the
updates
about
the
packages
that
are
being
updated
well
deployed
to.
A
Thank
you
cool
and
then
the
second
part
of
this
question
is
the
pipelines
in
gitlab
project
only
execute
delivery,
slash
package
jobs
without
any
deployment,
jobs,
correct.
B
Yeah
yeah,
that
is
correct
pipelines
on
the
gitlab
projects,
do
not
trigger
any
deployments.
They
are
mostly
related
to
the
gitlab
project.
They
execute
tests,
links
q,
a
et
cetera,
et
cetera.
The
deployments
to
gitlab.com
are
mostly
well
not
mostly
are
handled
by
the
deployer
repository
and
by
our
tooling.
That
is
called
the
release
tools.
C
I
can
try
taking
this
myra
okay,
this
well.
There
are
historical
reasons,
obviously
around
this,
so
we
started
with
another.
Yet
another
project
was
take
off.
It
was
basically
changing
stuff
in
chef
server,
so
many
pieces
going
around,
but
the
most
important
bit
here
is
that
we
often
refer
that
gitlab
as
a
we
refer
as
a
single
application,
but
we
have
several
repositories.
C
So
what
we
we
are
used,
some
terms
in
delivery
team
like
project
satellite
projects
and
packages.
So
we
try
to
we
release
those.
We
try
to
synchronize
all
those
things
so
so
the
light
projects
are
workers
github,
shell
gisely,
everything
that
is
not
in
in
gitlab
repo.
Then
we
have
github
repo,
which
is
github,
and
then
we
have
packages
like
helm,
charts,
cng
images
actually
and
omnibus.
So
this
is
why
we
have
these
external
things.
C
A
Fantastic
thanks
for
that
cool.
So
then,
part
c
of
this
question
is
how
does
gitlab
release
tools,
bot
change
the
workflow
label
in
mrs
to
workflow
production
after
changes
are
deployed
to
production
and
myra.
B
The
long
answer
is
that,
after
each
deployment,
whether
it's
to
staging
tannery
or
production,
we
have
a
dedicated
job
that
goes
and
gets
dmrs
that
are
contained
in
a
package
and
updates
updates
those
accordingly.
So
whenever
we
have
a
deployment
to
staging
a
jobs
trigger
the
job,
goes
and
fetches,
or
just
request
the
merch
requests
and
update
each
of
them,
and
the
same
thing
happens
for
canary
and
production.
B
So
I
pointed
out,
I
think
I
pointed
out
the
code,
probably
not,
but
I
can't
link
to
the
code.
If
someone
is
curious
about
it,.
A
Fantastic,
thank
you
and
I'm
gonna
just
add
on
here
a
comment
which
is
that's
the
reason
actually.
So
I
know
sometimes
there's
been
questions
about
why
the
label
is
added
at
like
a
slightly
different
time
to
actually
when
the
code
lands
on
the
server
and
it's
because
it's
a
job
as
part
of
our
pipeline,
so
depending
on
the
length
of
our
pipeline,
it
can
land
actually
depending.
If
we
had
some
very
long
post
deployment
migrations,
it's
possible,
the
label
actually
gets
applied
a
bit
of
time
later.
A
So
it's
just
another
stage
in
the
pipeline
fantastic.
Thank
you
very
much
for
adding
those
questions.
Next
up
arturo.
Thank
you
for
adding
your
question.
Would
you
like
to
verbalize.
D
Yeah
yeah,
thank
you
for
asking
me
anything,
so
my
question
is
similar
to
the
to
the
classic
question
like
what
happened
when
you
type
a
url
in
your
browser.
So
in
this
case
it's
what
happens
when
you
deploy
a
when
we
deploy
gitlab
to
production
and
yeah.
D
C
Sure
I'll
take
this
one
as
a
wrote,
a
lot
of
stuff
here
in
the
agenda.
So
thank
you
for
the
question.
This
is
a
really
good
one,
so
I
would
start
from
high
level
as
you
asked,
and
try
to
give
some
insight
in
other
things
that
may
be
relevant
for
someone
working
on
on
features
or
code
changes.
C
C
So
as
long
as
qa
tests
on
staging
are
green,
we
can
start
cannery
product
economy
deployment
without
any
just
automatically.
We
don't
have
to
any
manual
operation
more
or
less.
It
goes
like
this,
so
we
run
regular
migration.
C
C
So
up
until
here,
everything
is
automated
since
the
starting
of
a
staging
pipeline
staging
deployment
pipeline.
So
it
goes
all
in
one
way.
Unless
something
blocks
us,
then
we
have
one
hour
baking
time,
which
means
that
we
wait
for
one
hour
with
cannery
deployed,
but
the
main
production
stage
we're
running
the
old
version,
and
we
use
this
to
figuring
out.
If
there
are
some
error,
not
catched
by
our
qa
tests.
C
Now
this
is
more
or
less
what
we
do
and
there's
a
micro
review
of
it,
but
I
think
it's
important
also
looking
at
this
from
the
database
point
of
view,
so
I
made
this
little
picture
here.
Maybe
it's
better
if
I
can
share
my
screen
just
for
a
second,
so
it
will
be
also
on
the
recording
would
be
easier
to
so
here
it
is
so.
This
is
a
picture
that
I
made
for
our
rollback
epic.
C
C
We
start
the
cannery
deployment,
which
is
this
is
behind
this
green
bars
here
so,
and
can
I
read
at
certain
point
in
camera
deployment
we
run
regular
migrations
and
the
schema
changes
from
schema
a
to
schema
b
and
then
some
machines,
not
all
of
them,
moves
from
the
old
version
to
the
new
one.
So
here
we
see
machine
a
that
goes
from
version
n
to
version
n
plus
one.
C
If
we
are
unlucky
even
six-
and
this
is
where
things
may
go
wrong,
because
we
have
multiple
version
of
the
same
application
running
at
the
same
time
and
verse
and
there's
a
intermediate
schema
in
there,
because
it's
just
regular
migration,
but
not
possible
by
migration.
So
this
is
where
we
live
as
a
delivery
team.
C
Instead
of
living
in
schema
a
and
schema
c.
This
is
where
say,
the
fun
is
right,
so
things
can
go
wrong
and
things
can
break
and
yeah
there's
an
extra
point
I
wanted
to
make,
but
I
didn't
have
time
to
type
it
there's
also
the
micro
level,
which
is
important
for
people
working
on,
say,
workers
or
things
like
that.
So
what
happens
in
a
single
machine
within
our
deployment,
because
also
in
there
things
doesn't
happen
just
with
a
flipping
switch
right,
so
you
have
old
version
of
workers
old
version
of
code.
C
Then
you
change
the
gitlab
code,
get
workers
code
as
well,
and
then
you
restart
things
so
there
are.
There
could
be
a
point
in
time
where
you
have
a
new
workers
in
the
same
machine
and
an
old
puma
version,
and
then
everything
aligns.
So
that's
the
point
right.
So
what
what
is
interesting
here
is
what
happens
when
version
mismatches-
and
this
always
happens
during
a
deployment.
So
it's
something
to
pay
attention
to.
A
Were
there
any,
do
you
have
any
follow-up
questions
arturo
on
that
one.
D
I
I
like
I,
I
think
I
understand
very
well
like
how
it
works
in
in
yeah,
like
with
a
different
stages
like
a
canary
stay
in
a
production,
but
maybe
we
haven't
talked
about,
for
example,
how
we
deploy
things
like,
for
example,
a
we
are
running
kubernetes.
So
what
are
they?
Do?
You
know
what
are
the
cloud
environment
that
we
are
like
deploying
the
different
things?
Maybe
we
can
go
a
little
bit
more
about
that.
D
C
Easily
is
always
on
vm,
so
we're
talking
about
virtual
machines
running
omnibus
packages.
C
C
The
git
front-end
is
running
on
kubernetes
now,
so
when
I
say
that
we
are
upgrading
the
rest
of
the
fleet,
basically
we
have
several
jobs
and,
depending
on
the
service,
they
either
run
an
ansible
script,
which
just
ssh
into
every
single
machine
and
upgrade
packages
and
restart
packages
and
things
like
reconfigure
and
restart,
or
they
trigger
what
we
call
kate's
workload
pipeline,
which
is
a
project
that
we
have
for
handling
kubernetes
workload.
C
So
in
that
case
we
change
the
images
in
the
configuration
and
we
trigger
a
helm
upgrade
that
will
just
do
yeah
roll
out
of
the
new
version.
So
we
are
in
a
hybrid
state.
A
And
just
to
add
a
little
detail
to
that,
so
yeah
we're
very
much
kind
of
our
other
side
of
our
world.
In
addition
to
deployments
and
releases
is
migratinggitlab.com
over
to
kubernetes,
so
we
will
hopefully
reach
a
point
where
everything
is
on
kubernetes
we're
not
fully
there
yet
so
that
kind
of
adds
some
some
complexity
here.
E
Yes,
thank
you
for
hosting
these.
These
are
really
fun
and
implemented.
So
I
appreciate
it.
What
are
the
things
that
this
team
does?
That
should
really,
from
your
perspective,
from
this
team's
perspective,
be
just
part
of
gitlab
as
a
product
so
that
our
users
and
customers-
and
I
guess
your
team
as
well-
can
just
use
it
off
the
shelf.
A
That's
a
fantastic
question
fits
very
well
with
our
sort
of
strategy,
so
we
are
moving
like
kind
of
historical
reasons,
an
awful
lot
most
of
our
work
is
outside
the
product,
definitely
not
ideal,
and
we've
been
sort
of
moving
towards
that.
It's
definitely
a
strategy
for
us
to
continue
moving
into
the
product
and
I'd
love
to
get
kind
of
everyone
at
delivery's
thoughts
on
their
sort
of
wish
list.
I
think
two
big
ones
that
sit
for
top
of
my
sort
of
list.
A
A
I
know
it's
a
fairly
unusual
use
case,
but
certainly
it's
one
that
certainly
adds
complexity
to
our
day-to-day
and
then
the
second
one
I
have,
which
is
considerably
smaller
and
actually
something
I
was
chatting
to
er
and
releases
this
morning,
so
we're
gonna
see
if
we
can
collaborate
on
this
is
just
making
it
easy
to
actually
keep
track
of
all
the
pieces
of
information.
A
So
for
all
the
steps
that
alessia
just
went
through
before
on
how
we
do
deployments
each
one
of
those
actually
has
quite
a
lot
of
information
associated
like
times
gifs
package
ids
and
all
of
these
things,
and
we
struggle
really
to
know
how
to
quickly
find
all
those
within
delivery
team
like
there
are
times
where
in
an
incident
situation,
we
need
to
quite
quickly
understand
like
what
changed
on
this
server.
A
When
did
it
change
and
what
might
have
caused
a
problem,
and
at
the
moment
we
don't
really
have
a
quick
place
to
jump
to
where
we
can
quickly
find
all
that
information,
so
some
sort
of
deployment
report.
We
were
talking
about
user
user,
readable
deployment
report
that
would
give
us
that
information
would
be
super.
A
C
We
have
also
the
multi-project
triggering
pipeline,
so
we
do
extensive
use
of
triggers
for
because
it's
a
multi-project
thing
right,
so
we
triggered
pipelines
from
one
project
to
the
other
one.
And
since
we
moved
to
oops
instance,
almost
everything
we
use
is
in
that
instance.
So
we
finally
can
use
multi-project
pipeline,
but
we
made
extensive
use
of
waiting
for
the
pipeline
to
be
just
as
a
gating
action.
So
we
trigger
something.
We
need
this
to
be
completed
and
then
we
can
move
on
and
so
far
we
ended
up
using
active
waiting.
C
So
we
have
an
extra
job
that
just
wait
for
they
want
to
finish
because
yeah
there
are
a
bunch
of
issues
in
in
our
multi
project
pipeline.
So
if
something
goes
wrong
and
usually
goes
wrong
in
our
pipeline
because
you
can
have
flaky
qa
or
things
like
that,
there's
no
way
to
retry
or
to
just
continue
for
where
it
breaks.
B
So
I
will
say
the
different
ways
of
handling
releases.
Like
the
monthly
releases,
the
patch
releases,
the
security
releases,
we
have
even
a
different
setup
for
one
of
them.
That
is
the
security
releases.
We
need
to
have
like
a
different
private
project
and
also
for
different
releases.
We
need
to
know
what
merge
requests
were
included
in
the
in
the
type
of
release,
whether
it's
a
patch
release
or
a
monthly
release.
It
will
be
great
to
just
have
a
single
feature
that
could
do
all
of
that
for
us.
A
Yes,
and
maybe
it
is
a
but
yeah
very
much-
we
have
a
strategy
to
move
four
of
our
workflows
inside
the
product
this
year,
and
so
we
will
be
working
with
the
stage
group
stuff.
Hopefully
there
are
features
already
existing
that
we
can
just
pick
up.
There
may
be
some
that
are
close,
that
with
a
small
sort
of
addition
or
extension,
then
we
can
also
pick
those
up
or
other
ones
we'll
be
trying
to
add
into
backlogs
so
yeah
very
excited.
A
F
Sure
yeah
and
I,
as
I'm
writing
this-
I
think
it's
probably
better
suited
for
the
quality
team,
but
I'll
ask
it
here.
Anyways.
Do
we
have
any
qa
processes
in
place
for
testing,
self-managed,
omnibus
or
upgrade
paths
that
skip
minor
or
patch
versions?
I
know
the
upgrade
process
between
self
managed
and
dot
com,
as
well
as
the
deployment
environment
for
selfmanageverses.com.
There
can
be
some
differences.
Do
we
have
any
qa
or
testing
for
the
self-managed
specific
stuff.
C
C
Okay,
so
from
our
point
of
view,
we
have
dedicated
environment
for
testing
customer
releases
and
I'm
quite
sure
we
test
how
many
bus
packages,
so
we
have
the
release
environment
where
every
time
we
tag
something
we
deploy
it
there
well
every
time
between
quotes.
So
when
we
do
security
fixes
back
ports
for
security
fixes,
they
don't
end
up
there,
so
we
only
always
deploy
the
latest
patch
release,
so
that
machine
runs
qa
as
well,
and
so
we
test
every
single
battery
releases
insulation.
C
A
C
A
Right
yeah,
so
yeah
we
test
the
the
the
nicest
upgrade
path,
but
yeah
no
jumping,
but
I
will
add
in
and
make
sure
quality
come
back
because
they
might
have
some
good
thoughts
about
like
the
how
this
ties
in
with
the
quality
strategy
and
and
why
we
go
about
it.
That
way.
Thanks
for
asking.
A
Fantastic
one
thing
I
did
want
to
just:
if
anyone
else
has
any
questions
feel
free
to
please
drop
them
in
on
the
agenda.
Like
one
thing
I
would
like
to
kind
of
ask
slightly
staged
is,
but
I
know
it's
a
little
bit,
perhaps
not
as
visible
as
it
should
be
and
we'll
be
coming
along
is
uric
has
been
working
on
leading
and
kind
of
moving
change
logs
inside
the
gitlab
product,
and
we've
been
sort
of
testing
and
rolling
those
things
out.
A
G
Yeah
sure
so
the
elevator
pitch
of
it
is
that
we
have
our
current
change,
lock,
approach,
which
involves
contributors
and
other
engineers
committing
a
yaml
file
and
in
there
they
write
a
short
description
of
what
the
feature,
for
example,
is
about,
and
then
they
have
to
link
to
the
merge
request
and
optionally.
If
it's
a
contributor,
I
believe
they
can
also
add
the
author
name
to
it
and
then
there's
a
tag
saying
hey:
this
is
a
bug,
fix
a
feature
being
added,
etc.
G
That
particular
workflow
we've
been
using
for
a
couple
of
years,
but
it
has
some
issues,
one
of
them,
for
example,
being
that
you
have
this
sort
of
two-step
process
of
make
your
changes,
add
the
file
and
then
set
up
your
merge
request.
But
then
you
have
to
go
back
edit.
The
file
to
add
the
merge
request,
force,
push
and
for
experience,
engineers
that
is
released
for
me
is
mildly
annoying
but
doable,
but
for
people
that
are
new
to
git,
for
example,
or
they
use
the
web
ide.
G
It's
not
something
you
can
install
yourself
and
easily
use
the
setup
that
we're
now
moving
to
is
using
this
newly
introduced
feature
it's
introduced
in
13.9
and
essentially
the
way
it
works.
Is
you
write
your
commit
messages
as
you
normally
would,
and
they
add
a
certain
tag
at
the
end
of
the
message
and
that
tag
will
indicate.
This
is
a
feature,
a
bug
you
know
etc
and
from
that
point
on
gitlab
takes
care
of
everything,
so
it
will
try
to
automatically
figure
out
the
merge
request.
It
will
show
the
author
all
these
normally
manual.
G
Steps
are
done
for
you,
along
with
some
sort
of
added
power
features
where
you
can
customize
how
it's
presented
and
stuff
like
that.
We
are
currently
testing
that
out
with
gitlab
pages
and
omnibus.
I
could
let
pages
I
believe
earlier
today
decided
they
were
going
to
do
their
next
release
with
this.
G
Basically,
if
that
goes
well,
that
will
be
there
sort
of
a
new
way
of
doing
it,
omnibus
we're
basically
waiting
until
the
22nd,
the
id
being
that
we
do
this
release
with
the
new
approach,
but
they've
been
using
both
all
the
new
approach
in
parallel,
so
you
can
always
revert
if,
for
whatever
reason,
it
doesn't
work
out
and
then
we'll
sort
of
gradually
start
rolling
that
out
to
the
other
satellite
projects
and
then
last
we'll
do
the
main
rails
application
we're
doing
that
one
last,
because
it
has
the
largest
number
of
contributors
with
a
fairly
diverse
set
of
experiences.
G
So
a
lot
of
people
they
might
be
highly
experienced,
but
also
a
lot
of
people
who
probably
don't
even
know
what
git
is,
for
example,
yeah.
So
that's
what
we're
working
on
it's
instead
of
a
custom
thing,
it's
all
built
in
gitlab
through
an
api.
Let's
see
what
else
is
there
yeah?
I
think
that's
sort
of
the
brief
overview
of
it,
and
this
is
part
of
the
sort
of
dog
footing,
effort
we've
been
focusing
on
in
the
last
couple
of
months,
and
this
was
related
to
one
of
the
previous
questions.
G
One
of
the
things
where
he
felt
like
hey
this
should
really
be
in
the
product
because
at
least
for
free
software
projects
they
basically
all
need
to
generate
a
change
log
and
there's.
You
know
different
ways
of
doing
it,
but
will
be
much
easier
if
that's
just
one
way
of
doing
it.
At
least
when
you
use
gitlab.
A
Nice
thanks
very
much
so
we
are
pretty
much
at
time.
Has
anyone
got
any
final?
Is
there
a
final
question
or
if
not
there's
also,
we
have
a
slight
channel,
which
people
are
also
always
welcome
to
drop
in
and
chat
to
us
there
as
well.
So.
A
Fantastic
well,
thank
you
so
much
for
everyone
who
turned
up
and
thank
you
so
much
for
all
the
great
questions
as
well,
really
good
to
see
you
all
enjoy
the
rest
of
your
days.
Bye.