►
From YouTube: 2021-10-18 Staging improvements and the impact on the single pipeline project discussion
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).
B
B
A
Yes,
so
they
are
kind
of
a
different
thread
of
of
the
staging
improvements
project,
so
they
haven't
necessarily
been
been
synced
up.
We
probably
expect
staging
ref
to
start
getting
deployments,
maybe
next
week,
it's
quite
soon,
so
that
will
be
it
yeah.
It's
not
because
we've
been
waiting
on
anything
in
particular
just
that
the
staging
ref
project
required
kind
of
other
work
to
get
a
get
environment
up
and
understood,
and
things
versus
the
staging
canary
project
was
pretty
trivial
to
stand
up
the
canary.
A
B
You
and
then
another
question
that
I
have
is
about.
There
is
an
issue
associated
to
this
epic,
about
changing
the
order
of
the
deployment,
and
there
is
like
this
picture
that
basically
states
actually
number
three
of
the
option
for
aesthetic
states
states
that
production
and
staging
are
going
to
be
deployed
almost
in
sync
staging
a
bit
ahead.
But
my
question
is:
we
are
going
to
still
use
the
baking
time
right
and
baking
time
is
going
to
be
triggered
after
the
deploy
to
the
canary
to
production,
canary
yeah.
A
Production
tannery,
I'm
actually
not
sure
this
is
probably
a
bit
of
an
implementation
detail,
so
though
there
may
so,
I
suppose
the
way
to
think
about
this
one
is
staging
and
production
need
to
have
the
same
package
in
order
to
maintain
mixed
deployment.
Like
consistency,
should
I
say
so
in
order
to
achieve
that,
staging
production
get
the
same
package
deployed
to
them,
but
we
don't
want
to
be.
We
want.
We
want
customers
to
know
that
we
deploy
to
our
staging
environment
before
our
production
environment.
A
A
If
we
didn't
put
that
same
package
on
production,
we
would
need
to
roll
staging
back,
because
otherwise
we
lose
our
version
consistency.
So
I
think
what
the
probably
the
end
iteration
like
the
ideal,
perfect
state,
would
be
that
staging
probably
starts
deploying
and
maybe
like
10
minutes
later,
production
starts.
You
know
so
it's
just
behind,
but
whatever
the
sensible
cuts
are
inside
the
job,
so
graham
will
probably
figure
this
out.
A
B
B
B
I
think
you
recorded
it
a
couple
of
weeks
ago
in
which
you
had
a
discussion
with
alessio,
even
with
mac
and
with
nyla
and
then
well.
They
were
saying
that
executing
staging
in
production
roughly
at
the
same
time,
but
like
the
following.
The
benefits
of
ensuring
the
package
is
always
tested
against
multi-version
compatibility
and
that
staging
is
going
to
be
kind
of
a
true
production
environment
like
in
a
way
that
is
going
to
have
the
same
features
and
the
same
sort
of
the
same
database.
B
So
my
question
here
is
that
the
staging
that
you
are
referring
is
not
the
staging
that
we
have
right
now,
because
this
stage
that
we
have
right
now
that
the
database
is
very
different
from
production
right.
So
I
assume-
or
I
think
that
staging
that
you
are
referring-
is
the
new
stage
in
ref
or
is
the
current.
A
Staging
that
we
have
no
that's
a
great
question
yeah,
so
no
this
one
that
if
that
recording,
is
entirely
around
staging
and
staging
canary,
so
in
terms
of
the
database,
yes,
you're
right
in
terms
of
the
data
will
be
different
for
that
video
and
for
anything
to
do
with
ordering
of
deployments.
I
think
we
were
thinking
around
it
in
terms
of
changes
applied,
perhaps
rather
than
like
config
or
data.
A
Does
that
make
sense
so
like
when
we
say
staging
canary
and
staging
are
consistent,
we're
talking
about
they
get
the
same
package
in
the
context
of
that
video.
So
for
the
database,
what
we
were
talking
about
is
staging
a
production
database
being
equivalent
we're
saying
the
same.
Migrations
have
run
versus
it's
exactly
the
same
data.
B
Yeah
it
does
it's
just
that
one
part
of
the
video
I
think
it
was
set
to
mention
that
one
of
the
benefits
of
having
the
same
package
exactly
in
a
stage
and
in
production,
was
to
use
a
staging
as
a
true
production
environment,
and
if
we
are
still
using
the
current
database,
that
is
actually
not
true.
Yeah
you're
right,
yeah.
A
No,
in
that
sense,
it's
not
going
to
be
true
for
yeah
you're
right.
It's
not
going
to
be
true
for
testing
like
database
changes.
It
will
be
true,
for
I
think
if
I
remember
we
were
probably
talking
about
it
in
the
context
of
having
all
of
like
the
services
available,
all
the
components
available
and
what
that
will
mean
is
we
can
we
can
test?
We
don't
have
application
changes,
but
yeah
there
is
still
going
to
be
a
big
gap
on
the
test
data.
A
Just
because
what
this
all
of
these
changes
are
focusing
very
much
around
mixed
mixed
version
deployments,
so
I
think
the
data
on
staging
is
a
problem,
but
it's
a
sort
of
a
slightly
different
problem
in
that
we
don't
have
a
realistic
way
of
testing
migrations,
the
it's
non-trivial
to
change
the
data
on
staging
and
what
I
think
will
be
the
difficult
part
about.
It
is
the
fact
that
we
haven't
been
refreshing
it
for,
for
so.
B
A
Yeah
exactly
that
people
are
expected
to
be
stable,
which
means
a
lot
of
test.
Data
is
very
likely
to
have
been
added
in
and
relied
on,
so
we
would
need
some
way
of
finding
that
and
people
switching
to
like
either
having
test
data
in
production
that
we
would
then
keep
pulling
into
staging.
Or
you
know
if
we
were
just
to
refresh
it
today.
I
think
a
lot
of
tests
will
fail,
because
the
data
they're
expecting
won't
exist.
A
Okay,
it's
one
trivial,
but
I
think
it's
something
which
we
once
we've
done
the
so
I
think,
there's
probably
this
kind
of
ties
in
there.
There
are
two
more
phases.
Let
me
see,
I
think
so.
I
think
there
are
two
more
phases
of
staging
improvements
that
we
already
know
about.
That
will
come
after
staging
ref
and
after
the
staging
canary
project.
A
A
A
One,
the
next
one
is
most
likely
going
to
be
like
generate
staging
traffic,
yes
on
staging,
and
that
will
mean
that
we
can
actually
then
start
relying
on
alerts
and
actually
finding
a
lot
of
stuff.
So
that's
gonna
most
likely
be
the
piece
we
do
coming
next
and
then
it
will
be
consider
refreshing,
staging
data
that
one,
I
think,
is
a
little
question
mark,
because
I
think
what
we
haven't
fully.
A
A
People
have
admin
access;
it
is
something
that
can
be
spun
up
and
torn
down
as
needed,
which
means
we
don't
have
multiple
ones.
You
know,
there's
lots
of
benefits
to
staging
ref.
The
downside
of
staging
ref
is.
It
is
built
of
the
reference
architecture
and
on
our
current
kind
of
pipeline
of
infrastructure
changes.
We
go
to
the
pre-environment,
the
staging
environment,
production,
and
at
that
point
it
goes
into
the
reference
architecture,
which
means
from
the
infrastructure
point
of
view.
B
A
That
was
a
great
question.
We
don't
know.
Pierre's
gonna
have
to
figure
that
out,
because
what
he
has
so
the
only
decision
we've
made
right
now
is
that
it
will
deploy
alongside
staging
canary
from
our
from
a
time
point
of
view.
So
it'll
be
the
package
we
want
to
put
on
stage
and
canary
will
be
the
package
that
we
also
want
to
put
on
staging
ref.
That's
the
only
decision
we've
made
so
far.
Okay.
Now
there
are
some
problems
with
doing
that.
A
One,
of
course,
is
that
if
the
tests
fail
on
staging
canary
for
us
it's
a
canary
right,
so
canaries
we
just
drain,
we
don't
have
to
do
anything.
Staging
ref
is
an
environment
so
for
now
at
least
that
doesn't
matter
too
much,
but
I
don't
know
how
we
will
cover
staging
ref.
If
we
put
a
bad
package
on
it,
they'll
have
it'll
have
to
just
wait
for
the
next
deployment.
A
Is
the
kind
of
the
thing
we
need
to
like
at
some
point
figure
out?
It
doesn't
matter
too
much
at
this
stage,
but
in
the
future,
so
staging
canary
is
a
canary
environment.
We
deploy
a
package,
that's
the
earliest
point.
We
deploy
a
package
if
it
if
it
fails
or
there's
anything
wrong
with
it.
It's
a
canary
environment.
We
can
drain
the
traffic
out
of
that
no
problem.
A
So
what
we
need
to
in
the
future,
I
think
figure
out
for
staging
ref
is,
and
it
can't
I
mean
I
guess
it
could
be
drained
in
the
we
could:
dump
the
environment
and
re-spin
it
up
right.
It's
a
get
environment,
but
what
we
don't
know
is
when
we
put
a
bad
package
on
staging
ref,
we
have
no
way
of
rolling
it
back.
We
have
no
way
of
draining
it,
so
does
it
just
stay
broken
until
the
next
deployment?
A
I
don't
know
we
have
no
recovery
for
that.
We
haven't
figured
that
out
yet
why
we
cannot
run
work.
Staging
ref,
you
haven't,
got
any
tools:
okay,
okay,
like
this,
is
what
I
mean
we
haven't
at
this
stage.
We
haven't
got
any
so
the
kind
of
I
guess
the
timeline
of
not
primer
the
broad
pieces
of
the
staging
ref
project.
So
let
me
step
back
a
little
bit
so
context
for
this
project,
for
staging
improvements
is
mec
is
the
kind
of
overall
leader,
so
quality
are
kind
of
the
majority
stake
in
this
project.
A
A
So
now,
at
this
stage
of
the
project
staging
canary
is
fully
within
the
delivery.
Team's
ownership,
we're
the
only
ones
working
on
this,
defining
it
using
it.
So
we
we're
kind
of
the
complete
con
decision
makers
around
this
project
at
the
moment,
yeah
collaborating
with
quality,
but
in
terms
of
who's
deciding
what
order
of
task
and
how
to
go
about
that.
That's
fully
our
project.
A
Staging
ref
is
a
quality
project.
So
it's
a
little
bit
different
and
in
terms
of
the
infrastructure
side
of
things,
I'm
the
dri,
but
pierre
and
cindy
are
the
ones
doing
the
actual
work.
It's
not
a
delivery
project
and
that's
because
we
are
mostly
providing
infra
support
to
enable
quality
rather
than
it
being
our
environment
like.
I
don't
think
we
will
as
delivery.
I
don't
think
we'll
be
using
staging
ref
anytime
soon.
It's
quality
going
to
use
it
to
build
out
a
new
test
suite.
A
A
A
A
Maybe
in
three
four
weeks
where
a
package
must
be
deployed
to
staging
ref
plus
to
staging
canary,
it
must
pass
all
of
the
tests
that
quality
choose
to
put
it
through
on
those
two
environments
will
be
different
test.
Suites
must
pass
both
of
those
before
we
decide
that
this
thing
is
suitable
to
deploy
to
production
canary.
So
these
two
they
co-parallel,
and
then
they
come
back
together.
A
So
we
haven't
got
that
yet
we
haven't
got
the
test
in
place.
What
we
don't
know
is
how
long
a
staging
graph
deployment
takes.
We
don't
know
anything
about
deploying
to
the
get
environment
yet
so
that's
also
a
thing.
We
don't
quite
know
where
to
put
it
in
the
pipeline,
because
it
could
be
it's
a
two-minute
deployment
or
it
could
be
it's
two
hours,
like
literally
no
idea
so
we'll
see
that
stuff
as
we
go
along.
B
A
Goes
I
mean
it
gives
it
a
lot
more.
It
gives
us
a
much
more
thorough
test,
which
is
good.
We
will.
We
will
see
a
lot
more
failures
around
the
staging
stage
of
the
deployment,
but
what
that
should
mean
is
fewer
incidents.
That's
the
goal
is
that
we
have
way
fewer
incidents.
We
pull
things
back,
but
we
are
going
to
have
to
review
how
how
the
release
manager
experience
is
because
it
it
will
be
a
little
bit
more
complicated
because
the
package
will
kick
off
and
it
will.
A
A
A
And
that's
kind
of
what
I
that
was
what
I
sort
of
a
lot
of
this
involved
stuff
in
terms
of
like
what's
happening,
and
how
we're
going
to
do
the
changes
for
some
people
in
the
team.
They
don't
need
to
know
the
ins
and
outs,
but
once
we
have
it
in
place,
it
affects
all
of
us
for
release
management.
So
you
know
we
are.
It
is
kind
of
a
big
change
for
us.
A
Okay,
good
stuff,
and
so,
if
you
think
of
others
like
keep
asking,
if
I'm
not
around
alessio,
has
been
pretty
deep
in
this
project
as
well,
so
he
he'll
also
be
outside,
in
fact,
just
use
g
delivery,
because
this
stuff
affects
everybody.
So
hopefully
people
see
these
questions
as
well.
Okay,
awesome.
B
Cool
so
yeah
on
the
next
point
I
actually
tried
to.
I
was
reading
through
it,
and
I
tried
to
build
something
to
represent
my
thoughts
because
then
yeah
this.
This
is
very
difficult,
so
I'm
just
gonna
share
my
screen.
If,
of
course,
my
keyboard
is
starting
to
my
keyboard
is
not
reacting
yay
or
perhaps
I
can
do
it
with
my
mouse
just
one.
Second,
I'm
gonna
to
connect
my
keyboard
yeah,
no
problem.
I
just
replaced
this
copic
okay.
B
B
So
I'm
gonna
share
my
screen
to
try
to
explain
this,
so
this
is
the
same
slide
that
you
had
in
your
presentation
exactly
the
same
right
and
I
think
at
the
very
same
level
of
this
epic
of
reordering
the
auto
deploy
jobs.
We
also
have
two
other
epics
kind
of
in
parallel.
We
have
the
decide
the
future
of
the
post
deployment
migrations
and
we
also
have
the
single
pipeline
phase
two
right,
and
the
purpose
of
this
presentation
is
to
try
to
explain
how
these
two
can
fit.
B
Or
how
can
we
mix
these
two
into
also
this
epic?
How
this
can
work
together
right?
So
the
first
one
and
of
course
my
mouse-
is
now
not
working
yay,
okay,
perfect!
So
I
post
my
post-deployment
migrations.
So
what
I
understand
so
far
is
that
first
we
are
going
to
deploy
to
canary
staging
then
canary
production,
and
then
we
are
going
to
deploy
to
staging
automatically
after
canary
production,
and
then
we
are
going
to
deploy
manually
well
after
canary
production.
A
Might
be
a
little
different,
these
are
probably
implementation
details.
The
order
is
right.
The
it
may
be
that
the
staging
deployment
is
linked
to
the
manual
promotion,
just
because
the
only
we
we
only
want
to
put
a
package
onto
staging
if
we
also
want
to
put
it
on
production,
so
I'm
not
sure
quite
how
we'll
implement
that,
but
it
may
be
that
it's
the
manual
trigger
to
production
includes
the
staging
deploy.
B
A
A
It
could
be
literally
that
once
we
finish
like
the
staging
prepare
job,
we
trigger
the
production
deployment
like
they
could
be
linked
in
some
way.
That's
not
like
an
hour,
so
the
we
may
I
say
these:
these
are
going
to
be
implementation,
details.
Think
of
staging
as
a
once.
We've
made
the
decision
that
this
package
is
going
to
production.
B
B
So
we
can
work
through
this
assumption,
so
this
one
on
the
left
is
the
coordinated
pipeline,
and
this
one
on
the
right
is
a
different
pipeline
that
I
haven't
had
an
infrared
and
the
pipeline
is
about
deploying
the
post
deployment
migrations
on
staging
and
on
production
this
pipeline
on
the
right.
It
is
going
to
be
manually
executed
by
a
release
manager
at
this
on
the
first
iteration,
and
if
they
we
are
going
to
aim
to
execute
it
at
least
once
a
day.
It
can
be
more,
but
at
least
once
a
day,
amazing.
A
A
The
number
of
times
in
my
career,
I
feel,
like
my
startup
idea,
future
a
tool
that
lets
me
draw
out
a
deployment
pipeline.
I
spend
my
entire
life
trying
to
draw
boxes
that
show
diploma
pipelines
and
yeah
there's
nothing
trivial.
I
cannot
be
the
only
person
that
spends
hours
of
my
week
during
deployment
pipelines.
B
A
Okay,
so
that's
going
to
be
how
we
we
will
be-
and
I
I
think
at
the
point
where
the
we
have
the
jobs
as
different
pipelines.
This
probably
will
be
blocking
but
yeah
just
so
we
kind
of
have
it
official,
so
they'll
be
running
in
parallel
they'll.
The
decision
from
both
of
these
environments
will
need
to
be
taken
into
account
before
we
do
a
deploy
to
gpro
canary.
B
Got
it
okay,
so
this
is
like
the
broad
look
of
the
coordinated
pipeline
and
the
post
deployment
pipeline
and
then
the
following
slides
are:
how
are
they
going
to
look
like
the
deployer
pipeline
for
each
environment,
for
example?
This
is
for
gstg
canary
and
currently
well,
we
have
regular
migrations,
then
the
fleet
then
the
track
then
qa
and
then
it
finishes.
This
is
like
a
very
simplified
stages.
I
didn't
put
all
of
them
because
it
is
larger,
but
this
represents
kind
of
the
current
status.
B
A
B
A
And
I
think
he
we
haven't
got
it
at
the
moment,
but
okay,
so
it's
gonna
it'll
quite
soon
next
week
it
will
look
like
this
awesome.
Okay,
perfect
rough,
we're
going
to
have
italian,
perfect,
okay
yeah.
So
the
reason
for
that
is
is
kind
of
important.
So
this
is
because
stadium
canary
is
going
to
be
the
the
environment
that
we
deployed
to
right.
So
this
is
the
one
where
we
want
to
before
we
go
to
production.
A
This
is
going
to
be
the
essential
place
for
testing,
so
this
will
end
up
being
our
most
capable
environment.
So,
even
if
production
canary
doesn't
have
the
step
like
it
doesn't
have
a
prefect
step
on
production
canary,
we
probably
will
put
one
on
stage
in
canary
so
that
we
get
like
the
best
version
of
tesla.
B
And
then,
if
this
both
of
these
are
green,
we
are
going
to
finish
and
that's
it
that's
it,
and
then
it
is
sort
of
the
similar
for
a
production
canary
in
which,
right
now
we
have
migrations.
Italy,
fleet
track
q,
a
and
finish,
and
then
on
the
new
version.
We
are
going
to
have
the
same
one
right:
q
and
a
are
going
to
be
two
jobs
which
is
going
to
be
the
full
q
a
and
then
the
mixed
deployment
q,
a
yeah,
okay
and
the
staging
deployer
pipeline.
This
one
is
modified
a
bit
further.
B
Currently
we
have
the
migrations,
the
italy,
perfect
fleet.
Then
we
execute
the
pulse
deployment,
migrations,
then
the
tracking
q,
a
and
finish,
and
on
this
new
version,
the
post
deployment
migrations,
are
going
to
be
removed
because
they
are
going
to
be
executed
in
the
new
pipeline
and
q.
A
is
still
the
same
q
a
is,
is
going
to
execute,
like
I
think,
the
full
pipeline.
B
Okay,
cool
and
then
for
production.
It
is
sort
of
the
same
modifications
we
don't
run
q
a
on
production,
but
the
only
modification
is
that
the
post-employment
migration
pipeline,
a
job
is
going
to
disappear
and
in
the
new
version
it
is
going
to
be
associated
with
this
new
pipeline
that
we
were
talking
about
okay.
B
So
these
are
the
changes
that
are
going
to
be
kind
of
included,
or
that
are
the
way
they
are
going
to
look
with
the
new
future
of
the
post-deployment
migration,
epic
yeah.
Okay,
now
for
the
single
pipeline,
the
purpose
of
the
single
pipeline
is
to
remove
the
complexity
from
the
deployer
pipeline
and
actually
move
it
to
the
release
tools
to
actually
be
like
the
coordinator
of
everything.
B
And
how
is
it
going
to
look
in
this
very
broad
sense?
There
are
several
not
several.
I
think
we
have
two
or
three
more
pending
issues
of
the
single
pipeline,
at
least
on
the
phase.
Two
one
is
to
move
the
q
a
and
another
one
is
to
move
the
tracking
and
we
have
another
one
about
making
q
a
and
making
time
executed
at
the
same
time.
But
for
this
purpose
I
think
we're
mostly
interested
about
the
q,
a
so
with
the
coordinated
pipeline.
B
A
B
A
B
That's
it
okay.
So
after
all
these
stagings
have
been
executed.
Well,
not
solid.
Staging
category
staging
and
standing
ref
have
been
executed.
We
are
going
to
execute
production
canary,
which
is
also
going
to
execute
the
full
q,
a
and
the
mixed
deployment
q
a
and
is
going
to
send
the
slack
notification.
B
A
Maybe
it'd
be
worthless,
taking
that.
Well,
no,
let's
give
it
yeah
yeah
okay,
so
we
may
not
bother
with
that
qa
on
staging,
but
we
figured
that
quality
can
figure
that
out.
It
doesn't
add
much
value
right,
because
at
that
point
the
staging
deployment
is
a
bring
staging
up
to
the
correct
version
rather
than
validate
the
package.
B
A
A
A
A
I
don't
know
what
makes
it
cleaner
on
the
diagram
to
show
qa
or
not.
We
may
or
may
not
run
it
after
the
staging,
because
the
goal
of
deploying
to
staging
is
simply
to
put
staging
on
the
same
version
that
we
will
be
running
in
production,
so
we're
not
really
expecting
those
tests
to
ever
fail.
So
we
we
can
see
on
timing,
but
it's
up
to
you.
What
do
you
think
is
the
most
the
cleanest
representation
for
this
diagram.
B
Okay
yeah,
it
can
be
like
we
have
like
an
interrogation
symbol
right
here
to
see.
If
perhaps
this
one
is
not
going
to
be
executed,
yeah,
okay,
okay,
yeah,
that
can
be
an
implementation
detail
yeah
and
for
the
deployer
pipeline.
Well,
it
is
going
to
be
simplified.
Actually,
q
a
is
going
to
be
removed
from
current
from
staging
canary,
like
on
the
new
implement.
B
A
A
Okay,
so
those
are
kind
of
the
two
big
projects
we
have
is
reorder
is
auto,
deploy,
reorder
and
the
future
of
post
deployment
migrations
like
so,
what's
our
next
task
for
this?
So
what's
the
next,
like
I
don't
know,
other
other
pieces
of
the
single
pipelines
are
going
to
jump
to
here
like
what?
What,
if
anything,
do
we
need
to
complete
from
single
pipeline
to
help
with
with
particularly
with
a.
A
A
Did
you
catch
that
seriously,
so
we've
got
the
kind
of
rough
order
of
work.
Is
we've
got
the
auto,
deploy
reorder
tasks
that
graham's
just
started
on
then,
following
that
we
can
do
the
future
of
post
deployment,
migrations
tasks
that
you've
already
created?
So
what
are
the
I'm
gonna
move
this
one
further
down
but
like
what?
What
do
we
need
to
complete
from
the
single
pipeline
phase?
Two,
particularly:
what's
the
order
of
things
we
need
to
complete
to
support
the
auto,
deploy,
I
suppose
the
auto
deploy
reorder
plus
staging.
B
Yeah,
so
I
have
been
thinking
about
that
and
honestly,
I
don't
know
if
we
technically
strictly
talking.
We
need
an
item.
We
can
move
on
without
a
single
pipeline
phase.
Two
the
thing
about
the
single
pipeline
phase
two
is
that
it's
going
to
sell
post
reduce
the
technical
depth
we
have
right
now,
because
yeah
modifying
the
deployer
pipeline
is
quite
painful.
B
A
A
A
B
B
A
B
A
A
The
rest
of
it
is
just
as
you
say
here,
it's
it's
a
it's
a
good
thing
to
do,
to
simplify
the
pipeline,
so
cool,
okay,
great
stuff
and
then
I'm
just
scanning
through
five
and
six
other.
It
sounds
like
there
are.
No,
there
are
no
immediate
tasks
needed.
Is
that
correct?
So,
like
steps
one
two,
three
on
removing
the
blocking
nature
of
post-deployment
migrations,
we
don't
need
that
immediately.
Is
that
correct
or
we
do
need
that.
B
I
do
think
we
need
that.
I
don't
think
we
need
that
for
the
reorder
of
the
post-deployment
migrations,
because
if
we
leave
the
post-deployment
migration
on
staging
and
on
production,
we
need
to
make
sure
that
when
the
production
deployment
is
triggered,
the
post-deployment
migration
has
been
executed
on
staging
because
they
are
going
to
be
on
the
same
pipeline.
B
B
If
we
leave,
if
we
leave
those
jobs
there,
when
we
move
the
switch
to
execute
the
staging
and
deploy
in
production
properly.
At
the
same
time,
there
is
going
to
be
a
chance
for
us
to
execute
the
post-employment
migration
production
first
than
on
the
staging.
So
there
is
this
manual
check
for
release
managers
to
check.
Okay,
they
have
the
product.
Have
the
post-employment
migration
been
executed
on
staging?
Yes,
okay,
then
I
can
promote
the
production.
I.
A
That
we
should
probably
make
a
decision
on
and
like
certainly
like,
we
should
make
it's
you
and
graham
and
alessia.
Maybe
maybe
it's
tasks
for
next
week,
actually
to
figure
out
is
whether
it
is
a
good
idea
or
a
bad
idea.
So
we
have,
I
think
we
have
two.
There
are
two
ways
we
could
make
this
change
right,
so
we
could.
A
B
A
So
they
would,
they
would
probably
still
be
a
deployer
pipeline,
but
they
would
be
triggered
later
by
the
coordinator.
So
there'd
be
like
a
separate
pipeline
that
gets
triggered
on
the
auto
deploy
schedule.
So
they're
kind
of
you
know,
I
guess
it's
closest
to
what
alessia
originally
said
as
like
the
deploy,
the
the
delayed
auto,
deploy
the
delayed
post
deployment
migration
job.
The
reason
I
wonder
if
that
might
be
a
smaller
iteration
is
just
because
that
doesn't
change
anything
from
a
release.
A
Manager's
point
of
view
a
pipeline
just
runs
through
every
step,
so
we
may
not
need
to
worry
about
the
kind
of
additional
pieces
around
like
monthly
releases
and
making
sure
we've
actually
executed
them.
Now
it
may
not
help
us
like
it.
You
it
might
like
I'd,
say:
I'd,
have
a
chat
with
graham
and
alessia
about
how
we
want
to
bring
this
in
because,
actually,
maybe
it
is
easier
to
just
jump
to
the
to
doing
steps
one
to
three
of
the.
A
A
Probably
not
the
others
so
much,
but
definitely
four
and
five
like
we
end
up
for
a
little
period
of
time
in
a
a
semi-risky
place.
So
I
wonder
if
there's
a
depending
on
how
much
other
work
we
have
to
do
around
the
auto,
deploy
reordering
if
there's
a
smaller
iteration
that
gives
us
what
we
need
on
mixed
deployments
without
us
needing
to
kind
of
do
all
of
this
work
in
parallel.
A
A
A
B
I
don't
know
if
you
have
seen
it,
he
updated
it
last
night
and
there
is
a
step
step
number
three,
that
he
says:
move
post
deployment,
migration
from
being
handled
by
the
deployer
to
being
handled
by
the
release
tools,
and
the
objective
is
the
same
that
we
are
talking
about.
He
doesn't
implementation
details
yet
so
probably
this
is
the
best
exactly
question
like
how
do
we
plan
to
do
this
either
by
moving
the
jobs
to
the
coordinated
pipeline
or
implementing
the
future
or
the
possible
migration
or
doing
something
else?
Yes,.
A
B
Yeah,
no,
I
like
it.
I
like
that.
I
think
we
discuss
it
all.
Thank
you
for
your
time.
I
think
we
are
both
on
the
same
page.
What
I
am
going
to
do
is
the
task
that
you
assigned
me
about
reviewing
q
a
can
be
done
before
tracking
and
to
start
talking
with,
unless
you
and
with
more
aims
about
how
are
we
going
to
move
the
possible
immigration
jobs
awesome.