►
From YouTube: Do you test database code in production?
Description
I wanted to take a minute and ask you a question: how often do you deploy untested database code in production? At gitlab, we're using some cool new tools to make database migrations safer and better.
Migration testing project: https://gitlab.com/gitlab-org/database-team/gitlab-com-database-testing
Merge requests that use the migration testing: https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&state=opened&label_name[]=database-testing-automation
Database team job posting: https://boards.greenhouse.io/gitlab/jobs/5093969002
A
Alex
here
with
the
gitlab
database
group,
I
want
to
take
a
minute
and
ask
you
a
question:
how
often
do
you
deploy
untested
code
in
production
every
other
job?
I've
worked,
we've
had
issues
come
up
in
production,
in
particular
due
to
untested
database
code.
Now
you
might
be
saying
I
test
everything
in
advance,
migrations,
queries,
everything
and
I
believe
you
but
prediction
systems
have
major
differences
from
the
dev
and
test
environments
that
they
stem
from
history
and
scale.
A
Customers
do
crazy
things.
Sometimes
they
do
stuff
just
to
see
if
they
can
rise
out
of
you
or
maybe
they're
trying
to
get
banned.
Sometimes
they
have
crazy
workflows.
You
never
considered
as
a
part
of
the
system
design.
Maybe
it's
not
customers
at
all.
Maybe
five
years
ago
someone
developed
a
feature,
they
turned
it
on
in
production
for
a
day
and
turned
it
off
because
of
all
the
bad
data
it
generated,
and
then
it
was
too
difficult
or
expensive
to
clean
up.
A
So
they
didn't
combine
that
data
history
with
all
the
scale
of
your
customers
and
the
data
operations
can
just
occur
differently.
There
are
some
ways
to
mitigate
that
risk.
Maybe
you
run
select
queries
in
advance
with
explain,
plans
to
make
sure
they
perform
on
a
replica,
but
if
it's
not
a
replica
that
can
be
risky
or
dangerous,
one
malformed
query
or
an
accidental
paste
can
spell
disaster.
A
Maybe
you've
got
a
production
copy
you
can
use,
but
the
turnaround
time
for
those
test
environments
is
expensive
due
to
the
typical
high
cost
of
resetting
them
here
at
gitlab,
we're
doing
things
a
little
bit
differently,
leveraging
the
database
lab
engine
from
our
friends
at
postgres,
ai,
we're
not
only
able
to
generate
explain,
plans
for
destructive
queries
on
a
production
replica
we're
also
able
to
use
them
to
test
our
schema
migrations.
Every
time
a
schema
migration
is
added
to
the
get
lab
repo.