►
From YouTube: 2021-04-27 Delivery team weekly rollbacks demo - part 1
Description
Preparing to test a dry-run rollback in Production
A
C
A
B
The
the
for
the
release,
yeah
80
minutes,
78
minutes
plus
yeah-
you
don't
even
count
on
the
raspberry
pi
images,
those
takes
half
a
day
kind
of
you,
don't
wait
for
them.
No,
we
don't!
Okay,
nice
80
minutes,
wow
yeah!
It's
a
lot
of
packages,
a
lot
of
just
yeah,
a
lot
of
versions,
a
lot
of
stuff
to
build.
We
are
building
this
on
the
dev
instance
right,
but
it's,
but
it's
a
runner
doing
this
right.
So
yeah.
B
B
So
we
were
just
acknowledging
the
fact
that
the
main
fleet
deployment
started
a
couple
of
minutes
ago,
so
I
mean
the
it
would
take
one
hour
more
or
less
so
I
mean
it's
there's
no
way
we're
going
to
be
able
to
test
it
now.
So
maybe
I'm
going
to
ask
to
the
myra
and
skarbuck
if
they
maybe
feel
comfortable
in
running
this
in
one
hour
time
or
even
two
hours.
When
I
mean
it's
more
suitable
for
both
of
them.
C
B
We
because
we
are
sticking
to
the
plan
that
was
approved
because
there
being
it
a
dry
run,
we
could
run
it
now.
I
mean
that's
that
that
that's
the
fact,
that's
a
fact
right,
so
nothing
is
going
to
happen
and
we
and
one
of
the
first
step
in
the
thing
is
we
check
that
is
actually
a
real
dry
run
pipeline.
So
nothing
is
gonna
change.
D
D
D
D
D
B
B
B
Okay,
so
I
I
have,
I
didn't,
put
anything
in
the
agenda,
but
I
have
a
couple
of
items
that
maybe
we
can
discuss.
We
just
want
to
have.
We
can
discuss
now,
and
I
think
we
should
close
this
earlier
so
that
we
get
some
time
back,
because
some
will
be
involved
in
this
later
on.
So
the
thing
is,
I
was
reviewing
the
the
the
plan
again
this
morning
and
I
realized
that
there
is
so
when
we
run
this
in
production
with
not
with
without
the
dry
run.
B
There
is
an
expected
failure
that
we
didn't
capture
in
our
in
our
change,
change,
request
issue,
which
is
that,
because
of
the
special
nature
of
our
tests,
we're
going
to
cancel
something.
So
we
will
have
a
production
locked,
because
production
will
be
locked
by
unfinished
deployment
to
production,
so
the
first
pipeline,
one
checks,
the
what's
the
name,
gprd
checks
down,
gpu
d,
prepare,
I
think
yeah
gprd
prepare
will
fail.
B
So
this
is
something
so
I
I'm
just
I'm
just
thinking.
Every
every
release
managers
knows
how
to
deal
with
it
because
it
happens
also
with
regular
deployment.
So
we
know
that
we
set
the
variables
we
rerun
and
then
we
unset
the
variable.
Maybe
henry
is
less
familiar
because
it
never
happened
in
the
in
the
shift
that
he
started
now.
But
I
mean
it's
something
that
is
part
of
how
we
handle
regular
deployments.
So
I
think
my
reasoning
is
more
among
the
line.
A
B
For
because
I'm
assuming
that
sometimes
we
will
end
up
in
situations
where
deployment
was
fine,
nobody
acknowledged
any
type
of
error
and
then
we
have
another
spike
and
they
said
maybe
it's
better
to
roll
back
and
maybe
there's
something
I
mean
you
know
as
a
release
manager
that
if
you
promoted
something
I'm
not
right
but
in
the
yeah
say
in
that
moment,
when
the
pressure
is
really
high
better
to
double
check.
Why
this
failed.
A
D
What
we
don't
have,
I
suppose
it's
the
other
piece
right
around
world
backs.
Is
we
don't
really
have
any
guidelines
for
a
release?
Manager
gets
pulled
into
an
incident,
something
may
or
may
not
be
right
and
that
all
the
steps
you
would
go
through
before
he
gets
the
role
back.
So
it
feels
to
me
it's
part
of
that
right.
It's
like
mate.
You
check.
If
there's
a
deployment,
maybe
you
cancel
it.
You
check
out
the
stuff.
You
check,
post
deployment,
migrations,
you
set
this
variable
or
you
kick
off
a
rollback.