►
From YouTube: 2022-08-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
Okay,
I'll
go
ahead
and
begin
so
welcome
everyone.
This
is
the
august
10th
2022
delivery
groups,
monthly
ama,
so
delivery
group
is
responsible
for
deployments
and
releases
to
all
get
lab
users.
So
I
will
kick
off.
We
have
one
question
on
the
agenda:
uppers,
not
other
cool,
so
I'll
verbalize
could
post
deployment.
A
Could
post
deployment
migrations
be
run
during
the
canary
window
after
canary
has
been
deployed,
but
before
production
deploy?
This
is
related
to
a
change
that
alpha
is
currently
working
on.
So
I've
added
my
answer
here,
but
skype.
If
you
want
to
add
any
additional
details,
please
do
jump
in
so
sort
of
short
answer
is
no.
We
have
things
set
up,
so
the
post-deploy
migrations
pipeline
won't
be
executing
any
migrations
before
they've
been
deployed
to
production
and
added.
In
a
note,
there.
A
B
A
I'll
also
add
on
here
we,
this
is
kind
of
related
to
our
recent
changes
to
separate
out
the
pipeline.
So
I'll
put
the
handbook
update
in
there
and
what
we've
essentially
done
recently
is
the
final
stages
of
the
autodeploy
pipeline
were
to
execute
these
post-deploy
migrations
and
what
we've
done
is
pretty
much
just
lifted
the
jobs
related
to
that
into
their
own
independent
pipeline,
and
the
goal
behind
that
is.
It
means
that
all
auto
deploy
packages
now
have
the
ability
to
roll
back.
A
If,
if
we
have
problems
in
production,
so
a
bit
of
extra
context
there
in
case
anyone
is
on
the
call
but
hasn't
been
following
along
with
those
changes.
A
Awesome
lee
you
have
the
next
question.
C
Yeah,
so
I'm
working
a
lot
with
amazon
web
services
and
finserv
accounts,
so
the
nasdaq
goldman
sachs
bank
of
america,
those
kinds
of
folks
and
they
distinguish
a
a
pretty
big
difference
between
what
a
deployment
is
and
what
a
release
is,
and
usually
there
is.
I
know,
we've
got
the
capability
for,
through
the
environments
of
being
able
to
support
that
you
have
environment
type
of
scheduling,
to
be
able
to
make
sure
that
somebody
approves
somebody
going
between
environments.
C
Are
we
thinking
about
anything
about
releases
where,
let's
say
I've
got
multiple
different
projects
that
each
deploy
things
independently,
where
there
is
the
ability
to
think
of
having
a
release
that
aggregates
across
multiple
projects
to
have
a
single
final
deployment
that
would
be
considered
a
release
across
all
of
those
projects?
A
A
great
question
yeah,
I
suppose
just
one
little
extra
thing
then
in
terms
of
what
you
would
like
to
see
like,
is
that
the
sort
of
goal
that
there
is
a
single
package
that
results
this
sort
of
is
the
resultable
deployments.
C
So
if
you
think
of
the
way
that
I
I
talk
to
them-
and
this
may
be
wrong
in
the
way
that
I'm
I'm
talking
about
it
with
our
customers,
but
so
I've
opened
the
discussion
up.
But
let's
say
I've
got
a
sub
group
that
has
five
micro
services
that
are
associated
with
it.
C
And
then
there
is
a
sixth
project
that
has
other
dependencies
that
are
included,
that
I
may
have
terraform
scripts
for
configuring,
a
database
or
some
middleware,
or
something
else
that
the
project
depends
on
and
there's
a
change
management
process
that
goes
across
the
five
micro
services.
That
let's
say
each
creates
their
own
docker
image
to
deploy
into
different
name
spaces.
C
And
when
I
go
ahead
and
deploy.
I
want
to
take
the.
I
want
to
make
sure
that
the
latest
image
from
microservice
1
through
microservice5,
that
they
all
get
released
in
conjunction
with
one
another
through
some
sort
of
dependency,
as
well
as
that
sick
project.
To
make
sure
that
any
database
updates
any
additional
middleware
that
may
be
required
also
gets
released
at
the
same
time
with
some
sort
of
tracking.
C
That
shows
if
something
did
fail,
that
the
rest
of
the
components
would
either
roll
back
or
I
would
have
a
way
to
be
able
to
show
that
there
was
a
failed
deployment
to
do
a
manual
rollback
if
it
was
required.
D
I
think
that
would
fall
under
what
the
release
team
is
doing
rather
than
what
we
are
doing.
Amy
is
alright
yeah.
A
That's
possibly
right
so
for
certainly
for
the
for
the
sort
of
the
deployments
that
delivery
is
is
running.
We
we
are
sort
of
working
towards
this
model,
so
currently
on
github.com,
we
deploy
it's
pretty
much
monolithic,
pretty
much.
A
Everything
just
is
packaged
up
and
released
to
gitlab.com
as
one
thing
and
then
what
that,
what
that
guarantee
does
is
we're
able
to
then
produce
the
package
which
goes
off
to
self-manage,
exactly
as
you're
sort
of
saying,
like
you
know,
we
produce
a
single
package
that,
if
you
install
you,
get
all
the
pieces
that
go
with
that
and
what
we're
actually
starting
to
work
towards
is
to
think
about
whether
it's
possible
for
stage
groups
to
deploy
to
gitlab.com,
which
doesn't
rely
on
that
single
package
and
have
more
independence,
whilst
still
resulting
as
having
a
single
package
that
we
actually
can
give
to
self
management.
A
So
that's
kind
of
how
we
are
operating.
I
I
suppose,
in
terms
of
so
customers
should
still
be
able
to
expect
that
they
will
have
a
single
single
package
with
all
the
pieces
in
it
in
terms
of
whether
we
have
sort
of
features
and
things
coming
out.
I'm
not
not
totally
sure
like
that.
That's
certainly
something
we
can.
We
can
check
in
with
release.
C
Yeah
and
I
I
could
see
it
being
because,
as
you
were,
describing
the
idea
of
that
monolithic
type
deployment
model,
it's
a
conversation.
I
know
the
sales
teams
struggle
with
because
a
lot
of
our
customers
to
build
out
that
type
of
deployment
scenario
they
end
up,
creating
mono
repos
and
then
those
mono
repos
very
quickly
end
up
becoming
larger
than
you
know:
five
gig
in
size,
depending
on
how
many
contributors
they
have,
which
then
leads
to
a
whole
other
set
of
issues.
So
that's
where
I'm
trying
to
balance
those
two
things
together.
C
A
Yeah
absolutely
yeah.
It's
such
an
interesting
challenge
because,
as
we're
starting
to
think
about
it,
now
it's
all
down
to
kind
of
keeping
track
of
dependencies
and
keeping
track
of
versions
and
knowing
you
know,
component
a
has
version,
10
and
composition
b
is
11
and
have
they
been
tested
together.
So
it's
certainly
a
really
a
really
interesting
challenge,
but
yeah.
I'm
not
aware
at
the
moment
that
we
have
things
in
place
to
allow
us
to
do
that.
A
Great
question:
so
we
are
just
early
into
the
quarter,
so
we
have
within
delivery.
We
have
got
four
main
okrs
that
we're
focusing
on
this
quarter,
so
we've
just
recently
split
delivery
group
into
two
teams.
One
of
our
teams
is
the
delivery
system
group.
Sorry,
it's
a
delivery
system
team
and
that
team
is
going
to
be
focusing
this
quarter
on
rebuilding
all
production
clusters
within
a
week.
A
So
this
ties
into
our
disaster
recovery,
work
and
generally
kind
of
improving
our
ability
to
kind
of
operate
our
kubernetes
clusters
and
also
we're
currently
still
scoping
but
related
to
our
self-serve
work.
We
are
scoping
out
what
would
be
a
useful
kind
of
foundational
preparation,
work
that
we
can
do
that
sets
us
up
well
for
actually
moving
some
components
to
having
self-serve
deployments
and
maintaining
our
kind
of
single
release
package
then
over.
On
the
other
side,
we
have
our
orchestration
team
and
that
team
is
focusing
this
quarter
on.
A
We
have
a
couple:
we've
identified
some
steps
that
we
would
expect
all
components
to
move
towards
in
order
to
reach
self-serve.
This
is
based
on
the
things
we've
learned
from
gitlab.com
deployments
over
the
years.
So
we
sort
of
know
that
there
are
version
files
we
need
to
manage
and
we
need
to
have
tests
in
place
and
various
metrics.
So
we've
identified
a
couple
of
components
and
we're
going
to
try
and
move
them
a
couple
of
steps
closer
to
self
serve
deployments.
A
So
in
q4
we
expect
to
start
working
on
supporting
patch
releases
going
back
further
something
we
know
a
lot
of
customers
want
at
the
moment.
It's
not
very
straightforward.
There's
a
lot
of
difficulties
with
getting
fixes
into
older
branches,
there's
a
lot
of
challenges,
of
keeping
branches,
kind
of
building
and
deploying
them
to
environments.
So
we're
going
to
spend
some
time
this
quarter
like
working
out.
A
What
exactly
will
be
involved
in
that
and
then
in
q4
we
expect
to
start
working
on
actually
setting
up
to
support
the
extension
that's
coming,
so
those
are
the
accounts.
All
of
them
are
on
quite
low
percentages
because
we're
very
early
in
the
quarter,
so
all
of
them
are
at
the
moment
sort
of
in
progress.
A
Okay,
in
which
case
thanks
so
much
for
all
the
questions
and
thanks
for
joining
us
again
this
month.
I
hope
you
all
have
a
great
rest
of
your
day.
Okay,.