►
From YouTube: 2021-04-13 Delivery team weekly rollbacks demo
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
C
C
B
D
Okay,
no
demos
today
because
we
yeah
there's
a
critical
situation:
progress
we
didn't
want
to
mess
up
with
cancelling
jobs
during
the
security
release,
so
discussion
items.
So
I
have
the
first
point:
it's
about
qa
after
the
production
rollback.
So
right
now
either
for
regular
deployment
and
drawback.
We
don't
run
qa
at
the
end,
but
there
is
there's
a
schedule:
smoke
test,
yeah
yeah,
the
sanity
run
smoke
does
send
to
run
whatever
that
runs
every
two
hours
in
production.
D
D
So
I
I'm
I'm
happy
to
be
convinced
otherwise,
but
I
don't
think
we
want
to
run
the
qa
as
part
of
the
rollback.
For
several
reasons.
Fir
I
mean,
if
you
maybe
let's
discuss
this
before
I
I
I
give
my
I
already
spoiled.
What
is
my
point,
but
just
if
you
have,
if
you
think
we
should
run
it,
please
tell
me
why
or
if
you
think
we
should
not
running.
Why
again.
B
Should
we
have
a
quick
vote
and
see
who
thinks
we
should
run
it
and
who
shouldn't
and
now
we
can
see
if
we're
all
in
agreement,
we're
going
to
discuss
right?
If
you
think
I'm
gonna
go
for
a
vote,
that's
gonna
be
chaotic.
Unless
you
think
about
it.
Don't
look
at
anyone
else
think
about
this
one
right.
If
you
put
your
left
hand
up,
then
then
you
think
yes
right
hand.
No!
Okay,
have
I
got
that
everyone
know
that
after
right.
E
B
C
B
B
Take
the
action
right
right.
Okay,
everyone
thing!
Is
you
gotta
all
vote
right?
I
don't
want
any
sitting
on
the
fence.
Everyone
has
to
make
a
decision
here
so
two
thumbs
up.
We
need
to
run
something
we'll
discuss
what
some,
what
that
is
one
thumb
up,
we're
good
right.
We
don't
need
to
run
anything
extra.
D
D
B
This
is
like
best
recording
ever
I'm
just
going
to
cut
these
first
five
minutes
and
just
keep
these
just
delete
everything
after
this.
This
is
just
a
bit
still
video.
We
need
okay,
so
we're
in
agreement
right.
You
need
your
hands
two
thumbs
up,
we'll
run
something
we
discuss
what
it
is.
One
thumb
up,
we're
fine,
it's
good
without
any
tests
pipeline
answers.
F
No,
like
realistically
here's
my
opinion
on
the
situation.
We
can
run
q.
A
that's
fine,
like
I
support
the
decision.
If
we
choose
to
do
that
or
some
other
solution,
but
I
mean
this
is
production
right.
We
should
have
all
the
necessary
metrics,
slas
slos,
alerting
all
that
stuff.
If
something
is
broken,
we
should
know
about
it
very
quickly.
F
If
we
have
some
sort
of
degradation,
we
should
know
about
it
very
quickly:
either
users
will
yell
scream
panic
cry
or
something
bad
will
be
happening
in
some
way,
shape
or
form.
I
still
support
running
something
I
just
don't
think
it's
a
mandatory
thing
that
we
need
to
worry
about
because
we
don't
run
qa
today
after
deploys
right.
F
Like
I
think
in
general,
if
we're
suffering
some
sort
of
outage,
the
first
thing
that
we're
going
to
be
checking
is
something
related
specific
to
that
outage
and
qa
is
not
built
with
hey.
Here's
an
outage,
let's
test
for
this
outage
or
test
for
this
degradation
yeah
until
qa
has
that
capability,
which
it
never
will,
because
outages
or
negativations,
are
all
over
the
place.
There's
no
way
to
test.
For
that.
F
That's
going
to
be
the
first
thing
we
look
for
so,
if
there's
a
rollback
procedure,
if
we're
going
to
put
something
in
the
procedure
validate
that
we've
remediated,
that
incident,
whether
that
be
via
a
qa
test
or
whether
that
be
some
manual
handling
or
just
waiting
for
metrics
to
come
through
and
tell
us
that
we're
okay
or
not.
That's
realistically,
in
my
mind
what
the
solution
she
really
should
be.
C
B
C
With,
like
I
don't
know,
probably
just
at
a
minimum
running,
the
smoke
test
is,
but
they
don't
need
to
be
blocking
at
all.
I'm
also
curious.
This
is
probably
a
different
conversation,
but
like
say,
we
did
run
qa
and
something
geared
up.
What
do
we
even
do
with
that
situation?
Do
we
roll
back
a
roll
back.
B
I
think
your
rights
go
back,
I
kind
of
like
the
idea
of
running
something
just
because
I
think
the
biggest
challenge
we're
going
to
face
with
rollbacks
is:
do
people
trust,
rollbacks
and
I
think,
having
the
tests
be
able
to
tell
us
something
is,
is
working
as
it
was
like
it
should
always
just
be
like
they
passed
before
they
pass
again
and
all
good,
but
I
kind
of
like
the
idea
that
we
might
have
something
additional
that
if
people
are
oh,
how
do
we
know
this
rollback
did
its
thing.
B
We
can
say
we
have
like
all
the
metrics,
but
also
let
the
qa
test
the
passing.
So
we
know
we
can
trust
the
metrics.
I
just
wonder
how
many
extra
kind
of
confident
points
we
might
want
to
be
able
to
give
for
a
rollback.
D
E
So
oh
yeah
yeah
go
ahead,
so
if,
if
you
run
a
rollback,
then
probably
because
something
and
production
failed
right
and
we
need
to
roll
back
and
we
already
have
a
lot
of
attention
on
whatever
was
breaking
right.
So
we
roll
back
because
something
is
broken
and
when
we
roll
back,
then
probably
a
lot
of
people
are
checking
anyway.
If
we
are
recovering
from
the
status
and
we
roll
back
to
something
which
worked
before
our
right
or
at
least
where
we
know
the
failure
cases
before.
E
So
it's
really
about
testing
for
outages
or
not
right,
and
for
that
as
except
you
should
have
metrics
and
alerts
already.
So
I
think
it's
it's
strange
to
to
run
tests
again
against
production,
because
I
think
the
idea
of
testing
is
to
prevent
something
coming
into
production,
which
is
broken
right.
So
it
should
happen
before
that.
B
I
don't
know
I
I
I'm
not
sure
I
agree
like
I
think,
maybe
not,
maybe
not
the
full
sweep
but
the
smoke
test.
I
think
I
like
everything's
generally
working,
because
I
think
what
we
don't
know
is
application.
I
guess
the
scenario
that
we
are,
I
assume,
will
hear
at
some
point.
Certainly
it's
a
big
unknown
is
the
application
code
that
doesn't
roll
back
cleanly
and
that
won't
necessarily
be
the
thing
we're
doing
the
roll
back.
D
Just
say
the
thing
that
I
want
to
say
so
and
also
henry
doubled
down
on
this,
because
basically
so
we
are
now,
we
are
discussing
testing
a
rollback
which
is
something
where
it's
kind
of
a
self-inflicted
pain,
and
so
I
understand
the
need
for
running
a
qa
at
the
end,
because
you
want
to
make
sure
that
everything
is
still
fine
because
it
wasn't
broken
before
so.
On
that
regard
I
reached
out
to
qa
asking.
D
This
as
part
of
the
our
testing-
but
I
will
not
put
this
in
the
in
the
automation
for
for
also
another
reason.
On
top
of
that,
first
one
is
okay.
Everyone
is
already
watching
at
the
problem
at
hand,
because
this
didn't
start
out
of
nothing.
So
there
was
a
real
problem.
Someone
knows
it
and
everyone
is
working
for
fixing
that
one.
So
we
already
have
a
matrix
that
tells
us
if
the
rollback
was
successful
in
terms
of
resolving
that
out
the
specific
outage.
D
This
is
something
then
it
may
introduce
another
outage,
but
that's
not
a
problem
and
then
would
be
another
incident
and
then
would
be
up
to
on
calls
and
release
managers
figuring
out,
which
one
of
the
two
outage
is
best
to
have,
because
guess
what
this
is,
what
we
have
right,
so
you
can
choose
outage
one
or
out
hb
and
and
then
either
you
move
forward
again
or
you're
back
to
yeah.
You,
you
deal
with
the
small,
let's
say
with
one
of
the
two
outages
and
try
to
move
forward.
Fine.
D
There
was
an
extra
thing
that
I
want
to
point
out,
which
is,
I
think,
qa
can
be
dangerous
because
we
don't
know,
I
mean
right
now
ahead
of
time.
We
don't
know
what
type
of
outrage
we
are
rolling
back,
so
it
may
be
one
of
those
outages
that
is
putting
stress
on
the
system,
and
so
it
takes
a
longer
time.
So
you
we
basically
when
we
start
rolling
back,
we
can
see
that
the
matrix
whatever
is
trending
down,
but
it's
still
maybe
there's
a
long
queue
of
failed
job
on
sidekick
whatever.
D
B
Yeah,
maybe
so
yeah
I
mean
I
was
going
to
say
actually
the
the
concern
I
had
mostly
was,
as
the
tests
are
running
scheduled
like
I,
I
could
imagine
if
we
ran
two
lots
at
the
same
time.
That's
interesting
stuff
could
certainly
happen
so,
okay,
but
I
do
think
we
should.
B
We
should
add
into
our
we
should
add
somewhere
into
the
documentation,
maybe
that
we
have
these.
We
can
run
the
scheduled
job
because
I
think
there
will
be
times
where
we'll
be
asked
like
you
know,
how
confident
are
we?
We
can
just
trigger
the
tests
and
be
sure
so
that
makes
sense.
B
B
Cool
does
that
make
sense
so
robert?
Does
that
make
sense
to
you
that
we
just
run
it
scheduled
if
we
want,
if
we
have
one
extra
checks.
B
It
has
the
added
benefit
that
we
could
also
maybe
add
a
step
just
let
quality
know
if,
when
we
do
that
manual
trigger
so
that
they
don't
get
surprised
if
results
come
in,
so
we
should
probably
add
those
two
steps
to
our
our
run
book.
B
B
A
Yep,
so
I
prepared
the
change
request
for
testing
a
rollback
in
dry
run
mode
and
well,
if
you
want
to
take
a
look,
there
is
the
issue.
I
do
have
some
questions
about
it
for
performing
a
rollback
in
dry
run
mode
like
we
just
need
to
add
the
flash
like
dry
run
into
the
command.
Is
that
all
that
we
need
to
do.
D
F
D
A
Okay,
that
is
easy
to
remember.
Okay,
okay,
thanks
and
I
do
have
another
question
about
who
should
be
the
change
reviewer?
It
is
not
clear
he
should
be
like
always
the
sre
on
call,
or
it
should
be
someone
from
the
team
or
it
doesn't
really
matter.
E
I
think
it's
good
if
it's
somebody
who
has
a
little
bit
of
context
to
this,
to
be
able
to
review
it
right
and
the
sier
on
call
typically
is
loaded
with
other
things.
So
for
doing
the
initial
review.
I
think
it
should
be
just
somebody
with
a
little
bit
of
context.
It
could
be
any
sre
if
you
look
at
the
exchange
management
process
documentation
in
the
handbook.
E
It's
just
saying
that
you
should
you
know
let
the
sree
on
call
review
this,
but
I
think
that's
that
should
be
changed,
maybe
or
clarified,
because
for
c1
c2
and
c3
have
c3
criticality
changes.
You
basically
just
need
the
approval
of
the
sae
on
call
when
you
want
to
execute
it,
but
for
really
reviewing
it
thoroughly.
I
think
you
should
ask
somebody
else.
I
think
that's
better.
Also
for
the
sreon
call.
D
Yeah
when
I
was
looking
at
the
process
for
doing
the
because
there's
another
issue
about
the
production,
not
the
dry
run,
but
the
original
idea
of
running
directly
production,
it
was
reviewed
by
jarv
and
was
part
of
the
process
that
just
one
s3
can
review
it.
But
then
you
need
the
on.
Basically
when
you,
when
you
pick
a
schedule,
when
you
pick
a
shadow,
you
should
see
who's
on
call
on
that
shift
and
then
you
need
his
approval,
which
is
not
a
full
review
of
every
single
step,
but
it's
more
about.
B
For
this
one,
I
would
say
that
I
like
henry-
maybe
it's
worth
you
reviewing
just
checking
it's
all
good
like
we
should
get
marin
to
be
the
actual
approver
of
this
and
make
sure
that
he's
happy.
We've
got
all
the
things
in
place
for
this,
so
I
think
when
we're
happy,
the
cr
is
ready
from
our
side.
We
think
it's
ready
for
approval.
We,
like
I'm,
happy
to
ping
over
to
him.
I
think
it's
probably,
I
think
the
cr
looks
good.
B
D
D
I
mean
it's
just
a
summary
table,
so
the
full
content
even
already
summarized,
is
there.
So
I
I
really
don't
know
there
is
something
worth
mentioning
because
I
was
checking
back.
My
old
issue
and
part
of
the
checklist
is
that
staging
test
was
executed
and
note
from
the
result
was
taken
into
the
issue
as
well
as
dry
run
is
actually
part.
So
we
are
doing
something
strange
here
because
we
are
creating
another
change
because
for
the
dry
run
when
it
is
kind
of
part
of
the
main
production
one.
But
I
mean
it's
no
problem.
D
B
B
Cool
okay,
so
yeah,
I
think
we
need
once
we've
got
the
table.
I
think
henry.
If
you
want
to
do
the
sort
of
delivery,
sre
check,
then
probably
pretty
good,
hopefully
to
ask
ask
marina
his
thoughts.
What
for
his
thoughts
on
this
one.
E
B
B
B
B
B
So
maybe
one
thing
that
might
be
worth
just
sort
of
sharing
kind
of
thoughts
that
I
had
and
see
if
other
people
agree,
which
is
so
we're
getting
kind
of
close
now,
hopefully
the
dry
run
will
be
super
boring
just
work
as
expected,
and
then
we
can
plan
a
real
production
test.
B
And
that
will
hopefully
give
us
a
pipeline
that
we
are
happy,
we
know
works,
it
does
roll
backs
and
then
there's
maybe
a
period
of
time
after
that,
where
we
look
for
incidents
that
are
suitable
candidates
for
rollbacks
and
try
and
reuse.
This
pipeline,
like
where
we
can
on
incidents
to
kind
of
build
our
confidence,
build
other
people's
confidence,
and
then
we
could
use
that
to
kind
of
move
into
the
next
step
of
like
what
does
more
automated
rollbacks
look.
D
D
Yeah,
I
think,
sounds
good.
Maybe
it
probably
is
going
to
be
boring
to
watch
this.
Maybe
we
will
have
some
fun
in
the
prepared
job.
I
think
probably
there
is
the
only
part
where
I
mean
I
would
say
not
the
only
part
because
who
knows,
but
you
know
it's
likely
that
maybe
something
is
different,
because
the
prepared
job
may
be
different
because
now
we're
going
to
cancel
something.
D
B
B
D
E
B
Yeah,
it's
a
good
point.
It's
a
good
point.
It
is
a
good
point
on
timing,
though
right,
because
for
this
one
we're
a
little
bit
more
around
employees
right.
So
how
do
we
want
to
hand
like
assuming
we
can
get
all
this
stuff
wrapped
up
and
like
ticked
and
approved
like
before,
okay
say
like
too
late
tomorrow
morning?
B
How
do
people
feel
about
us
just
going
with
the
first
point
that
we
can
so
like
say
we
get
a
deployment
goes
through
and
we
know
we
can
go
ahead.
So
we
pause
the
post
deployment
migration
and
then
we
have
like
a
window
or
do
people
want
to
try
and
schedule
this
and
then
we're
around
and
can
do
it
like?
How
do
you
want
to
handle
this.
B
We
won't
be
waiting
for
a
package,
though
right
because
we'll
be
pause
there,
we'll
we'll
know,
there's
a
like,
potentially
fine
deployment,
so
say,
for
example,
like
first
thing
tomorrow
morning
we
go
okay,
great
we're,
not
doing
a
release.
We
have
a
deployment
going
on.
We
pause
the
package
and
then
see
it's
just
incidents.
We're
waiting
on
then.
B
D
D
B
Okay,
so
let's
just
go
for
it.
If
we,
if
we
get
it
because
I
I
think
from
a
kind
of
site
traffic
point
of
view,
the
least
risky
time
for
us
to
do.
It
is
going
to
be
in
emir
morning
when
we
have
sres
online,
but
we
don't
have
all
of
the
site
traffic,
but
it's
a
little
bit
dependent
in
the
morning
week.
We
often
have
some
complexities
under
like
it
depends
what
happens
overnight
for
the
deployments.
B
So,
okay,
let's
get
this
reproved
and
then
first
deployment
that
we
see
that
looks
like
a
possibility.
We'll
just
go
ahead
and
try
and
do
it
and
whoever's
available
can
join
and
we'll
record
it.
And
then,
even
if
just
like
a
couple
of
people
say,
let's
definitely
have
two
people
watching
this
and
we'll
record
it
and
everyone
else
can
either
try
later
or
watch
the
video.
F
E
D
In
any
case,
we
need
release
managers
support
because
they
are
the
one
that
are
promoting
the
regular
production.
They
have
the
the
knowledge
about
the
status
of
production
and
so
on.
So
they
are
the
ones
who
make
the
call
if
they
can
cancel
or
not
the
thing
so
now,
uric
is
not
here,
but
for
india
morning
housing,
but
maybe
you're
the
same
way
he
did
today.
They
just
notified
media
there's
no
way
we're
gonna
do
this,
because
we
are
still
doing
the
deployment
of
the
security
release.
D
Maybe
this
is
something
that
robert
and
your
could
take
care
of.
Just
they
just
say,
notify
the
other
team
members
that
are
usually
working
in
the
time
zone.
So
yeah,
I'm
gonna,
start
a
production
deployment.
Now
everything
looks
fine,
so
maybe
I
can
cancel
it.
Are
you
available
to
run
the
roll
back
in
whatever
two
hours
time,
because
more
or
less
time
is
that
one?
Because
we
we
want
the
promotion
to
complete,
maybe
wait
a
bit
of
time.
D
B
That's
a
good
point,
and
I
don't
we
actually
don't
have
to
rush
it.
So
how
about
we
say
that,
then
we
will
schedule
it
loosely
in
that
we'll
it
doesn't
actually
matter.
I
think
if
we
like,
cancel
the
post-deployment
migration,
it's
absolutely
fine!
If
we
then
have
four
hours
before
we
do
the
rollback
right,
that's!
Okay!
So
how
about
we
get
uric
in
the
morning
to
watch
for
a
suitable
deployment?
B
He
can
give
us
a
shout
we'll
know
the
earliest
point.
We
can
do
the
roll
back,
we'll,
try
and
schedule
something
then
like
early
in
the
day
for
early
in
the
afternoon,
around
two-ish,
utc,
right
so
or
two
or
three-ish
right,
so
that
we
can
try
and
have
as
many
people
involved
as
possible,
cool,
okay,
we'll
shout
about
that
stuff
on
slack,
so
yeah
we'll
get
uric
to
be
the
kind
of
initial
trigger
and
then
based
off
that
we
can
agree
on
what
the
schedule
looks
like
awesome.
A
B
Wanna,
how
much
of
the
table
do
you
want
to
have
in
place
already
for
that
alessio
actually.
D
Yeah,
that's
that's
that
was
going
to
suggest
so
I
had
still.
I
have
30
minutes
before
my
days
and
so
I'm
I
have
no
other.
I
mean
it's
top
of
my
to-do
list,
so
I
would
just
start
working
on
this
now,
but
even
just
having
title
change
and
the
summary,
it
really
points
out
that
all
the
tests
we
did
right
so
exactly
yeah.
B
B
Super
graceof,
let's
reconvene
tomorrow,
hopefully
cool,
speak
soon,.