►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
With Preview Environments, Everyone is Invited To the Party- Jacob MacElroy, Okteto
Historically, code reviews have been the sole domain of software developers. Who else is going to be capable of pouring over hundreds of lines of code and identify good and bad practices? But modern software development is no longer the sole domain of software developers. As our industry has matured, it has shifted, and new roles have appeared. Even in the smallest teams, you'll often have Program Managers, Designers, Content Writers, etc. They don't write code on their day-to-day jobs, but they often have the same or even more context on the changes you're working on. Wouldn't it be fantastic if they could also review your changes? Let me introduce you to preview environments. A preview environment is, at a high level, a copy of your application attached to a pull request. With preview environments, you can include a live copy of your application along with your code changes, making it easier for everyone in your team to give you feedback on your changes. Heroku and Runnable are some of the earlier proponents of preview environments, but they were limited to their own walled garden. In this presentation, I'll talk about why Kubernetes is the perfect platform for preview environments to finally gain the massive adoption they deserve.
A
Hello
again,
everyone
here
locally,
my
name
is
jacob
mcelroy,
I'm
a
developer
at
octeto,
and
the
title
of
my
talk
is
with
preview
environments.
Everyone
is
invited
to
the
party
and
that's
an
interesting
title-
to
try
and
get
accepted
here,
but
what
it?
What
it
means
is,
is
by
introducing
preview
environments
to
your
review
process,
you're
able
to
integrate
more
a
more
diverse
set
of
roles
and
include
as
many
people
as
possible
in
your
review
process
so
that
you
ultimately
have
a
better
product
and
a
better
team
right
so
same
with
parties.
A
The
more
people
you
invite,
usually
as
long
as
they're
the
right
people,
the
the
better
the
party
right.
So
to
accomplish
this
first,
I'm
going
to
define
preview
environments.
I'm
going
to
talk
about
what
I
mean
when
I
say
preview
environments-
maybe
you've
never
heard
of
it.
Maybe
you
have
it's
one
of
those
things.
A
There's
we
could
talk
about
how
it's
implemented,
but
but
how
it
benefits.
The
team,
I
think,
is
probably
the
most
important
aspect,
because
it's
the
why
so,
let's
talk
about
what
a
preview
environment
is
we're
defining
today
for
the
context
of
this
talk,
we're
defining
a
preview
environment
as
a
full
deployment
of
your
application.
A
That
is
deployed
in
conjunction
with
the
pull
request.
You
open
up
a
pull
request
and
then
you
have
a
preview
environment,
so
it
is
deployed
from
the
branch
that
is
under
review,
at
least
at
least
the
code.
Maybe
all
the
code
and
the
automation
to
deploy
that
code
is
all
in
the
same
branch,
but
the
point
is
is
that
the
preview
environment
is
effectively
using
the
code
that
that
you're,
putting
under
pull
requests
that
you
want
to
have
reviewed
and
when
the
review
is
complete
it
all
the
resources
are
cleaned
up.
A
So
it's
an
ephemeral
environment
that
is
specific
for
the
review
process.
It's
all
it's
it's
not
it's
not
a
staging
and
the
reason
that's
important
is
because
you
think
about
these
ephemeral
environments
or
something
like
that.
You
may
think
of
a
staging
environment.
Well,
it's
a
little
bit
different
than
the
typical
staging
environment
which
is
after
emerge
right.
This
is
before
this
is
your
development
branch.
Okay.
A
So
it's
very
much
a
development
thing
and
we
have
a
snippet
here
of
sort
of
something
fulfilling
all
of
that
we
have
a
github
bot
that
has
said
hey
your
preview,
your
ephemeral
preview
environment
is
deployed
and
here's
how
you
access
it
right
there
and
it's
a
snippet.
If
you
use
github's
code
review
process
you
you
may
notice
that
as
a
comment
and
that's
what
that
is,
so
it
appears
there.
A
So
that's
that's!
What
a
preview
environment
is,
that's
what
we're
defining
it
as
and
since
you
know
we're
here
at
kubecon,
I
feel
like.
I
have
to
mention
that
this
is
one
of
those
things
that
is
really
not
necessarily
made
possible,
but
made
better
made
easy
and
made
the
possibility
of
preview
environments
being
more
ubiquitous
between
teams
is
made
possible
because
of
the
groundwork
laid
down
by
kubernetes
cloud
development
in
general.
You
can
go
from
from
that's
bitbucket
logo.
A
A
So
we've
defined
it,
we've
talked
about
how
it
fits
well
with
kubernetes,
and
so
that
we
probably
all
here,
have
the
possibility
of
doing
preview
environments.
So
let's
compare
the
review
process
both
with
and
without
preview
environments.
So
the
traditional
code
review
process
is
focused
on
a
code
diff.
It's
for
developers
right
a
developer,
typically
writes
the
code,
creates
the
pr
and
is
going
through
a
developer,
focused
review
process,
and
I
don't
think
that
should
change.
I
think
that's
great
it.
A
But
it's
really
hard.
I
think
most
people
would
agree
it's
really
hard
to
intuit
or
know
and
understand
the
behavior
of
your
function
feature
just
by
reading
a
code.
Diff
right,
you
may
be
able
to
know
how
a
loop
may
execute
and
that
those
types
of
behavior
but
the
product
it's
going
to
be
very
difficult.
So
that's
where
yeah,
you
can
get
some
of
that
from
a
traditional
code
review,
but
I
think
a
preview
environment
based
code
review
is
gonna.
Gonna
help
gonna
help.
A
So
when
you're
using
a
preview
environment,
you
have
a
readily
available
hands-on
environment
so
readily
available.
I
think
that's
important,
because
there
are
many
times
in
the
past
before
I
used
preview
environments
that
were
automatically
deployed
where
I
would
pull
down
a
teammate's
branch,
do
a
deploy
myself,
deploy
it
locally
or
remotely.
A
Whatever
was
available
to
me-
and
I-
and
I
would
do
that-
and
I
would
do
the
review
process
there
do
sort
of
the
preview
environment
review
process
I'll
take
talk
about
there,
but
I
had
to
there
was
there
were
hurdles
I
had
to
opt
into
doing
that
I
had
to
be
able
to
do
a
deploy
which,
in
some
products
is
not
easy.
Some,
you
know,
we've
talked
about,
there's
been
other
talks
here
where
they
talk
about
how
some
people
can
do
to
deploy
some
people.
A
Can't
you
know,
so
you
have
to
be
able
to
do
that.
You
have
access
so
readily
available.
I
think
is,
is
super
appropriate
here.
It
just
happens
with
preview
environments,
it
gets
deployed
and
then
you
decide
if
you
want
to
use
it
or
not
right
and
with
kubernetes,
and
all
that
that's
cheaper.
That's
easier,
so
you
decide
if
you
want
to
use
it
or
not,
but
it's
already
there
you
don't
have
to
decide.
I
want
to
spin
it
up.
A
I
want
to
take
the
time
to
check
out
the
branch
everything
it
just
happens
and
that's
great,
because
we
all
want
to
do
less
work
and
we
just
want
to
reduce
friction
along
this
whole
process.
Right
often,
preview
environments
focus
on
visual
changes,
visual
and
I'm
talking
about
visual
changes
to
the
application.
So
this
is
where
we
pull
in
some
of
the
diverse
role
set
right.
How
does
it
affect
the
ui?
If
you
have
a
ui
component?
How
does
it
affect
the
log
output?
A
A
The
preview
environment
review
focuses
on
functionality
right
you
care
about
the
functional
aspect:
it's
not
an
automated
functional
test
or
anything
like
that,
but
you
you
can
use
the
product
in
a
functional
manner
and
redo
often
times
people
do
this
in
staging.
But
now
you
can
do
it
right
with
your
branch
and
doing
all
these
things.
Everyone
is
invited
to
the
party.
You
have
more
people
now
that
have
the
ability
to
to
provide
feedback
they're
not
going
to
do
a
full
review.
A
The
design
of
the
page,
the
flow
of
the
page
so
product
can
go
in
and
say
hey.
This
goes
from
this
to
this
to
this
part
of
your
application
and
goes
through
all
that,
and
they
say
yeah.
That's
that's
how
I
envisioned
it
in
my
mind,
and
they
can
do
that
right
then,
just
by
clicking
a
few
links
on
the
on
the
review
right,
then
development
they
get
to
use
it.
A
So,
if
you're
developing
an
internal
api,
people
could
target
your
preview
environment
with
their
clients
and
use
that
it's
up
there,
it's
ready
for
them
to
use
and
then
devops.
This
one
is
kind
of
a
subtle
thing
in
that
with
the
I
think,
the
advent
of
all
of
the
cloud
deployments
and
everything
the
devops
and
the
specifically
the
automation
of
getting
something
deployed,
things
can
break.
A
Then
you
can
go
through
and
make
your
feature
write
all
the
code
and
then
all
of
a
sudden,
you
can't
deploy
it
in
a
production-like
environment,
well
with
preview
environments
and
specifically
preview
environments
that
model
how
your
production
environments
are
done,
that
automation
gets
tested
with
your
branch.
If
you
can
create
a
preview
environment,
it's
much
more
likely
that
you're
able
to
produce
a
production-like
environment,
so
devops
is
now
participating
just
kind
of
by
the
fact
that
a
preview
environment
gets
created
right.
A
A
I
believe
that
adding
all
that
adding
the
diverse
role
set
testing
all
those
things
adding
the
visual
changes,
I
think
that
promotes
ownership
and
what
I
mean
by
ownership
is
I
mean
having
feeling
like
you
have
you
are
responsible
for
your
product,
that
you
have
a
say
and
that
you
are
participating
right
and
that
you're
participating
in
the
key
role.
I
think
I'm
biased,
I'm
a
developer
right,
but
I
think
the
development
portion
of
it
is
is
some
of
the
one
of
the
key
aspects.
A
There's
many
aspects,
but
that's
a
that's
a
place
where
it's
being
made
is
being
developed,
it's
being
created,
and
so
the
more
people
that
you
can
include
at
that
point
in
time.
The
the
more
responsibility
they'll
feel
and
the
increase
ownership,
I
think,
typically
leads
to
better
products
and
better
teams.
A
Whenever
I
typical
flow.
Whenever
I
do
a
code
review
is
I
will
do
a
code
review
it'll
go
under
the
normal.
Let's
say
that
in
the
traditional
sense,
this
this
flow
shows
in
the
traditional
model.
We'll
do
a
code
review
we'll
check
all
the
traditional
code,
diff
type
things
we
will
merge
and
then
that
gets
into
some
staging
deploy
and
then,
if
there's
any
kind
of
visual
or
integration
review,
that
needs
to
be
done,
it'll
be
done
against
that
environment
right.
A
A
Then
it
has
to
go
under
code
review
again,
because
this
is
typically
these
are
enforced.
I
can't
merge
at
all
any
new
change
and
so
we've
sort
of
in
a
way
disincentivized
actually
having
that,
because
I
have
to
go
through
this
whole
flow
again
and
so
we're
less
likely
to
to
dot
the
eyes
and
cross
the
t's
of
the
visual
and
the
integration
review
process
right,
because
I
don't
want
to
have
to
do
this
again,
because
I
don't
have
time
right.
Is
it
important
enough
to
where
I
can
redo?
A
All
of
this-
maybe
maybe
not-
and
and
that's
a
judgment
call
that
may
be
true,
but
what
if
we
could
remove
that
and
I
think,
with
the
preview
environment
the
typical
flow,
at
least
when
we're
talking
about
the
visual
and
integration
review
and
and
all
that
sort
of
thing
it
becomes
this
right.
So
we
do
the
code
review
and
the
visual
and
integration
view
all
before
the
merge
all
together
right
and
then
we
merge
and
there's
no
more
that
the
feedback's
been
done.
A
I
don't
have
to
wait
for
another
deploy
to
get
more
of
that
feedback.
There
are
other
things
that
you
will
pick
up,
but
for
the
most
part,
we've
for
this
part
for
this
visual
and
integration
review
of
the
actual
change
we've
eliminated
that
right.
So
we
get
to
do
that
all
once
and
one
branch
one
go,
we've
I
believe,
save
time
for
the
developer.
A
We
may
be
using
more
time
for
people
that
that
haven't
been
part
of
this
review
process
before
we
may
be
using
more
of
their
time
because
they're
participating
in
more
reviews,
but
I
believe
that's
a
net
gain
and
I
think
that
all
those
key
components
you
know
the
role,
diversity,
the
increased
ownership
and
then
just
the
better
use
of
everyone's
time.
I
think
those
team
benefits
to
me
really
highlight
why
everyone
should
consider
preview
environments.
A
A
A
Okay,
so
I've
got
zero
votes,
but
it's
the
only
one
up
there,
so
it
gets
gets
to
go.
You
mentioned
the
benefits
of
preview
environments
for
looking
at
visual
changes,
but
it's
also
great
for
getting
a
feel
on
interactive
changes
like
a
search
or
browser.
Yes,
yes,
so
sort
of
performance
related
there's
sometimes
I
talked
about
in
the-
and
I
should
have
mentioned
this
then,
but
I
talked
a
little
bit
about
how
we
look
at
complex
code
in
a
different
code
review.
We're
checking
that.
Well,
why
are
we
looking
at
complex
code?
A
I
mentioned
you
know
looking
for
things
that
may
be
bug
prone,
but
a
lot
of
times
complex
code
is
non-performant
or
doesn't
perform
as
well,
and
it
may
show
up
in
a
preview
environment,
especially
if
you're
able
to
load
your
preview
environment
with
with
data
with
the
the
last
talk
they
talked
about
how
because
they
were
database
based,
they
talked
about
adding
data
into
the
database
and
so
that
you
could
do
development
and
they
needed
for
development
persons
purposes.
We
could
do
that
here.
B
Oh,
I
was
just
gonna,
follow
up
and
explain
a
little
bit
more.
What
I
was
talking
about.
You
can
also
end
up
with
like
a
ui
that
looked
really
good
when
you
drew
it
and
then,
when
you
go
to
like
click
on
something
like
the
page
reflows
and
all
of
a
sudden
like
you
thought
you
were
clicking
one
place
and
it
goes
somewhere
else,
and
so
that's
another
thing
that
these
preview
environments
can
really
help
you
catch
yeah.
A
Yeah,
so
the
the
point
was
there
that
that
oftentimes,
when
you
have,
if
I
get
it
all
correctly,
if
you
have
a
flow
or
like
spinners
or
something
going
in
between,
if
you
actually
go
through
the
flow
of
the
website
and
actually
visit
you,
you
may
find
that
you've
done
something
you
didn't
want
to
do
and
it's
going
to
need
a
change
right
and
you
can
address
that.
Then
any
other
questions
yeah.
We
have
one
right
here.
C
A
Yep,
so
the
question
is:
do
you
think
that
preview
environments
are
valuable
for
non-ui
environments
like
like
clis
and
apis,
that
sort
of
thing
yeah?
Yes,
I
do.
Obviously
I
think
it's
a
little
bit
there's
a
little
bit
more
harder
to
integrate
a
test
with
that.
So
I
didn't
talk
much
about
integrating
automated
tests
with
preview
environments,
which
is
something
you
can
do
but
say
you
have
an
internal
api
right
that
the
rest
of
your
team
uses
or
even
publicly
available
api.
A
You
can
go
ahead
and
either
run
an
automated
test
suite
against
that
or
if
I'm
providing
a
new
api
change
to
say,
there's
like
two
or
three
internal
teams
that
use
it.
They
can
start
using
that
they
can
target
and
do
whatever
you
want.
Hey.
I
have
a
preview
environment,
run
it
through
its
paces
and
give
me
some
feedback
right.
That's
now
an
option.
Cli
is
the
same.
You
know
any
anywhere
anytime,
there's
a
client
server
interaction,
whether
it's
http
or
whatever.
If
your
cli
has
that
way,
yes
yeah,
I
think
it's
super
valuable.
A
I
think
the
I
do
believe
it's
a
harder
to
adopt
right
and
the
the
benefits
are
not
as
immediate
as
the
ui
ones
and
the
role
diversity
doesn't
apply,
doesn't
necessarily
apply
as
much,
but
you
are
able
to
involve
more
teams
and
give
them
a
a
really
high
fidelity
environment
to
to
do
their
testing.
It's
before
emerge
right,
that's
better
than
doing
stage.
You
can
get
that
feedback
earlier
and
not
have
to
wait
for
that
yeah.
I
think
so.
D
A
A
The
question
is,
if
you
have
lots
of
database
type
things
or
database
actions,
how
does
a
preview
environment
help
there
or
is
only
for
ui
stuff?
Typically,
the
the
quickest
that
I've
seen
value
have
with
preview
environments
is
for
ui
basics.
However,
that's
not
the
only
way
right.
No,
we
absolutely.
There
are
absolutely
remote
development
products
that
allow
you
to
populate
data
for
your
deployed
environment.
A
So
if
they
talked
about
at
the
last
talk
where
they
can
populate
that
data,
so
if
there's
any
type
of
client
server
interaction
where
someone
is
consuming
it,
which
is
almost
everything
right.
So
if
you
are
doing
some
kind
of
say,
you're,
adding
a
prepared
statement,
I'm
not
great
with
databases,
I
don't
use
them
a
lot,
but
if
you're
adding
a
prepared
statement
or
some
change,
where
the
data
model
is
completely
different,
yeah
you
can
you
can
absolutely
model
that
change
and
start
doing
that.
It's
a
little
bit
more,
you!
A
A
No,
it
would
actually
deploying
it.
You
would
just
deploy
the
real
thing
and
you
may
have
mock
data
like
fake,
can
data
or
a
copy
of
of
actual
data
from
production
sanitize.
It
don't
do
that
unless
you
know
your
data
right,
but
that's
not
a
recommendation,
but
it
it's
possible
right,
yeah,
you,
you
would
actually
deploy
that.
That's
one
of
the
the
in
my
definition
that
would
be
fit
under
that
and
that
it
has
to
be
exactly
like
your
production
deployment
or
as
similar
as
possible.