►
From YouTube: 2021-04-27 Delivery team weekly rollbacks demo - part 2
Description
Running a dry-run rollback in Production
A
B
A
B
B
B
B
B
B
Just
to
validate
our
pre-change
steps,
we
have
the
first
item
already
checked,
which
I
believe
alessio
you
did
earlier
today,
but
just
to
validate
yeah.
I
just
want
to
make
sure
things
are
still
cancelled.
Yeah
the
post,
deploy
is
still
cancelled,
ensure
there
are
no
ongoing
deployments.
There
is
no
ongoing
deployment.
C
B
B
B
Yeah,
that's
fine,
yeah,
take
a
note,
so
technically
the
rollback
command.
We
really
wanted
to
state
that
we
want
to
roll
back
to
what's
currently
listed
as
current,
so
the
fa1
dd,
which
I
need
to
find
the
rest
of
that
package
name
for
so
to
do
that.
I'm
just
going
to
look
at
our
announcements
channel
to
figure
out
what
that
is
supposed
to
be.
D
A
B
B
B
D
D
C
A
C
B
Yeah,
so
this
is
it's
just
a,
I
guess,
a
language
thing
like
from
a
technical
standpoint.
A
deploy
is
still
ongoing.
We
just
paused
it
for
the
purposes
of
this
test,
but
inside
of
g
delivery,
I
just
ran
the
auto
deploy
status.
It
tells
us
there's
an
ongoing
deployment
and
that's
because
we
haven't
finished
the
production
deployment
that
we
were,
that
is
supposed
to
be
rolling
out
and
sure
enough.
Our
last
statement
is
the
production
environment
is
locked
and
that
it's
locked
because
we
didn't
finish
our
last
deployment.
B
B
A
B
D
D
B
E
B
B
E
B
B
B
B
B
The
reason
why
we
run
this
job
is
because
we
need
to
tell
the
servers
to
update
their
apt
cache,
because
otherwise
they
won't
know
the
package
exists,
because
we're
rolling
back
that
database
should
already
be
populated
with
the
package
that
we're
going
backwards
to
so
hypothetically.
We
don't
need
to
run
this
job
at
all
during
a
rollback.
In
my
opinion,.
B
B
B
B
B
B
D
B
D
A
B
The
apt
cache
clean
job,
which
is
one
of
the
finishing
tasks
this
one.
That's
what
technically
removes
the
old
package
from
the
server
since
we're
in
dry
run?
I
don't
expect
this
to
do
anything
and
considering
the
fact
that
the
package
is
actively
running
and
we
haven't
installed.
The
older
version
like
this
shouldn't,
do
anything
yeah
every
deploy.
We
clean
out
the
app
cache,
because
otherwise
our
service
would
fill
out
fill
up
on
the
disk
space.
If
we
don't
do.
B
E
E
One
other
thing
that's
unrelated
specifically
to
this
dry
run,
but
it's
related
to
rollbacks.
So,
just
before
joining
here
I
was
doing
a
bit
of
an
epic
tidy
up,
so
we're
going
to
try
and
get
the
code
the
pipeline
for
code
rollback
epic
to
be
this
basically
and
we
can
consider
it
complete
when
we've
done
a
rollback
in
production
and
it's
all
gone
well.
E
So,
whatever
our
follow-up
test
after
this
is
and
then
I
will
move,
we've
got
quite
a
lot
of
other
issues
which
are
all
around
improving
information
like
dashboarding
commands.
Those
are
kind
of
lots
of
those
pieces,
I'm
just
going
to
move
those
up
onto
the
assisted
rollback,
epic
and
that
epic
will
be
the
thing
that
we
use
to
take
the
rollback
pipeline.
We
have
and
sort
of
fill
in
the
steps
that
we
need
to
go
to
until
we
become,
I
suppose,
confidence.
E
So
it's
filling
in
all
the
gaps
of
getting
from
here
to
the
point
where,
in
the
event
of
an
incident
we
automatically
check,
is
there
something
that
could
be
wrought
back?
If
it
is,
we
would
roll
it
back.
So
all
of
the
bits
that
go
in
between
those
two
things
so
I'll
move
some
stuff
around.
But
hopefully
it
means
that
we
are
quite
close
to
having
the
code
pipeline
epic
completed,
which
is
very
exciting.
E
Well,
we
end
up
once
we've
done
this
dry
run
test.
We
end
up
in
a
interesting
problem,
which
is
that
we,
the
next
in
order
to
finish
this
task.
We
need
to
do
a
roll
back
on
production.
The
problem
is
really
hard
about
scheduling.
The
test.
Rollback
is
we're
taking
a
fully
working
system
and
potentially
breaking
it,
but
if
we're
in
an
incident
that
risk
is
a
little
bit
different
because
we're
taking
a
broken
system
and
potentially
fixing
it.
B
I
think
the
type
of
incident
matters
like
if
it's
an
abuse
problem,
then
rolling
back,
doesn't
apply
and
in
fact
that
might
actually
make
things
worse,
because
we're
sitting
here
telling
the
service
to
go.
Do
some
tasks
unrelated
to
processing
a
user
abuse
request.
You
know
I'd
be
wary
of
that
kind
of
style
of
rolling
back
at
that
point,.
B
E
E
E
E
B
B
B
B
B
E
A
A
D
B
B
B
B
D
B
B
D
B
B
B
B
No,
I
think
this
is
what
alessio
was
trying
to
really
get
out
there.
Is
that
the
normally,
if
any
issues
happen
that
force
us
to
do
a
rollback?
Usually
it's
the
rails
code
base
and
not
the
giddily
code
base
that
causes
the
problem.
So
in
this
particular
case
we
made
it
a
manual
job
because
they
are
relatively
good
at
being
backward
compatible
with
each
other.
So
there's
a
chance
of
just
speeding
up
the
rollback
procedure
by
simply
not
doing
the
giddily
jobs,
which
I
agree
with.