►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. 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.
Preview Environments with ArgoCD - Brandon Phillips, Codefresh
Deploying to static environments(QA/staging/prod) is a familiar process for existing ArgoCD users. However, several teams want to shift left and use preview environments. Preview environments are created dynamically when a pull request is opened and are destroyed when the pull request is merged/approved This talk will focus on implementing preview environments in a GitOps way using ArgoCD.
A
Yeah,
hello,
everyone,
first
of
all,
congrats
on
making
it
to
the
end
of
the
day.
So
being
the
very
last
presentation,
I,
don't
know
if
that's
a
good
thing
or
a
bad
thing,
but
here
we
are
so
we
are
going
to
talk
about
preview
environments
with
Argo,
CD
and
Brandon
as
introduced
I'm
at
code
fresh
as
a
principal
technologist
I
also
hand
a
lot
of
go
to
market
stuff,
but
the
most
important
thing
is
I
get
to
spend
a
lot
of
time
playing
around
with
Argo.
So
that's
very
fun.
A
I'm
going
to
start
with
what
seems
like
a
very
obvious
question
that
I
think
everyone
in
this
room
is
going
to
go.
Oh
I
know
what
a
preview
environment
is.
So
why
are
we
discussing
this?
But
what
I
want
to
talk
about
is
that
preview
environments
mean
different
things
to
different
people
and
a
preview
environment,
for
you
might
be
a
namespace,
it
might
be
a
cluster,
it
might
be
a
set
of
clusters,
it
could
even
be
a
region
or
in
the
case
of
like
Mike's
great
talk
earlier,
it
could
be
V
clusters
as
well.
A
So
preview
environments
really
differ
from
person
to
person,
and
what
I
want
to
talk
about
today
is
how
Argo
is
trying
to
bridge
that
Gap
with
their
generators
they're,
making
it
possible
to
fit
as
many
use
cases
as
you
can
so
here
in
this
image.
Obviously
the
simplest
diagram
I
could
have.
Is
you
have
some
developer
action
that
is
resulting
in
some
kubernetes
resource
in
some
way,
whether
it's
a
cluster
or
namespace?
That's
what
we're
going
to
talk
about
today
and
how
we're
going
to
do
that.
A
So
why
should
you
care
I
mean
that's
always
the
question,
but
but
why
should
I
really
care
about
this?
What
is
it
solving
for
me
and
that's,
where
I
really
think
it's
important
to
talk
about
testing,
because
as
we
move
more
towards
modernized
applications
as
we
move
towards
kubernetes
and
really
getting
at
scale,
testing
is
just
getting
more
and
more
complex.
A
We
can't
really
get
away
from
it
and
there's
this
concept
of
oh
we're
going
to
shift
left,
we're
going
to
move
security
testing
and
a
lot
of
things
further
left
developers
are
going
to
take
on
more
responsibilities.
I
think
it's
a
great
idea,
it's
harder
to
implement
and
practice,
but
what
we
want
to
do
is
with
preview
environments.
Is
help
shift
a
little
bit
of
that
onto
the
developer
without
making
it
feel
like
a
giant
burden
on
them.
So
that's
a
goal
here
and
we
want
to
avoid
that.
A
Rework
that
happens
in
static
environments
like
I,
don't
think
anyone
wants
to
get
up
into
their
staging
their
uat
and
definitely
not
their
production
and
have
a
feature
that's
not
acting
as
expected.
So
the
goal
is
to
make
sure
that
we
test
this
earlier
in
the
process
to
truly
understand
the
state
of
it
and
and
really
then
we
can
proceed
forward
with
just
better
development
practices.
A
We
want
to
avoid
really
ugly
merges
as
well,
because
I'm
sure
many
of
you
have
been
here
involved
either
from
the
devops
or
the
developer
side
that
you
have
multiple
features
that
are
actually
clashing
together
and
you're,
hitting
some
really
nasty,
merge
conditions
and
it
may
not
even
come
out
until
you're
actually
testing.
So
this
gives
us
an
opportunity
to
be
a
little
bit
more
Dynamic
about
how
we
create
our
test
environments,
and
we
can
merge
feature
sets
together
into
a
preview
branch
that
gets
built
out
into
a
preview
environment.
A
A
Whatever
you
want
to
call
it,
it
becomes
kind
of
a
Dumping
Ground
and
what
developers
do
because
they're
focused
on
delivering
their
story
points
is
they
deliver
their
code
and
they
go
hands
off
and
it
turns
out
something's
broken
in
the
integration
environment
and
it
basically
becomes
a
case
of
whoever
found
it
has
to
figure
it
out.
That's
not
a
fun
scenario
right
and
I
think
the
developers
are
going
to
push
you
off
because
that's
not
their
goal.
To
worry
about
that
right.
A
A
So
let's
talk
about
some
use
cases.
So
I'll
start
with
the
good,
and
some
of
these
are
going
to
be
obvious
as
we
move
into
some
of
the
other
sections,
maybe
a
little
less
obvious,
but
the
first
one
being
microservices
I
think
most
people
on
kubernetes
are
doing
some
sort
of
microservices
or
mini
services
or
whatever
you
want
to
call
them,
depending
on
what
you
kind
of
had
to
go
with
at
your
organization,
they're,
just
a
naturally
good
fit
for
this
right,
they're
kind
of
bite
size.
You
can
easily
test
them
in
a
preview
environment.
A
Ideally,
if
you
really
followed
microservices,
you
know
best
practices,
you
don't
have
a
lot
of
other
dependencies
that
are
going
to
cause
problems,
so
that
can
be
very
helpful
if
you
have
projects
with
heavy
concurrent
Feature
work.
So
in
other
words,
you
know
you
have
like
a
big
project
release
coming
up.
A
You
have
20
50
100
developers,
all
working
on
features
at
the
exact
same
time
and
I
think
we
all
know
that
when
you
get
towards
the
end
of
a
Sprint
they're
coming
in
hot
a
lot
of
times
right,
you
might
have
you
know:
80
75,
80
percent
of
the
features
getting
delivered
right
at
the
end
of
the
Sprint.
So
if
you
have
projects
like
this,
it
can
become
kind
of
the
Wild
West
in
those
integration
environments
where
we're
merging
everything
into
the
main
branch
to
really
queue
up.
This
release
to
kind
of
push
it
through.
A
A
So
you
end
up
with
developers
who
are
kind
of
like
hung
up
to
dry
for
a
little
while,
because
they're
waiting
to
see
where
they
can
actually
test
their
change
at
and
they
don't
really
have
a
good
environment
to
do
that
in
so
this
gives
them
a
little
bit
of
an
opportunity
to
spin
up
an
environment
that
suits
their
needs
to
actually
test
it
out,
and
then
just
Argo
and
preview
environments
is
a
great
combination.
Right,
I
think
we
can
all
agree
with
that.
A
A
lot
of
the
recent
development
in
Argo
has
made
this
so
much
easier
and
we'll
talk
about
that.
But
it's
really
just
improving
things,
so
I'm
going
to
talk
about
the
bad,
but
these
aren't
really
bad,
but
I
wanted
to
say
the
good,
bad
and
ugly.
So
this
is
what
we
have,
but
these
are
potentially
bad
things
right.
A
So
apis,
for
example,
can
seem
like
an
obvious
use
case.
You're
like
well
I
can
really
get
out
there
and
test
this
in
a
preview
environment.
It's
gonna
be
very
easy.
Depending
on
how
much
dependency
you
have
on
other
services
or
other
services
have
on
you
as
an
API,
and
also
how
you
set
up
Ingress
routes.
This
can
be
a
bit
of
a
trap,
because
API
testing
can
really
lead
to
very
unexpected
results
and
you're
likely
going
to
have
to
build
Out
preview
environments
with
multiple
services.
A
So
you
may
find
that
to
be
a
good
thing
you
may
not.
It
can
actually
be
a
very
good
use
case,
but
you
need
to
watch
out
for
some
of
the
caveats
there.
Anything
that
has
heavy
database
mutation
or
depends
on
messages
or
basically
in
strong
external
infrastructure
that
you
have
to
consume
from
and
you're
changing
things
can
be
tricky.
It's
not
that
it
shouldn't
be
done.
A
You're,
going
to
start
to
wonder
where
these
you
know
these
missing
messages
are
going,
and
it
can
be
a
really
confusing
thing,
if
not
everyone's
in
the
loop
on
exactly
what's
going
on,
so
you
need
to
be
careful
about
where
you're
consuming
from
and
then
I
also
have
core
services.
And
what
I
mean
by
this
is
let's
say:
I'm
a
business
to
business.
Retailer
and
I
have
a
pricing
engine
right
and
that
pricing
engine
affects
effectively
everything
in
the
company
right.
It's
it's!
You
know
on
manifest
it's
on
the
checkout
process.
A
It's
in
all
these
different
places.
You
can't
test
these
in
preview
environments,
but
it
can
be
tricky
to
really
understand
the
full
implication
of
what
you're
changing
in
an
engine
like
this
across
the
entire
ecosystem
of
what
your
you
know,
company
really
utilizes
and
organizes.
So
that
can
be
quite
tricky,
so
you
can
do
it.
But
again
you
need
to
truly
understand
the
scope
of
the
services
that
you're
trying
to
utilize
and
how
you're
actually
going
to
play
off
of
that.
A
So
here's,
the
ugly
I,
don't
think
there's
going
to
be
too
many
surprises
here,
but
you
know
monoliths
they're,
not
really
a
great
use
case.
It's
not
that
you
can't
use
a
monolith
to
do
this
because
you
definitely
can
I've
worked
with
many
people
that
put
monoliths
into
preview
environments,
but
there
are
a
lot
of
potential
bad
repercussions
here.
There's
resources,
usage
issues,
there's
just
the
impact
on
other
external
infrastructure,
supporting
services
that
you
really
need
to
be
aware
of
so
monoliths
again.
A
It's
not
that
you
can't
do
it,
but
it's
probably
not
the
ideal
use
case
here.
I
think
what
you'll
see
is
a
lot
of
times
as
companies
are
going
through,
like
modernizations
they're,
taking
monoliths
up
they're,
going
to
split
them
up
into
smaller,
more
bite-sized,
Services,
probably
not
microservices,
but
somewhere
in
between,
and
then
they
can
really
start
to
see
the
benefits
of
things
like
preview
environments.
A
If
you
have
microservices
with
hard
coupling,
you
probably
didn't
really
do
microservices
right,
but
it
happens
all
the
time
right,
so
you're
going
to
have
some
hard
coupling
between
microservices.
That
can
make
it
very
tricky
if
your
preview
environment
to
test
one
service
requires
you
to
bring
in
20
other
microservices.
You
have
kind
of
a
problem,
it's
probably
an
architectural
problem,
but
it's
also
a
problem
for
preview
environments.
A
That's
just
a
tricky
thing
to
actually
deal
with
and
then
load
testing
is
an
interesting
one,
because
I've
seen
preview
environments
used
for
load
testing,
and
it
can
give
you
some
cursory
information
for
sure.
But
the
reality
is
it's
never
going
to
be
very
accurate
compared
to
your
production
resources.
You
know
your
actual
environments
that
you
want
to
have
sort
of
a
true
metric
from
on.
How
is
this
going
to
perform
compared
to
what
I
expect
it
to
look
like
in
production?
A
It's
very
difficult
to
generate
exact
load
unless
you
have
the
exact
resource
specifications
as
your
production,
environment
and
the
exact
load
there,
so
you
can
do
it
pretty
tricky
and
the
last
one
here
is
more
of
a
philosophical
one,
but
it's
just
an
inflexible
culture.
There
are
a
lot
of
organizations
out
there
who
they
have
their
static
environments.
They
have
a,
they
have
a
Dev,
they
have
Assist
you,
they
have
uat,
they
have
a
production
and
that's
all
they
want
to
stick
to.
They
don't
want
to
have
to
manage
any
resources
outside
of
that.
A
It's
not
a
problem
that
you
can't
change,
but
it's
definitely
a
problem
that
can
make
it
very
difficult
to
get
developers
and
your
devops
folks
and
kind
of
everyone
else
within
the
I2
organization,
into
a
situation
where
they're
ready
to
kind
of
have
preview
environments
and
understand
the
impact
that
has
on
developers
and
how
they
deliver
code.
So
that
one
that's
up
to
you
guys
to
figure
out
it's
your
company's.
You
know
you
can.
A
You
can
tell
me
if
it's
going
to
work
there
in
my
experience,
usually
companies
that
are
you
know,
moving
towards
things
like
Argo
and
kubernetes.
They
already
have
a
more
open
mindset
to
things
like
this,
but
if
it's
a
company,
that's
kind
of
like
hey,
we
want
to
use
kubernetes
and
Argo,
but
they're
an
older
Legacy
software
company.
It's
a
little
bit
more
challenging
to
kind
of
bring
that
culture
along.
A
So
let's
talk
about
some
best
practices.
There's
a
lot
here
and
I'm
sure
like
I
have
here
you
guys
already
do
all
of
these
things
right.
So
this
is
not
surprising.
I'm
sure
you
guys
are
experts
at
all
this
stuff.
We
already
talked
about
shift
left,
but
in
general
we
do
want
to
shift
left
now.
That
doesn't
necessarily
mean
we
just
want
to
give
developers
more
work
to
do.
We
just
want
that
to
happen
earlier
in
the
process,
but
we
want
to
assist
them.
A
We
want
to
do
it
in
a
way
that
it
doesn't
create
additional
burden
on
the
development
process
on
you
know
the
delivering
feature
process
and,
of
course
you
know
in
in
along
with
that,
you
know
we
need
to
automate
it
right.
So
that's
kind
of
where
our
Argo
is
coming
into
this
picture.
Here
you
want
to
stick
to
a
consistent
naming
strategy.
This
is
not
something
that
you
necessarily
have
to
do,
but
it's
going
to
make
things
a
lot
easier
like
if
you're,
using
a
pull
request
generator
or
if
you're,
using
sem
generator.
A
Having
that
consistent
naming
strategy
is
going
to
make
it
much
easier
to
set
up
the
Argo
side
to
actually
pick
up
on
things
and
automatically
create
these
environments.
So
it's
a
good
thing
to
have
that
consistent
naming
strategy
and
then
the
third
one
is
really
what
we're
going
to
be
focused
on,
which
is
pull
request,
preview
environments.
This
is
one
of
the
the
simplest
ways
to
start
I
mean
we
obviously
saw
you
can
get
much
more
complicated
than
this
earlier
on.
A
But
if
you
have
a
pull
request
create
a
preview
environment,
you
can
drive
it
off
that
pull
request
information.
It
makes
it
very
easy
to
understand
the
life
cycle
of
it,
so
not
only
when
is
it
created,
but
when
does
it
get
destroyed
and
how
does
it
get
merged
in
you
know.
How
do
we
mix
features
together?
You
can
easily
do
that
by
merging
two
feature:
branches
together
and
creating
a
preview
environment
out
of
that,
in
this
case
I'm
using
labels
on
GitHub.
A
So
you
can
merge
branches
together
and
then
put
a
label
on
that
and
it's
going
to
kick
off
the
process.
So
a
lot
of
flexibility
there,
some
other
cool
things
that
you
can
do
and
I
would
suggest
you
do,
and
this
I'm
going
to
credit
coastus
with
that
I
work
with,
which
is
the
automated
PR
comments,
because
this
is
very
helpful
if
you
are
creating
a
preview
environment,
you
kick
off
a
preview
environment.
A
After
a
pull
request
has
been
created,
it
can
be
very
helpful,
especially
if
it's
a
web-facing
application
to
go
in
and
actually
put
the
address
or
the
destination
of
that
environment.
On
the
pull
request
itself,
because
a
lot
of
times
your
QA
folks,
there
you
know,
especially
if
they're,
going
to
assist
you
with
this
or
maybe
even
other
developers
that
are
going
to
help
you
test
this
out.
They
don't
necessarily
know
where
to
go.
A
I
mean
they
could
go
digging
through
crew
cuddle
right
and
they
could
look
for
your
service
and
look
for
the
namespace
and
try
to
figure
it
out.
But
if
you
have
that
link
there,
it
just
simplifies
the
entire
process.
So
automated
comments
on
there
very
good
thing
to
have
the
next
one
being
smoke
test
is
a
little
bit
trickier.
I
think
we
all
know
that
you
know
everyone
would
love
to
have
you
know
comprehensive
smoke
tests
and
your
end-to-end
testing
is
going
to
take
care
of
everything
for
you.
A
It
would
be
great
if
it
is
part
of
this
process
as
well.
That
may
not
always
be
possible,
but
it's
land
best
practice
like
when
you
spin
up
a
preview
environment.
Ideally,
if
you
have
the
resources,
you
should
run
it
through
the
same
set
of
smoke
tests
and
automated
testing
that
you
have
for
your
regular
integration
environment.
It's
going
to
simplify
things
because
it
might
catch
stuff
like
you,
don't
have
a
verified
or
signed
image
right.
You
have
code
smell
issues
or
whatever.
A
You
want
this
to
automatically
happen,
and
this
is
where
git
Ops
is
really
helping
us
with
this
right.
You
know
it's
declarative
configuration
we're
assigning
a
state.
It
comes
in
cleans
up
the
process,
so
we
want
the
environment
to
clean
itself
up
the
advanced
ones.
We
already
talked
about
culture,
but
Ingress
here.
So
Ingress
is
an
interesting
one.
It
could
be
anything
from
just
routing
a
little
bit
of
traffic
into
a
preview
environment.
A
A
So
where
does
this
fit
in
with
Git
Ops
and
here
I'm
going
to
give
a
little
plug
to
the
open
git
Ops
group,
because
this
is
really
perfectly
in
line
with
preview
environments,
so
you're
looking
for
something
that
is
declarative
and
versioned
and
immutable
pulled
automatically
continuously
reconciled
preview
environments
within
kubernetes
and
Argo
perfectly
fit
into
all
of
those
right.
So
we
have
resources
that
are
defining
out
the
infras,
defining
out
the
environment
that
we
want
to
spin
up.
A
It's
also
stored
in
git
right,
so
the
entire
life
cycle
of
this
is
stored
in
git,
whether
it's
gitlab
or
GitHub
or
whatever
it
is
so
we
can
kind
of
Trace
between
those.
As
far
as
when
I
spin
up
a
preview
environment
I
know
that
it's
either
a
combination
of
these
branches.
It's
this
Branch
here
were
some
additional
commits.
After
we
created
the
preview
environment,
it's
automatically
created,
and
then
it
lives
with
that
life
cycle
of
that
pull
request
as
well.
A
A
So
when
you're
spinning
up
a
process
like
this,
ideally
you
have
a
very
simple
scenario:
when
you're
kicking
off
a
preview
environment,
the
reality
is,
there's
often
supporting
things
that
need
to
be
put
in
place.
You
know
whether
that
is
infrastructure.
It's
additional
Services,
it's
you
know,
whatever
you
really
need
to
put
in
place,
so
I
would
highly
recommend
that
you
learn
the
sync
phases
and
waves,
if
you
don't
know
them
and
really
understand
how
to
use
the
hooks
to
your
advantage.
A
So
this
diagram
is
technically
not
100
correct,
but
it's
kind
of
how
I
think
about
it,
which
is
git,
is
holding
our
state
argo's.
Attempting
to
sync
our
state
kubernetes
is
our
end
resource
in
this
case,
and
we
have
Precinct
sync
and
post-sync
events.
Here
are
some
examples
that
you
might
utilize
them
for
right.
So
in
our
Precinct
we
might
need
to
validate
our
image
signature
first.
In
some
cases
you
might
need
to
actually
verify
compute
and
service
availability.
A
Now
I
know
you
guys
who
are
all
working
on
cloud.
Are
thinking.
That's
that's
silly.
Like
I
mean
the
cloud
is
just
going
to
spin
up,
but
the
reality
is.
A
lot
of
folks
are
actually
working
with
on-prem
infrastructure
as
well,
where
they
have
requirements
for
compute
and
you
could
potentially
run
out
of
space
or
you
might
need
to
actually
create
a
new
allocation
for
request
for
space.
A
So
having
this
as
a
Precinct
to
say,
hey
I'm,
going
to
need
this
cluster,
these
pods
this
much
resources
so
that
I
can
actually
spin.
This
up
can
be
crucially
important
for
sync
again,
you
can
spin
up
additional
necessary
infrastructure.
So
if
you
have
a
database
requirement,
you
could
create,
let's
say
a
dynamic
Cassandra
instance
populate
it,
get
it
ready
for
this.
You
can
check
if
you
have
service
to
service
dependency,
that
you
need
to
follow
up
on
and
then
postsync.
This
goes
into
what
we're
talking
about
earlier.
A
If
you
want
to
put
a
slack
or
teams
message
out
there
with
an
environment
link
that
can
be
very
helpful,
end-end
testing
workflow
again,
this
is
kind
of
like
the
dream,
but
if
you
had
your
end-to-end
testing,
actually
working
in
a
preview
environment,
that'd
be
fantastic
and
not
shown.
Here
is
actually,
if
you're
in
a
sync
fail
scenario,
but
that's
also
a
valid
use
case.
If,
for
whatever
reason,
the
sync
fails,
what
do
you
want
to
run
in
the
case
of
a
preview
environment?
A
A
lot
of
times,
there's
going
to
be
cleanup
tasks
for
any
of
the
stuff
that
you
previously
set
up
in
either
pre-sync,
sync
or
postsync
all
right?
So
let's
talk
about
the
meat
and
potatoes
of
this,
which
is
Argo
application
sets.
So
this
is
incredibly
powerful.
So
it's
really
meant
to
be
a
very
flexible
approach
to
managing
deployments
across
multiple
repos
applications
clusters
and
more
right.
It's
kind
of
the
catch-all
scenario.
It's
like
okay
I
need
to
go.
A
You
know
this
deep
and
this
far,
how
do
I
do
it
with
Argo
Argo
gives
you
that
flexibility
to
do
that
through
its
generators.
The
generators
offer
different
levels
of
complexity,
depending
on
what
you
actually
need.
You
can
do
something
as
simple
as
a
list
generator
where
you
just
have
a
list
of
texts
that
it's
going
to
iterate
through
and
create
environments
that
match
that
it
could
be
based
on
merges
pull
requests,
The
Matrix,
which
I
think
of
a
matrix
like
a
slot
machine
where
you
pick
how
many
lines
you
want
to.
A
In
our
case,
we're
using
that
pull
request
generator.
That
I
was
talking
about
earlier,
which
allows
us
to
dynamically.
Have
an
Argo
application
set
monitoring
for
pull
requests
in
our
case,
it's
looking
at
a
label.
It
could
be
based
on
a
branch
name
filter
as
well,
but
right
now
it's
just
going
to
be
looking
for
a
pull
request,
label
that
says
preview
or
whatever
you
want
to
use,
and
it's
going
to
kick
off
that
process
all
right.
A
So
let's
talk
about
what
we're
going
to
try
to
demonstrate
here
and
again
I'm
just
going
to
I
said
this
earlier,
but
to
someone
else
last
time,
I
tried
a
demo
for
the
cncf
Amazon
went
down
globally,
so
we're
going
to
give
it
a
run
and
see
how
it
goes
this
time,
but
we're
going
to
start
here
by
just
kind
of
walking
through
from
a
simple
perspective.
So
I
have
my
main
branch.
A
A
What
we're
going
to
do,
though,
is
we're
going
to
create
a
PR
Branch
here.
You
know
in
this
case
it's
called
feature
update
Index
this
commit
Argo
is
actively
monitoring
that
repository.
So
it
knows
that
we
have
a
pull
request
based
on
the
label
that
we
put
on
there
or
again
it
could
be
a
filter
based
on
naming
that
you
actually
picked.
A
It
then
updates
the
application
and
creates
a
new
namespace,
creates
the
application
inside
of
your
cluster,
whatever
that
destination
cluster
it
is,
and
this
could
be
n
number
of
clusters
right,
it
could
be
1
or
10
really
depends
on
what
you
want
and
we're
going
to
have
this
preview
environment
that
out
there
for
us
ready
to
go
so
once
that's
out
there,
it's
gone
through
all
of
our
testing.
We
validated
it.
You
know
we
did.
Our
own
smoke
tests
went
out.
Did
some
Epi
testing
against
it?
We
know
it's
in
good
shape.
A
A
This
is
intentional
because
again
we're
merging
into
an
integration
where
all
the
features
going
in
together
and
then
that's
going
to
update
our
staging
or
our
static
environment,
up
to
the
new
version
that
we
were
just
testing
and
playing
around
with
all
right.
So
let's
try
it
so
the
first
thing:
let's
take
a
look
here,
all
right.
A
Let's
just
take
a
look
at
the
repository
real,
quick
there's,
a
few
things
I
want
to
point
out,
the
first
being
that
if
we
want
to
create
them
from
the
CLI,
here's
the
commands
to
create
the
base
app
and
the
app
set
itself
just
simplifies
that
a
little
bit.
Let's
talk
about
what
we
have
in
our
home
here.
This
is
really
simple
and
straightforward.
A
In
a
real
scenario,
you're,
probably
going
to
have
customized
with
overlays,
that's
going
to
Overlay
certain
values
for
your
each
of
your
environments,
but
in
this
case
we
just
have
a
Helm
chart
and
there's
a
couple
of
values
that
are
critical
in
here.
Really
it's
this
namespace
one
and
our
tag,
so
our
namespace
is
going
to
be
dynamically
created
based
on
the
name
of
the
feature
Branch.
A
The
tag
itself
will
change
depending
on
you
know,
what's
happening,
whether
we're
merging
up
to
main
or
if
we're
just
building
out
a
preview
environment,
and
if
we
go
back
here,
we
can
take
a
look
at
the
world's
simplest
go
web
server,
which
is
kind
of
intentional.
So
we
just
have
a
web
server
here.
It's
just
saying:
hey
hello,
get
Ops
con
I'm
on
release
version
one
and
let's
go
ahead
and
let's
take
a
look
at
our
namespaces
right
now,
so
we
don't
really
have
anything
out
there
at
the
moment.
A
Let's
take
a
look
at
our
pods,
that's
not
in
Cube
system,
and
we
see
again
we
don't
really
have
anything
there.
So
let's
go
ahead
and
create
our
base
application
using
the
CLI
all
right
so
far,
so
good,
so
we'll
see
that
this
is
already
spinning
up
we're
creating
our
base
application
now
and
for
this
this
is
looking
at
the
main
branch
at
this
point
and
we
haven't
actually
created
our
app
site.
Yet
the
thing
that's
going
to
take
some
time
here
is
we're
actually
getting
a
load
balanced
URL.
A
So
we
can
click
through
to
it
very
straightforward
stuff
here.
But
if
we
go
take
a
look
at
our
namespaces,
we
have
our
staging
namespace
now
and
let's
take
a
look
at
our
pods,
we
see
that
we
have
a
simple
deployment
now
running
in
our
staging
namespace
and
let's
go
to
the
cheater
window
here
and
click
through.
A
So
inside
of
our
app
set,
there's
a
couple
of
things
that
I
I
really
want
to
make
sure
that
I
highlight
here,
because
it's
crucially
important
for
us.
The
first
thing
being
that
your
name
here
and
your
naming
schema
for
your
namespace
is
very
important
because
that's
what
either,
if
you
have
a
manual
cleanup
process,
that's
going
to
have
to
run
with
this
or
you
have
something
depending
on
where
this
namespace
is
going
to
be
deployed.
A
You
want
to
make
sure
your
namespace
is
consistent
and
that
your
developers
kind
of
stick
to
a
consistent
naming
practice
here.
The
other
thing
being.
We
are
passing
through
the
image
tag
and
again
this
is
so
that
we
can
promote
between
environments
and
also
have
a
preview
environment,
and
so
we
will
go
ahead
and
create
this
as
well,
and
we
do
have
create
namespace
equal,
true
run.
A
This
technically
isn't
really
necessary
for
us,
because
we
actually
have
a
namespace
resource
in
our
home
template
and
the
reason
that
we
have,
that
is
so
that
it
dynamically
gets
cleaned
up
when
we
merge
the
pull
request.
But
if
we
go
take
a
look
at
our
application,
we
can
see
that
it
did
deploy
out.
We
have
a
incredibly
tiny
hello,
get
Ops
con
V
1.0.
A
So
we'll
just
call
this
apps
apps
default,
we'll
do
automatic,
sync
I
do
like
prune
and
self
heal
use
our
Repository,
and
this
is
actually
in
the
app
setbucket
we'll
do
in
cluster
and
then
for
this
case,
because
this
is
Argo
managing
Argo
applications.
We
actually
want
to
put
this
in
the
Argo
CD
namespace,
for
this
particular
example.
A
A
A
We'll
update
the
index
and
then
this
is
a
very
important
part
here.
We
have
to
actually
select
our
preview
label
because
this
is
what's
going
to
kick
off
our
process
because
again
in
that
app
set,
we're
actually
monitoring
for
that.
Let's
create
this
now
because
it's
an
actual
code
change.
This
is
actually
going
to
depend
on
a
CI
process,
so
we
do
actually
have
the
build
happening
here
and
there's
nothing
really
too
crazy.
Going
on
here.
A
All
it's
going
to
do
is
actually
clone
it
down,
build
a
Docker
image,
push
it
out
so
that
it's
available
for
our
preview
environment
here
so
that'll
take
a
second
to
happen
once
that
kicks
off,
then
we'll
start
to
see
this
go
green.
In
the
meantime,
Argo
itself
is
actually
going
to
attempt
to
sync
it
now
I.
What
I
need
to
do
eventually
is
put
in
a
little
bit
of
a
pause
here
or
actually
have
it
be
web
hook
based.
A
So
we
know
when
it's
actually
ready
to
kick
off
that
process,
because
this
will
go
into
a
holding
pattern
until
our
Docker
image
is
actually
built
and
pushed
out
there,
which
is
happening
right
now,
all
right
so
that
has
been
pushed
and
if
we
go
back
to
GitHub
here
now,
we'll
see
this
go
green
and
that
our
checks
are
all
good.
So
in
other
words
our
CI
build
actually
happened.
A
Let's
go
back
in
and
look
at
our
application
and
we
can
see
that
we
actually
have
a
deployment
out
and
it
has
our
new
tag
information.
So
let's
look
at
our
namespace
now
so
now
we'll
see
that
we
actually
have
a
simple
deployment
feature
update
index
5
namespace.
So
that
is
a
mouthful,
but
that
is
definitely
the
namespace
that
we
want
and
if
we
take
a
look
at
our
pods
here,
we'll
also
see
that
we
have
the
Pod
running
as
well.
A
A
We
can
see
that
we
are
now
on
version
2.0
for
this,
and
our
staging
environment
is
still
on
1.0
all
right,
so
everything
is
actually
going
smoothly,
which
is
always
nice.
So
let's
go
ahead
and
merge
this
pull
request.
So
what
we
want
to
happen
like
I,
showed
in
the
slide
earlier
is
we
want
it
to
basically
clean
itself
up
right
when
we
merge
this
pull
request.
We'll
have
our
preview
environment
will
no
longer
be
needed
because
it's
been
merged
into
main
branch.
A
A
And
this
time
the
CI
build
is
just
slightly
more
complicated,
we're
cloning
we're
building
the
image,
we're
actually
going
to
update
the
Manifest
image
tag
and
then
we'll
push
that
image
and
image
tag
out
so
very
straightforward.
But
it's
going
to
give
us
the
end
result
that
we
actually
need
here
and
let's
go
take
a
look
we
can
see.
This
is
already
saying
no
it's
out
of
sync.
We
actually
no
longer
need
this,
so
this
is
going
to
work
on
cleaning
it
up
and
you
can
see
it
did
already
clean
up
that
application.
A
So
right
now,
I
had
it
set
on
a
rikue
timeout
of
15
seconds.
So
Argo
pick
that
up
pretty
quickly
and
if
we
look
at
our
apps
that
our
apps
that
no
longer
has
a
Dengue
dangling
application
off
of
it,
because
it's
no
longer
necessary
and
if
we
take
a
look
at
our
namespaces
again,
we
no
longer
have
our
simple
deployment
feature
update,
namespace,
take
a
look
at
our
pods
same
story
right,
so
that's
actually
been
cleaned
up.
So
let's
go
look
at
our
process
where
this
is
at.
A
This
is
actually
already
updated
it
and
pushed
that
out.
So
now,
let's
go
back
here
and
if
we
look
at
our
commit
message,
we've
updated
the
image
tag
to
this
new
version,
which
is
a9f4475
not
that
that
really
matters
that
much.
But
it's
meaning
that
hey
our
main
branch
did
get
this
new
tag
that
we
just
built
and
if
we
go
into
our
Argo
applications
here
and
I
go
into
our
base
app.
We
haven't
actually
seen
an
update,
yet
here
so
I
didn't
change
out
the
reconciliation
timeout.
So
it's
still
set
to
three
minutes.
A
So
let's
go
ahead
and
just
manually
refresh
this
that's
going
to
say:
oh,
we
actually
have
a
new
application
that
needs
to
be
deployed
out
here.
It's
going
to
go
ahead
and
sync
that
up
and
now,
if
we
go
back
to
just
go
back
here,
if
we
refresh
this,
we'll
see
that
we
only
have
one
external
load
balance
URL,
it's
in
our
staging
namespace.
Let's
click
through
to
that,
and
we
can
see
that
now
we
do
have
our
preview
environment
at
version
2.0
up
there.
So
yeah
I
think
that
covers
everything.
A
Let
me
go
through.
I
think
I
have
one
more
slide
here,
which
is
just
to
talk
about
some
challenges.
Some
of
these
are
going
to
be
obvious,
some
not
so
much
if
you
have
to
automate
a
lot
of
non-kubernetes
infrastructure.
This
could
be
painful.
You
might
still
need
to
do
it,
but
it
won't
be
fun.
If
you
have
a
ton
of
service
to
service
dependencies,
you
really
need
to
understand
the
entire
landscape
of
what
you
want
to
test
against
and
know
what's
reasonable
to
actually
pull
into
a
preview
environment.
A
We
kind
of
already
covered
it,
but
even
outside
of
load
testing.
If
you
have
performance
dependent
Services,
it
can
be
very
tricky
to
do
preview
environments
for
particularly
if
you're
doing
something
like
automated
learning
or
things
like
that.
It
can
be
very
difficult
to
actually
get
a
good
test
run
through
this
comprehensive
cleanup
can
be
challenging,
especially
if
you
are
creating
Dynamic
databases
and
all
sorts
of
other
cool
stuff
collaboration
can
introduce
a
people
process.
A
So
what
I
mean
by
that
is
as
a
developer,
if
I
need
to
test
multiple
features
together
with
someone
else,
I
have
to
go
talk
to
that
person
now,
whereas
before
it
was
I,
would
just
throw
the
code
over
the
wall.
It
ends
up
in
some
integration,
environment
and
someone
deals
with
it
now.
You're
saying
no
I
want
developers
to
be
a
bit
more
proactive
about
talking
to
other
developers,
understanding
how
their
features
interact
and
test
them
together.
A
That
can
be
challenging,
but
it
needs
to
happen
and
then,
as
is
any
kubernetes
presentation
and
Argo
Secrets
is
always
a
challenge.
I,
don't
think,
there's
really
ever
an
easy
solution.
You're
probably
gonna
have
secrets
that
you
need
to
deal
with
whether
it's
injecting
through
sidecars
or,
however,
you
want
to
do
that,
sealed,
Secrets
or
stops
or
whatever
you
want
to
use,
but
that
can
be
challenging
and
that's
it.
Yep
I
do
have
the
repo
here.