►
From YouTube: Delivery: Learning how to perform the security release
Description
In this video we discuss the details and plan required for an upcoming security release. A process that is made a tad more difficult since the migration to using auto-deploys for the GitLab.com site.
A
A
They
can
like,
they
can
obviously
also
download
the
packages.
I
think
all
of
this
is
written
down
in
the
docs
when
it
comes
to
that
process,
but
you
did
well
with
informing
and
now
you
actually
also
have
the
date
set,
because
if
they
confirm
that
the
QA
passed
right
like
that
they
verified
the
fixes.
That
means
no
more
surprises.
There
yep
I'm
a
bit
sad
that
we
cannot
do
this
on
Friday,
but
I
understand.
B
B
My
main
concern
is
if
we
wait
till
Sunday
we're
gonna,
have
a
new
auto
deploy
branch
with
90
plus
changes.
The
chance
of
a
merge
conflict
raises
that
many
commits
all
right
to
avoid
that
personally,
if
possible.
So
if
I
could
get
everything
done
on
Monday
I
would
be
happy.
Excuse
me
if
everything
I
could
get
everything
done
on
Friday
I
would
be
happy.
So,
let's.
B
A
So
it
would
probably
have
to
be
your
work
day.
You
would
probably
have
to
disable
the
cherry
picker
so
that
new
commits
do
not
go
in
to
the
auto
deploy
branch
on
github.com
and
you
need.
You
would
need
to
verify
and
confirm
that
the
state
on
the
FD
Club,
the
torque,
for
the
auto
deploy
branch
and
on
github.com
is
the
same.
So
you
have
a
you
know:
baseline
zero.
A
I'm
talking
about
I'm
talking
about
you
ought
to
deploy
branch-
oh
yeah,
because
we
are
deploying
from
that.
Alright.
So
if
you
confirm
the
debits
of
the
torque
and
dot-com
have
the
same
auto
deploy
branch,
you
can
then
disable
like
pause.
The
schedule,
job
that
does
Auto
picker
yeah
and
you
can
use
the
Chatham's
commands
to
merge
security
fixes
into
master.
But
that's
a
good
point
as
well.
You
you,
you
would
want
to
also
confirm
that
master
is
in
sync,
that's
a
good
point,
so
master
in
sync
and
auto
deploy
branch
in
sync.
B
B
B
A
A
A
Of
this
to
calm
development,
it's
gonna
be
really
important.
So
if
you
merge
all
of
those
things
into
monster,
you
will
need
to
make
sure
that
you
cherry
pick
all
of
those
merge
requests.
You
remember
how
that
was
done
right
with
cherry
pick,
whatever
yeah,
if
you
do
it
thing
in
the
correct
order
oldest
to
the
newest,
it
should
literally
be
a
couple
of
minutes
of
work
like
all
manual.
Unfortunately,
I
think
yeah.
A
B
A
A
A
A
So
when
that
is
done,
you
need
to
get
the
approval
from
uncle
to
deploy
on
Friday
yeah.
That
is
the
tricky
part
of
this
scenario,
but
if
you
inform
them
up
well
up
in
advance,
that
should
be
okay,
but
then
you.
We
also
need
to
remember
to
inform
development
that
we
are
deploying
security,
which
means
anything
that
is
going
to
be
added
on
Friday
afternoon
and
expect
it
to
be
deployed.
Is
gonna,
be
delayed
until
Monday
yeah.
B
A
A
So
then,
basically
it
is
up
to
each
job
working
on
Monday.
He
said
he
was
just
to
be
away
from
keyboard
all
right.
In
that
case,
he
should
sync
up
with
whoever
is
responsible
in
the
security
side
to
get
the
release
as
early
as
possible
on
Monday,
so
I
mid
mid.
We
worked
the
Europe
time
so
that
master
can
be
unfrozen.
Then
then
manual
sinking
would
need
to
be
done
right.
A
A
A
A
A
A
A
Couple
of
months,
but
in
both
cases
you
would
expect
a
new
auto
deploy
branch
from
master
after
the
thing
got
published.
That's
gonna
make
things
easier.
It's
only
that
in
one
scenario,
you're
doing
this
right
now
and
kind
of
freezing
things
until
Monday
and
the
other
scenario
is
on
Monday.
You
have
a
bit
more
extra
work
to
make
sure
that
everything
that
was
merged
up
until
this
point
is
deployed
to
calm,
so
difficult
difficulty
is
pretty
much
the
same.