►
From YouTube: 2022-01-12 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
Welcome
everyone
so
just
give
a
few
more
seconds
in
case
we
have
any
more
joiners
and
then
we'll
get
started.
A
Okay,
I
shall
begin
so
welcome
everyone.
This
is
the
delivery
team
ama
our
first
of
the
year,
so
thanks
for
joining
us,
so
I'm
gonna
kick
things
off
for
everyone
who's
here.
In
that
I'm
interested
to
know.
If
anyone
has
any
questions
or
if
there's
any
concerns
or
unknowns
or
anything
about
the
changes
we're
currently
making
to
staging,
we
have
an
issue
there.
That's
open.
B
Just
wonder
is
the
way
to
switch
between
the
staging
canary
and
the
staging,
because
I
know
for
gitlab.com
we
have
next.getlab.com
and
you
can
toggle
between
the
two.
Is
that
something
where?
Where
are
we
going
to
be
able
to
do
that
with
the
staging.
A
So
it
is
cookie
based
yeah,
I'm
not
sure
in
the
exact
way,
we'll
control
that
cookie,
but
it
is
set
off
a
cookie.
Yes,
so
you
will
be
able
to
determine
which
environment
you'll
go
to.
Yes,.
C
Yeah,
I
have
a
reference
to
the
issue
where
we're
discussing
this,
so
the
implementation
is
in
place.
I'm
not
entirely
sure
if
it's
already
handled
by
next.github.com,
but
the
same
cookie
can
have
a
special
key,
which
is
a
gitlab
underscore
canary
and
if
it's
equal
to
false
or
true
we'll
do
the
routing
as
well
on
the
on
the
canary
stage.
D
D
Next
yeah
staging.com,
that's
a
fun
domain.
There's
also,
apparently,
which
I
didn't
realize,
there's
a
hotkey
in
the
product
now
to
toggle
canary,
I
don't
know,
but
there's
a
potential
bug
with
that.
I
think
I
opened
an
issue
I'll
link
all
this
stuff
in
the
document.
Once
I
find
it.
A
Awesome
yeah
that
was
great
yeah
great
questions
done.
We
should
definitely
make
sure
that
we
have
the
same
capabilities,
so
people
can
toggle
the
main
difference
that
will
that
people
may
unexpectedly
experience
is
when
codes
on
things.
So
probably
that's
going
to
be
the
biggest
sort
of
shift
in
sort
of
understanding
is
code
on
staging,
isn't
necessarily
on
staging.
A
And
then,
if
you
find
a
problem,
you
can
block
production
they'll
be
running
pretty
much
in
parallel,
they're
staging
us
slightly
ahead
and
then
because
of
that
we
have
a
staging
canary
environment,
but
we
should
make
sure
we
have
the
capabilities
of
both
and
just
a
small
request.
Search
before
we
go
on
would
people
mind,
helping
write
the
notes
and
the
agenda
so
that
we
can
try
and
keep
up.
So
if,
if
people
are
speaking,
please
help
thanks
are
there
any
other
things
around
staging
that
people
may
know
about
that?
B
B
D
A
E
Yeah,
I
was
just
curious
about
the
what's:
what
does
delivery
have
looking
forward
into
year?
2022
that
we're
all
excited
about.
A
Should
I
go
first,
so
I've
added
a
few
in
the
end
at
the
very
very
bottom
of
the
2021
year
in
review,
so
we're
still
sort
of
selling
direction
for
the
department
and
the
team
for
the
year.
But
the
few
things
that
I'm
hoping
we'll
be
focusing
on
is
reducing
the
effort
involved
with
patches
and
particularly
back
ports,
but
also
security
releases,
because
they
are
pretty
time
intensive
for
all
of
us.
A
So
we
are
hopefully
going
to
be
able
to
make
some
some
good
improvements.
So
actually
you
know
we
know
that
customers
do
need
things
to
be
backported
a
bit
further.
We
know
we're
getting
more
requests
outside
of
our
maintenance
policy,
so
actually
reducing
the
the
pain
of
us
needing
to
be
able
to
do
that
and
then
continuing
with
kubernetes
so
most
exciting
one.
I
think
that
we'll
we
know
we're
going
to
be
tackling
is
redis
because
we're
already
dealing
with
redis
working
with
scalability
there.
A
Let's
go
back
share
more
of
the
highlights
on
reddit,
but
I'm
excited
to
see
that
one
progressing
and
then
I'm
hoping
that
this
year
might
be
the
year
we
get
to
continuous
deployment.
So
we
are
not
so
far
away.
We've
made
great
progress
on
rollbacks.
We've
got
lots
of
other
pieces
in
place.
We
still
have
a
few
things.
E
Yeah,
I
could
briefly
chat.
Redis
will
be
one
of
our
first
stateful
services
that
we
migrate.
That
gitlab.com
will
heavily
depend
on.
We
do
have
monitoring,
which
maintains
state
inside
of
kubernetes,
but
redis
is
going
to
be
the
primary
one
where
gitlab.com
has
a
dependency
on
something
that
maintains
state
inside
of
kubernetes.
I
was
just
repeating
myself
there,
my
apologies,
so
we
got
some
interesting
fun
items
where
we're
trying
to
plan
out
the
best
way
to
accomplish
this.
E
Currently
we
have
an
open
pr
for
the
bitnami
helm
chart
that
will
enable
us
to
have
a
desired
migration
path.
Currently,
the
existing
helm
chart
does
not
have
certain
items
that
we
kind
of
want
to
have
in
place.
That
would
enable
us
to
make
it
easier
for
us.
We
would
like
to
have
the
ability
to
migrate
without
bringing
down
a
redis
cluster
in
any
way
shape
or
form,
but
instead
we
kind
of
wire
up
our
virtual
machines
and
kubernetes
pods
that
run
the
redis
instances
all
together,
and
then
we
make
the
necessary
application
changes.
E
E
That
is
our
current
goal
that
we
are
testing
for
and
that
we
are
aiming
towards.
Obviously
we're
still
testing
this,
so
it'll
be
a
little
bit
of
time
to
occur
before
we
get
a
chance
to
execute
this
so
looking
forward
to
it.
A
Yeah,
certainly
a
huge
huge
one,
nice
nice
to
sort
of
shift
beyond
stateless
into
this.
So
this
is
going
to
be
the
first
of
of
many
new
services
which
is
excellent.
A
Has
anyone
else
got
any
hopes
or
highlights
that
I'd
like
to
share.
F
I
do
have
a
couple:
it
is
not
on
the
issue,
but
it
is
kind
of
on
my
wish
list
that
I
would
like
to
deploy
directly
from
master.
Instead
of
doing
this,
little
dance
of
creating
auto
deploy,
branches
and
tagging
from
the
latest
ring
commit.
It
would
be
really
cool
if
we
could
just
grab
the
last
commit
from
master
and
just
start
our
deploy
process
from
there
so
yeah.
That
would
be
one
and
another.
F
One
is
to
the
one
that
we
have
been
discussing
for
rollbacks
about
removing
the
blocking
nature
of
post-deployment
migrations,
which
we
are
already
working
towards
that.
But
the
end
result
of
that
is
that
we
are
basically
making
every
package
to
be
rollbackable,
which
is
not
a
situation
that
we
have
right
now.
So
that
would
be
nice.
A
A
G
Oh
hey
thanks
for
doing
these
calls
super
helpful.
G
I'd
like
to
see
some
other
cs
folks
on
the
call,
so
I
had
a
question
around.
I
have
been
working-
it's
probably
close
to
two
years
now
on.
How
do
we
succinctly
do
release
training
for
the
field,
so
there's
a
lot
of
features
where
you
all
have
done
a
fantastic
job
of
continuing
to
make
such
a
great
product.
One
of
the
things
that
I'm
struggling
with
is
how
do
I
help
the
field
like
essays,
tams,
pscs
really
hone
in
on
those
features
that
are
really
going
to
wow.
Our
customers
really
help
drive.
G
Adoption
help
make
our
products
stickier
and
I'm
wondering
if
there's
you
know
any
cycles,
any
appetite
from
this
team
to
kind
of
help
us
with
it.
I
think
it
is
a
group
effort
between
engineering.
You
know
product
marketing
and
us,
but
I'd
just
love,
to
hear
some
initial
thoughts
on.
Would
you
all
be
interested
in
partnering
with
us
on
that.
A
That's
a
super
great
question
and
thanks
for
sharing
that
link,
it's
the
first
time
I
have
seen
it
so
absolutely.
We
are
very
happy
to
be
very
keen
to
partner
on
things.
Possibly
we
would
be
looking
or
certainly
including
the
blog
post.
So
we
kind
of
have
two
processes
that
come
together
at
the
sort
of
the
on
the
22nd.
A
H
A
The
product
managers
manage
the
creation
of
the
blog
post
and
figuring
out
like
what
should
be
in
there.
Did
this
feature
make
the
release
or
not,
which
ones
to
highlight,
and
we
do
the
sort
of
gathering
of
of
the
actual
release
and
then
on
the
22nd.
We
publish
the
packages
and
then
there
is
a
blog
post
sort
of
person
assigned
who
is
publishing
the
blog
post.
A
So
the
process
overall
comes
together
with
a
bit
of
coordination,
but
it
is
certainly
something
we'll
be
looking
at
over
this
year
on
how
we
can
actually
improve
on
processes
so
yeah.
Let
me
take
a
look
through
and
absolutely
we'd
love
to
collaborate
with
you.
There
yeah,
because
I'm
thinking.
G
Like
this
isn't
even
mvc
would
be
just
kind
of
packaging
all
of
that
stuff
in
one
place,
because
there's
the
blog
post
and
those
are
kind
of
all
over
the
place
and
there's
the
docs,
then
there's
the
marketing
team
makes
videos
even
just
these
calls.
I'm
like
I
see
a
couple
of
essays
and
we
had
a
tim
earlier.
I
think
he
might
have
dropped,
but
it's
like
hey
did.
Is
everybody
aware
of
all
of
the
calls
like
this
call?
A
new
does
a
call
it's
like.
Are
we
attending
those?
Because
there
is
information
available?
A
H
A
Great
question,
thank
you
so
much
so
would
someone
like
to
scarborough,
I
feel
like.
I
want
to
nominate
you
because
you
know
what
the
biggest
one
was
right.
E
I
don't
like
this
domination
process
that
you're
doing
one
of
the
biggest
contributions
that
I
know
of
is
that
we've
migrated
things
over
to
kubernetes.
E
F
Okay,
I
will
try
to
move
along,
so
I
think
we
also
modified
the
auto
deploy
schedule.
Previously
we
were
creating
like
two
auto
deploy
branches,
one
in
india
and
one
in
america,
and
now
we
create-
I
don't
know
like
five
of
the
deploy
branches
and
then
on.
Every
auto.
Deploy
branch
creates
a
package
that
is
deployed
throughout
our
environment,
so
that
also
speed
up
and
also
the
fact
that
we
are
deploying
now
in
apac.
We
didn't
do
that
before
and
that
it
has
been
a
huge
help.
F
A
In
the
in
the
21
so
like
those
are,
those
are
definitely
some
of
the
real
key
things
highlighted,
I
think,
generally,
maybe
to
cut
to
sort
of
like
the
bits
that
are
pipeline
related
that
maybe
other
customers
would
find
useful.
A
We
did
quite
a
lot
of
work
to
to
streamline
the
process
like
the
deployment
pipeline
this
year,
so
we're
using
bridge
jobs
more
extensively
now
and
the
sort
of
the
on
the
most
simplest
way
of
the
benefit
that
gives
us
is
we're
not
having
to
wait
so
much
between
our
jobs,
so
the
pipeline
has
become
smarter,
so
that
was
quite
a
big
one.
A
For
us,
as
well
as
say,
underlying
kubernetes
means
we
can
get
the
code
out
more
quickly
and
kubernetes,
like
you,
know,
sort
of
really
sort
of
made
this
well.
I
suppose
we're
now
setting
up,
so
we
can
run
more
things
in
parallel,
so
reducing
waiting
on
the
pipeline
optimizing.
What
like
which
environment,
which
test
we
want
to
run.
Those
are
things
I
think
everyone
every
pipeline
can
benefit
from.
H
That's
great
to
hear
yeah.
Thank
you
for
all
that.
The
the
other
thing
too
sort
of
related
is,
do
we
have
our
pipeline
public
or
is
that
something
that's
behind
the
scenes
on
us
deploying
out
the
production.
A
So
it's
unfortunately
behind
the
scenes,
which
is
a
which
is
a
show.
C
Not
exactly
I
mean
the
execution
is
behind
the
scene,
but
the
code
is
public
yeah.
So
if
you
want
to
see
what
we
how
we
are
doing
stuff,
you
can
clone
and
use
our
code
base
and
then
you
have
to
run
it
in
your
own
environment.
If
you
want
to
see
the
execution
of
our
own
node,
that's
private,
yeah,
internal
information.
Things
like
that,
so
you
can't
see.
A
Like
it's
not
it's
not
super
trivial
to
just
see
our
pipeline.
Unfortunately
right,
which
is
a
shame.
A
Are
there
any?
I
don't
like
specific
questions
that
joe
or
maybe
anyone
else
from
from
support
sort
of
like
gets
around
from
customers
around
how
we're
doing
deployments.
A
Okay,
are
there
any
other
questions
that
people
want
to
cover
off
today.
A
No
okay,
awesome
thanks
so
much
everyone
for
coming
along
thanks
for
all
the
questions
and
hope
you
all
have
a
good
rest
of
your
day.
Take
care
bye,.