►
From YouTube: 2021-02-16 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
All
right
well
welcome
everyone.
Thank
you
for
joining.
We
are
going
to
perform,
hopefully,
a
rollback,
and
in
this
hypothetical
situation
we
are,
I
guess,
on
an
s1
or
an
s2
incident,
and
what
we
want
to
do
is
to
roll
back
to
the
previous
stable
package.
A
So
now
the
first
thing
that
I
want
to
do,
the
now
that
we
want
to
roll
back
is
like
well,
we
need
to
find
the
documentation
right,
so
I
don't
have
it
handy,
so
I'm
guessing
I
can
just
how
to
perform
a
rollback
in
gitlab
and
what
this
is
the
official
documentation.
So
I
don't
want
that.
So
I
don't
want
that.
A
A
Run
books
what
to
do
in
case
of
an
incident.
This
might
be
it.
A
A
A
A
So
right
here
is
just
saying
that
we
can
perform
a
roll
back,
but
it
is
assuming
a
bunch
of
things.
It
is
assuming
that
we
know
the
package
with
in
this
point.
We
don't
so
I
guess
I'm
just
going
to
return
to
the
index,
because
I
already
read
me
because
I
recall
that
we
just
wrote:
oh
here
it
is
so
it
is
on
the
last
commit.
A
A
A
A
A
A
A
A
A
A
A
So
I
guess
there
is
no
very
easy
way
to
do
this
bunch
of
javascript,
I'm
just
going
to
use
those
or
even
better
db.
A
A
A
A
A
You
should
see
a
single
tach
and
yes,
we
have
a
single
tag,
so
it
is
possible
for
more
than
one
tag
to
be
displayed.
In
that
case,
you
should
pick
the
most
recent
tags,
so
this
is
not
the
case.
We
only
have
one
tag
and
to
obtain
the
package
version.
We
need
to
replace
the
symbols,
because
this
is
omnivo
syntax,
and
we
don't
want
that.
A
D
A
D
A
Well,
I
can
see
that
the
pipeline
is
already
smaller
is
not
including
the
assets
job,
nor
the
migrations,
which
is
good,
so
it
should
be
faster.
This
time,
I'm
not
sure.
A
A
A
Well,
in
that
case,
unless
you
have
the
first
point.
B
B
Okay,
well,
I
will
imagine
you
are
here
and
just
keep
talking,
so
I
did
a
bit
of
reorganization
of
the
issues
and
epics.
So
I
think
we
have
three
main
entry
points
here.
One
is
the
pipeline
for
called
rollback,
which
is
basically
about
everything
we
are
doing
so
far.
So
it's
about
the
having
a
pipeline
that
can
roll
back
and
having
round
books
and
every
having
proper
documentation.
So
that's
the
notes
from
this
meeting
so
far
have
been
converted
in
issues
in
there
and
that's
something.
B
Then
we
have
the
assisted
rollback,
which
is
the
parent
epic,
for
that
one
which
is
more
about
the
automation
in
itself.
So
is
how
can
we
prevent
deployment
to
reach
post
deployment
migrations
if
we
are
unsure
about
the
safety
or
things
like
that,
or
how
can
we
stop
an
ongoing
deployment
and
notify
release
managers
to
yeah?
This
is
drawback
options,
or
maybe
just
continue
so
this
type
of
thing.
B
B
So
there
are
some
something
that
we
will
need
from
phase
two
to
actually
have
a
rollback,
assisted
broadband
as
an
option,
so
we're
talking
about
splitting
staging
from
canary
and
production
and
so
having
baking
time
and
this
time
kind
of
things
inside
release
tools
so
that
we
can
interleave
our
new
checks,
like
attempting
say
stopping
before
positive
migration.
Things
like
that.
So
that's
basically
the
the
three
main
point:
the
that
we
need
for
rollbacks.
B
A
Yeah,
so
this
one
was
kind
of
an
easier
scenario,
because
the
staging
was
well
not
being
utilized
at
least
for
development,
but
I
wonder
if
we
want
to
roll
back
to
a
certain
environment
and
we
have
an
ongoing
deployment
at
that
moment
like
what
should
we
do?
Should
we
cancel
that
deployment
and
roll
back,
or
should
we
wait
for
the
deployment
and
then
roll
back.
B
Well,
it
is
causing
an
outage.
We
suspected
we
stopped
rolling
out
right.
We
don't
want
to
increase
it.
I
suspect,
but
I
think
that
we
may
need
jarv
help
here
or
maybe
scarborough
if
he
knows
about
it,
so
the
the
the
broken
link
that
we
found
again
today,
the
one
linking
to
the
sri
rambook.
I
suspect
it
is
about
this
use
case
here,
because
what
I'm
thinking,
maybe
scarbec,
you
can
double
check.
My
my
assumptions
here
is
that
when
we
start
rolling
out,
we
remove
machines
from
the
load
balancer.
B
So
in
the
event
of
breaking
something
within
the
deployment
it
either
either.
If
we
stop
it
manually
or
if
the
pipeline
breaks
for
some
reason,
then
we
will
not
be
able
to
run
another
deployment,
because
if,
at
the
beginning
of
the
deployment
we
check
for
the
status
of
the
the
fleet
compared
to
load
balancer
and
those
things
will
be
messed
up,
and
so
we
just
say
no,
I'm
sorry,
I'm
not
going
to
the
check
phase,
the
first
one
we
said.
No,
we
can
deploy
just
try
to
figure
out
what
happens
here.
B
So
my
understanding
is
that
that
link
was
supposed
to
link
to
something
explaining
this,
but
I'm
not
sure.
So
definitely
we
need
to
fig
clear
this
thing
and
figure
out.
How
can
we
automate
this?
Because
if
we
want
to
automate
rollback,
we
don't
need
to
ask
a
necessary
to
put
machines
back
into
whatever
the
right
state
is
supposed
to
be
so
that
thing
does
this
answer
your
question.
A
Yeah
it
does,
I
guess
we
might
need
an
additional
preparation
step
to
make
sure
that
perhaps
those
steps
that
you
just
described
are
included.
D
Do
you
want
to
talk
alessia
a
little
bit
about
so
we've
got?
We've
had
some
suggestions
for
more
how
we
can
improve,
run
books
and
things
like
what
are
the
next
big
steps
for
for
rollbacks
or
or
for
single
pipeline.
B
So,
do
you
mean
outside
of
updating
the
drum
books
and
so
we're
talking
about
yeah.
D
Okay,
because
I
mean
I'm
kind
of
like
if
it
feels
like
we're
quite
close
to
having
something
which
at
least
on
staging,
we
could
we
could
run
so
yeah.
What
are
the
next
pieces.
B
B
So
I
just
want
to
tell
all
of
you
that
today
and
I
don't
know
how
well
how
this
happened
or
what
it
is.
I
discovered
the
top
groups
in
this
thing
here,
which
is
amazing.
I
don't
know,
I
don't
know
so
that
I
can
back
things
together
and
collapse,
all
of
them
and
it's
shipped
with
good
with
chrome.
So
it's
something
there's
no
extension.
It's
just
chrome.
B
It
basically
changed
my
life.
So
back
back
to
the
matter
of
hand,
rollback
so
zoom.
What
have
you
done?
Oh
jesus
zumbar
just
got
funky
here,
so
let
me
try.
So
I
think
that
okay,
so
in
assisted
rollback,
my
impression
here
is
that
what
we
need
the
most
is
this
one,
so
detecting
positive
climate
migration.
B
Now,
why
I'm
talking
about
this?
Talking
about
this,
because
scarborough,
not
scarborough
robert,
did
the
the
script
that
we
checked
today.
But
there
is
it's
very
handy,
and
I
love
that
we
have
that
one,
but
is.
B
We
need
to
start
thing,
not
really
thinking
but
experimenting
this,
so
we
have
a
way
forward
here,
which
is
the
current
situation.
Is
this
one?
So
we
have
a
stage
in
release
through
the
tags,
then
we
have
a
stage
that
do
the
waiting
and
then
we
have
a
final
stage.
The
triggers
and
this
three
is
triggering
on
deployer
master.
B
So
it's
a
real
deployment.
We
have
another
branch
which
is
next-gen,
which
is
a
force
to
check
mode.
So
whatever
we
triggered
there,
it
will
never
run
real
deployment.
We'd
just
be
check
mode
deployment,
so
I
think
that
we
should
start
working
on
something
like
this
in
parallel
to
the
current
situation.
B
So
my
goal
is
that
we
have
a
stage
when
we
attack
a
stage
when
we
wait
and
then
there
is
a
stage
where
we
triggered
the
old
deployment
on
master
and
in
parallel
we
trigger
staging
the
staging,
only
deployment
on
next-gen
branch
and
then
in
the
next.
In
the
next
stage
of
the
pipeline
we
trigger
a
canary
one.
B
Then
we
move
production
checks,
so
sorry,
making
time
and
yeah
breaking
tank
checks,
basically
in
release
tools,
and
then
we
trigger
production
so
that
we
can
see
if
the
refactoring
that
we
are
doing
actually
works
in
a
safe
environment,
because
we
are
just
running
check
mode
ansible
in
check
mode.
So
it
does
nothing.
You
just
compare
the
status
of
the
machines.
D
D
So
this
is
going
to
be
one
of
our
first
projects
we've
had
in
a
while,
where
the
pieces
of
work
are
big
enough,
that
it's
not
just
one
project
for
everything,
and
it's
also
enough
pieces
that
we
can
do
in
parallel,
so
that
lots
of
people
can
work
on
this
stuff.
So
eric.
I
know
you're
heading
into
release
management
myra,
as
you
rotate
out
over
the
next
couple
of
weeks,
like
it'd,
be
great
to
get
you
kind
of
owning
some
of
these
bigger
pieces.
D
I
want
to
see
what
robert
can
pick
up
as
well.
He's
obviously
heading
into
release
management
as
well,
but
just
to
kind
of
share
they'll,
hopefully
be
enough
kind
of
like
these
pieces
will
be
large
enough,
that
they
will
have
their
own
investigation
and
we'll
need
to
work
out
like
what's
involved
and
there'll,
be
tasks
that
we'll
need
to
break
out
from
this
and
and
schedule
so
yeah
they're
sort
of
mini
pieces
like
not
projects
but
they're
they're,
bigger
than
hey,
put
a
future
flag
on
this
thing.
D
D
What
do
we
want
to
try
and
have
ready
for
a
demo
next
week?
So
I
think
this
worked
really
nicely
that
we
had
a
load
of
runbook
changes
that
uric
you
put
in
last
week
after
going
through
the
demo,
which
was
super
awesome,
robert
put
in
the
new
command,
which
was
awesome,
let's
see
how
you've
ripped
out
a
load
of
stuff
from
the
pipeline,
which
is
also
awesome.
D
F
Yeah,
I
see
two
potential
items
here.
One
is
further
documentation
updates.
You
know,
we've
got
this
excellent
chat,
ops
command
that
robert
has
rolled
out
and
it
works
very
well.
Alessio
has
pointed
out
that
he
also
would
not
trust
that
tool
during
a
rollback
in
production.
I
would
like
to
see
that
issue
worked
on.
B
Let's
remove
let's
remove
italy
first,
it's
safer
if
gilly
is
outside
of
the
of
the
equation,
because
I
don't
trust
that
part
now.
D
C
I
have
a
dumb
question:
is
a
rollback
basically
the
same
thing
like
a
roll
forward
like
a
deployment,
but
we
leave
certain
things
out
right
I
mean
I
was
thinking.
If
you
would,
if
you
would
switch
the
release
numbers,
could
we
use
a
rollback
to
roll
forward
instead
of
doing
a
normal
deployment.
B
C
B
The
thing
is,
the
only
thing
that
we
have
is
that
during
regular
roll
forward
we
do
gizzary
first
and
then
the
fleet
during
a
rollback.
We
do
fleet
first
and
easily
after,
but
we
are
discussing
about
removing
easily
and
having
this,
let's
say
as
a
manual
job
ready
as
soon
as
we
roll
back
the
fleet.
So
in
theory
it's
either
doing
this
first
or
after
it
should
be
fine.
But
what
we
are
the
thing
we
just
no,
we
discussed
a
couple
of
weeks
ago
so
before
you
joined.
B
So
what
we
are
suggesting
here
is
that
deltas
are
smaller
enough
to
assume
that
easily
is
backward
compatible
because
it
usually
this
is
the
case.
Also.
We
just
upgrade
digitally
without
much
problems,
so
it
tends
to
be
very
backward
and
forward
compatible.
So
our
best
option
is
to
say:
don't
run,
don't
mess
with
easily
in
case
of
an
outage,
but
have
the
options
to
eventually
roll
back
that
as
well.
A
B
D
A
D
A
D
C
Most
broken
links
are
just
moved
into
the
uncut
uncut
edge
raised.
I
can't
spell
it
out
directory
in
the
runbook
docs
directory.
C
B
D
D
B
The
remediation
steps
are
not
entirely
clear
and
could
use
some
of
the
dates.
Improved
re
readability,
so
because
this
is
about
the
severity
one
incident,
because
when
we
first
wrote
this,
we
we
started
from
severity.
One
incident,
so
I
would
say
this
is
this
is
no
longer
the
case,
because
now
we
have
a
real
runbook
for
the
it's
just
that
it's
not
linked.
So
it's
a
bit
hard
to
find
so
we
tick
this.
B
We
are
missing
a
way
to
appropriately
and
concisely,
determine
if
there
are
blockers
that
will
prevent
us
from
being
able
to
perform
the
rulebooks.
This
is
no
longer
true,
but
we
need
to
update
the
drama
because
we
have
the
script,
which
gives
us
a
good
understanding
and
yeah.
So
I
was,
I
would
suggest
so
I
don't
know
who
will
take
this
issue
of
updating
it
not
to
delete
the
procedure
because
it's
extremely
valuable,
just
remove
it
from
the
critical
path
put
it
down
down
below
in
the
rambo
core
in
another
places
and
link.
B
A
C
The
docs
directory
and
run
books
and
then
uncut
texturized.
C
B
B
Yeah
yeah,
I
I
think
that
maybe
the
intention
here
was
something
like
delivery.
Team
thinks
that
they
have
to
roll
back,
and
so
this
is
how
they
start
but
yeah.
I
I
agree
with
you.
This
is
not
the
case
now
I
was
hoping
to
find
some
reference
to
the
machine
being
outside
of
the
balancer
things
like
that.
But
nothing
is
here.
B
E
E
B
Okay,
so
we
can
improve
this
run
book
with
better
instruction
and
worrying
about
post-deployment
migration.
I
I
think
this
is
the
thing
that
this
is
the
point
that
also
myra
pointed
out
today
that,
because
this
round
book
here
refers
to
the
severity
one
incident,
because
it
is
the
one
that
we
were
running
the
first
time
and
it
still
refers
to
having
background
migrations
and
it
should
be
more
general.
D
I
think
we
should
maybe
review
that
whole
runbook,
because
it's
quite
old
and
it
doesn't
really
fit
in
with
our
new
like
the
way
we
manage
incidents
like
it's
got
some
useful
pointers
in
it,
but
I'm
not
sure
I'd
dare
follow
much
of
it.
G
D
B
They
had
a
specific
problem
with
background
migrations,
but
it
was
not
safe
delivery.
They
didn't
have
the
right
back
as
a
delivery.
Team
has
a
roadblock
in
mind,
so
it
was
just
a
specific
problem,
so
I
think
we
can
just
ascend
that
and
make
sure
that
all
the
relevant
information
are
linked
together.
B
E
H
B
D
Maybe
if
robert
has
time
when
he
thaws
out
you
missed
it,
marion
he's
he's
in
an
ice
storm
she's,
very
un
texas,.
D
I
think
it's
the
back
story
so
yeah
until
he
until
he
throws
out.
We
won't
see
much
of
him.
H
D
Okay,
well,
let's,
let's
get
that
on
the
board,
then
so
the
next
time
we've
got
a
few
little
documentation
things
we
can
tweak
on,
but
the
next
issue
to
pick
up
is
the.
B
Yeah
this
is,
I
mean
these
are
the
the
smallest
thing
with
the
weekly
demo.
If
we
want
to
start
working
on
something
say
more
long
term,
there's
the
understanding
the
presence
if
there
are
post
deployment
migration
so
that
we
can
automate
so
checking
the
status
with
the
database
as
well
as
starting
splitting
the
release
trigger
yes
deploy,
triggering.
F
F
Now
they
need
to
ma.
They
may
need
to
touch
that
database
migration
again,
that
might
conflict
with
the
old
migration
like.
Maybe
this
is
just
a
checklist
of
if
your
mr
was
reverted
to
fix
something
you
need
to
re-review
the
database
migrations.
But
the
problem
that
I
have
right
now
is
that
the
database
is
not
going
to
reflect
reality
and
a
developer's
workstation
is
not
going
to
reflect
the
same.
H
So
I
think
that
the
process
that
we
sort
of
historically
have
taken
with
reverts
that
involved
migrations
is
that,
typically,
you
turn
the
old
migration
into
a
no
op.
So
you
just
remove
the
code
from
the
up
and
down
method,
and
then
you
have
to
create
a
new
migration
that
perhaps
runs
the
same
thing
but
checks
hey.
H
If
it
did
succeed
properly,
you
know
don't
run
it
there's
actually
a
good
example.
I
ran
into
recently.
H
H
B
Database
documentation,
this
is
defined
and
yeah.
A
H
Yeah,
let's
see
so
I
have
some
migration
guys
open.
Let's
see
if
any
mention
of
no
mention
of
revert,
but
there
is
reversibility
that
says:
oh,
if
you
can't
revert
it,
do
this,
but
that's
just
where
you
introduce
the
migration
and
there's
no
way
to
undo
it,
at
least
in
the
migration
style
guide.
I
cannot
find
a
mention
of
this
migration
referred.
H
H
B
H
Yeah,
so
so
it's
documented,
but
not
quite
the
way.
I
think
you
would
expect
like
there's
nothing.
That
says
if
your
merch
request
is
reverted
and
here's
the
process
for
migrations,
so
you
might
wanna.
You
know
pass
that,
along
with
the
database
team
yeah
either
way
to
answer
skype
the
process.
Basically,
you
turn
it
into
no
hope
and
then
you
sort
of
start
over.
B
B
B
So
I
would
not
be
scared
of
code
implications
because
when
we
start
deploying
to
cannery
it's
it's
in
reverse,
but
it's
the
same
thing
when
we
start
applying
to
kennedy,
we
run
migrations
but
for
hours,
main
stage
is
still
running
the
old
version,
so
it
is
exactly
the
same
in
terms
of
code
running
and
database.
State
is
exactly
the
same
situation.
D
A
How's,
the
roll
back,
we
are
still
executing
q
a.
I
think
it
is
going
to
take
some
more
minutes,
but
I
I
will
call
it
like
a
successful
demo
today,
because
we
actually
did
a
rollback
so.