►
From YouTube: Remove blocking nature of post deployment migrations
A
Hello,
everyone.
I
am
mayra
cabrera,
a
senior
vacant
engineer
on
the
delivery
team,
and
I
want
to
talk
to
you
about
a
problem
we
are
currently
having
and
how
do
we
plan
to
fix
it,
so
the
problem
itself
is
associated
to
post-deployment
migrations
now
for
context.
This
is
how
the
coordinated
pipeline
currently
looks
like
the
coordinated
pipeline
is
also
known
as
the
auto
deploy
pipeline
and
is
the
way
we
have
to
deploy
code
changes
all
the
way
to
gitlab.com.
A
Now
this
is
a
very
simplified
diagram.
There
are
a
lot
of
details
happening
behind
the
curtains,
but
for
the
purpose
of
this
video,
I'm
just
going
to
keep
it
simple.
So,
first
of
all
we
deploy
to
a
staging
canary
and
along
to
a
staging
ref.
Then
we
deploy
the
production
canary.
Then
we
execute
q
a
followed
by
baking
time,
and
then
we
have
the
manual
promotion
after
this
job,
our
deployment
to
staging
automatically
starts
and
then
30
minutes
later
we
do
a
series
of
production
checks
to
make
sure
we
can
perform
a
production
deployment.
A
A
So
whenever
we
have
an
incident,
whether
it
is
an
s1
or
an
s2,
we
aim
to
fix
it
as
quickly
as
possible
and
if
the
incident
was
caused
by
a
code
change
that
was
recently
introduced,
one
of
the
ways
to
mitigate
this
incident
is
to
perform
a
rollback
which
basically
brings
us
back
to
the
state.
Before
the
code
change
was
introduced
now
performing
a
rollback
is
quick.
It
will
normally
take
us
one
hour.
A
The
problem
is
that
if
the
auto
deploy
package
contains
a
post
deployment
migration,
we
cannot
roll
back
because
of
the
nature
of
the
operation
of
the
possible
migrations.
There
is
an
uncertainty
about
that.
So,
instead
of
that,
we
need
to
well
revert
the
merchant
well
that
caused
a
problem
and
deployed
to
gitlab.com
which
usually
takes
between
six
to
eight
hours.
So,
comparing
that
time
of
reversing
and
deploying
versus
the
time
that
takes
that
troll
back,
we
can
tell
that
rollback
is
faster.
A
The
other
problem
with
post-employment
migrations
is
that
they
are
lengthy.
They
are
long
because
of
the
operations
they
perform.
These
migrations
can
be
data,
migrations
can
execute
background
migrations
or
they
can
create
indexes
or
foreign
keys
to
large
tables,
which
usually
takes
a
lot
of
time
now.
Longer
post-deployment
migrations
can
affect
release
processes
like
the
monthly
release.
A
A
So
what
is
the
solution
to
this?
We
discuss
it
and
we
come
up
with
the
idea
of
disassociating
the
execution
of
post-deployment
migrations
from
the
coordinated
pipeline,
basically
to
make
the
coordinated
pipeline.
That
currently
looks
like
this
with
the
post-deployment
migrations
at
the
end
of
it
to
make
it
look
like
this.
A
A
Now,
how
do
we
plan
to
achieve
this?
There
are
several
issues
with
a
lot
of
implementation
details,
but
all
of
these
issues
can
be
wrapped
up
in
three
phases.
The
first
one
is
that
we
need
information
about
the
pending
post-employment
migrations
release.
Managers
need
to
know
if
there
are
pending
post-employment
migrations
to
be
executed,
and
they
also
need
to
know
which
auto
deploy
package
introduces
it
in
case.
A
We
need
to
roll
back
then
well,
we
need
to
build
the
independent,
positive
migration
pipeline
with
everything
that
entails
and
finally,
we
need
to
also
adjust
our
release
processes
to
account
for
the
execution
of
this
new
pipeline.
We
need
to
adjust
the
monthly
release
and,
of
course,
we
need
to
also
adjust
the
rollback
process.
A
So,
what's
next
after
we
have
removed
the
blocking
nature
of
the
post-deployment
migrations?
Well,
we
would
like
to
make
the
execution
of
the
post-deployment
migration
smarter.
How
well
an
idea
could
be
to
classify
them
based
on
their
nature
or
on
their
operations
and
to
find
a
suitable
time
to
for
them
to
be
executed.
A
For
example,
we
can
create
indexes
and
foreign
keys
for
large
for
large
tables
in
low
traffic
times
and
then
is
to
remove
the
execution
of
these
migrations
from
the
deployment
process
by
replacing
post-implement
migrations
with
a
gitlab
feature,
basically
to
dock
foot.
Now
these
are,
of
course,
very
long-term
directions.
A
I
actually
have
them
right
here,
so
the
first
one
is
the
issue
in
which
we
discuss
what
is
the
problem
with
the
post-implement
migrations,
and
how
can
we
solve
this?
We
discuss
several
options.
There
are
a
lot
of
details
in
here
and
then.
Finally,
the
result
of
this
issue
was
this
epic,
about
removing
the
blocking
nature
of
the
post-deployment
migrations,
which
contains
the
details
that
I
just
explained.