►
From YouTube: Implementing Preview Environments with GitOps in Kubernetes - François Le Pape, Remazing
Description
Implementing Preview Environments with GitOps in Kubernetes - François Le Pape, Remazing
Implementing Preview Environments with GitOps in Kubernetes: how to spin up ephemeral environments on the fly at each Pull-requests for the delight of your team. Have you ever experienced a delayed-release because your Staging environment was broken by another feature? Ending up merging a non-production tested Hotfix branch to your Main branch? Preview environments are an answer to increasing velocity inside your team. Kubernetes combined with GitOps allow you to quickly create and destroy resources along with keeping a clear code history and infrastructure changes in Git. Using Bitbucket Pipelines for Continuous Integration and ArgoCD for declarative Continuous Delivery, we will go through different challenges you can encounter to deploy Preview environments such as Secrets management with Sealed Secrets, splitting repositories, and clearing resources to prevent further costs.
A
A
C
C
First
about
me,
as
my
accent
can
show
you
I'm
french,
but
I
am
working
in
hamburg,
germany
with
weather,
maybe
a
bit
different
from
spain
from
spain
for
the
one
that
already
visited
the
city.
I
work
at
I'm
devops
engineer
at
remazing,
which
is
a
mid-sized
company,
but
we
have
a
very
small
team
tech
like
roughly
10
persons,
so
maybe
not
the
same
scale
at
some
companies
before
and
on
my
free
time
I
like
open
source.
C
So
I
joined
the
see
release
team
of
kubernetes
for
the
last
release
and
for
the
summer
I
will
pose
a
bit
open
source
and
maybe
come
back
in
the
winter
about
the
company.
So
you
can
understand.
What's
why
would
it
preview
environments?
So
it's
a
agency
with
a
software
that
we
build
in-house.
We
sell
to
other
companies
and
this
software
is
multi-tenant
and
I
will
maybe
refer
it
later
during
the
talk
as
remdash
and
that's
for
this
software
that
we
built
previous
environments.
C
So
one
year
ago,
again
like
not
so
long
ago,
we
still
used
a
basic
workflow
for
our
main
software,
so
we
have
plenty
of
microservices,
but
this
one
had
a
simple
git
flow,
so
we
had
a
team
of
developers
and
they
are
pushing
to
staging,
and
then
you
have
everything
deployed
on
staging
environment.
So
it's
just
one
branch
staging
deployed
everything.
Fine,
and
when
you
want
to
merge
on
production
we
do
it
every
monday.
C
We
is
a
request,
a
release
or
hotfix
and
we
merged
on
production.
It's
deploying
production,
it's
kind
of
nice.
So
imagine
someone
push
a
good
comment
and
you
have
maybe
I
don't
know
10
15
per
request
before
this
release
day
and
someone
pushed
a
wrong
comment.
What
will
happen
it
comes?
It
can
seem.
Maybe
like
super
simple
and
the
code
looks
great,
so
you
have
the
approval.
It's
got
merchant
staging,
but
yeah
too
bad.
You
couldn't
test
it
very
well
and
staging
is
broken.
So
how
do
you
deploy
on
monday?
C
C
C
So
super
easy
and
it's
fast
like
if
you
want
to
deploy
something
in
production,
you
just
have
to
create
one
through
request,
two
staging
and
then
one
prequest
to
production
and
it's
easily
merged
in
production.
Let's
say,
but
you
have
some
cons
that
are
added
to
those
two
nice
pros.
First,
one
it's
hard
to
reduce
and
test.
So
let's
say
someone
is
going
to
merge
something
on
staging.
You
want
to
review
it.
You
will
need
to
check
out
on
the
branch
pull
the
branch
test.
C
C
C
They
may
want
to
push
as
much
as
possible
new
codes
to
test
okay,
let's,
let's
try
to
break
it
to
see
if
it
works
and
without
breaking
breaking
staging,
because
staging
a
lot
of
persons
are
working
with
staging
or
qa.
But
if
you
let's
say
work
with
previous
environments,
which
would
be
a
new
thermal
environment
aside,
you
can
break
it.
It's
meant
to
be
break
which
is
very
good
and
yeah,
as
I
said,
other
difficulties
to
test
new
infra.
So
let's
say
you
want
to
test
radius
or
a
mail
server,
whatever
it's
hard
to
manually.
C
Add
it
to
staging
without
modifying
the
other
features
that
are
on
your
staging
and
last
one.
As
I
said
before,
one
pull
request:
one
feature:
one
branch
can
break
the
world
staging
which
will
then
you
will
need
to
fix
this
feature
without
it.
You
cannot
merge
to
production,
so
it
will
slower
your
time
to
market
and
in
a
startup
environment.
Let's
say
time
to
market
is
very
important
because
you
want
to
to
be
better
than
the
other
tools,
so
that
led
us
to
this
great
schema,
and
this
one
is
about
previous
environments
and
git
ups.
C
So
I
will
say
there
are
two
main
features.
Why
get
ups
is
useful
if
people
there
you
want,
you
have
other
receipts,
I
mean
if
you
don't
want
to
stand
so
about
get
ups.
You
have
two
main
features
where
you
want
to
to
maybe
use
github's
preview
environment.
Maybe
you
deploy
all
your
infrastructure
or
all
the
the
rest
with
git
ups
principles
and
it
just
copy
paste
basically
to
deploy
it
in
previous.
C
C
So
it
allows
you
to
to
test
basically
how
github
works,
different
tools
like
operators,
flux
or
argo,
and
because
it's
it's
a
step
before
staging
it's
very
likely
to
break
so
very
good.
Because
then
you
can
you
can
test
what
happens
if
you
have
a
wrong,
you
have
a
drift
and
you
need
to
reconcile
it.
You
have
resources,
breaking
maybe
databases
you
manage,
so
I
will
say
the
best
way
to
start
githubs.
C
As
you
can
see
here.
It's
quite
simple.
I
will
go
through
all
the
steps,
but
it's
easily,
like
often
you
push
code
to
like,
let's
say
developers,
push
codes
on
to
a
code
repositories,
github
bitbucket.
In
our
case
it's
bitbucket
and
you
will
see
in
the
following
presentation
that
billboard
has
some
flaws.
C
Let's
say
that,
maybe
you
don't
have
with
github
or
gitlabs,
so
it
involves
a
bit
of
bash
script
spoil,
and
so
you
push
your
docker
image
to
a
docker
registry
in
our
case
docker
hub
and
then
in
another
step
you
will
just
commit
the
environment,
which
is
just
a
yaml
file
and
a
docker
tag
to
make
it
declarative
and
reproducible,
and
we
commit
this
to
another
repository
ops
repository
where
you
store
all
your
infrastructure
and
then
an
agent.
Let's
say
argo.
We
just
watch
think
and
deploy
to
change
changes
to
different
namespaces.
C
So
in
the
end,
if
you
have
10
pro
requests,
you
have
10
namespaces
in
your
communities,
cluster
accessible
with
different
urls,
yeah
disclaimer
with
argo
cd.
Let's
say
you
have
what's
called
generators,
proquest
generators
which
is
doing
like
which
in
which
is
simplify
most
of
the
steps
that
I
will
talk
about,
but
for
bitbucket,
it's
not
available
yet
so
yeah,
let's
dig
a
bit
into
it.
C
First,
some
pitfalls.
I
would
like
to
to
new
before
implementing
previous
environment.
First
github
is
great
when
you
want
to
when
you
have
a
working
state
at
the
end,
because
everything
is
working
smoothly.
You
can
trace
your
commits
you
you
can
test
like
it's
super
nice,
it's
you
feel
shaved,
let's
say,
but
when
you
test
it
it's
a
mess.
Because
then
you
need
to
push
to
build
an
image.
Wait.
Everything
is
committed
to
the
apps
repo.
So
you
lose
time
so
at
the
beginning.
C
What
I
would
advise
is
to
use
a
tool
like
scaffold
that
will
compact
all
the
steps
build
push
and
deploy.
In
one
case
it
was
just
with
docker
and
helm,
and
we
compile
everything
of
this
to
focus
and
intensify
on
maybe
just
how
the
deployment
will
work,
how
everything
will
fit
for
your
preview
environment.
C
C
You
declare
everything
you
want
for
your
pipeline,
and
so
in
this
case
you
can
say:
okay,
I
want
to
listen
to
two
branches,
so
all
the
branches
that
are
matching
feature
and
the
other
one
fixed,
because
in
our
case
we
didn't
want
to
deploy
a
previous
environment
on
a
very
short-lived
branch
like
hotfix
or
something
we
want
to
be
as
fast
as
possible,
and
this
one
you
trigger
two
steps.
As
I
said,
you
build
and
push
to
a
remote
registry,
remote
docker
registry,
what
to
say,
and
the
second
one
github
cd
step.
C
So
when
you
commit
something
to
the
apps
repository,
so
yeah
a
bit
scary.
So
this
one
is
super
simple,
just
you
log
into
docker,
you
build
your
image
and
you
push
it
to
remote
registry,
but
because
bitbucket
makes
it
a
bit
harder.
Sometimes
there
is
one
step
that
is
good
to
take
a
look.
Look
at.
Is
this
one?
C
So
this
one,
you
export
the
current
tag
where
your
pipeline
is
building
to
a
bash
script
and
you
will
source
it
later
because
all
the
way
what
can
happen,
let's
say
you
have
a
slow
document
building
or
maybe
your
pipeline
doesn't
have
a
lot
of
ram.
You
will
have.
You
will
build
one
docker
image
and
then
you
will
go
to
the
next
step,
the
github
step,
but
then
your
head
of
the
branch,
the
head
of
the
branch,
will
change
so
with
bitbucket.
C
With
this
simple,
like
trick,
let's
say
you
can
be
sure
that
the
two
steps
are
matching
the
same
tag.
Yeah.
I
think.
That's
all
we
have
to
say
about
it,
the
second
one
which
is
a
mix
between
cicd,
it's
about
steel
bit
bucket,
so
second
step
git
ups,
first
one
we
don't
want
to
create
a
previous
environment
with
master,
so
we
just
remove
it
at
the
beginning,
as
you
can
see
here,
let's
highlight
it
and
then
we
import
our
environment,
so
we
are
sure
to
match
the
same
tag
as
we
had
in
the
previous
step.
C
C
C
You
can
modify
the
m
shot,
it
will
deploy
and
it
will
deploy
the
previous
environment
with,
let's
say,
more
memory
or
developer,
wants
to
add
redis
for
caching
database
queries.
They
can
modify
it
directly
on
the
code
repo
and
they
don't
have
to
touch
the
infrared
report,
and
for
this
we
just
modify
so
a
previous
file
that
I
will
show
you.
I
think
next
slide
and
we
inject
like
pr
id
pr
names.
So
we
can
build
nice
urls.
C
C
I
mean
you
have
plenty
of
documentation
about
doing
it
and
in
our
ops
repository
we
have
one
file,
the
one
I
told
you
about
with
the
template,
so
we
have
environment
variables
that
will
be
replaced
with
our
current
environment
and
inside
of
it
you
put
everything
you
want
like
the
one
which
we
use
useful
for
the
url.
You
can
put
other
values
file.
Let's
say
everything
is
customizable
and
argo
will
watch
this
file
and
deploy
it
accordingly
and,
as
you
can
see
here,
we
have
the
target
revision
just
here
to
help
you
a
bit
more.
C
This
one
is
set
to
the
branch
we
are
working
on,
so
the
the
pro
request,
let's
say,
and
so
every
change
will
be
detected
by
argo
and
argo
will
reconciliate
and
then
why
argo
cd,
I
feel
like
there
is
a
big
yeah.
There
are
other
tools,
but
in
our
case
it
was
mainly
is:
do
we
use
flux
or
argo
cd?
We
use
flux
for
everything
related
to
infrastructure,
so
primitives,
graphene,
ingress,
controller
traffic,
salt
manager,
cube
city
secrets
whatever,
and
it's
nice
it
works
nicely.
It's
a
cli.
C
C
So
that's
why
we
kept
flux
for
the
infrastructure
and
argos
did
to
deploy
previous
environments
about
it
just
quickly
about
the
flex
structure.
In
our
case,
we
have
one
folder
per
cluster.
We
have
three
four
clusters,
so
it
works
nicely.
Maybe
if
you
scale
up,
you
want
to
change
this
way
of
working,
but
in
our
case
it's
working
super
nicely.
C
So
in
anger,
cd,
we
manage
argo
cd
itself
by
ago
city,
in
apps
of
apps
concept
and
inside
the
previous
arm,
folder
that
I
can
highlight
here,
that's
where
we
commit
all
our
previous
environments.
So
if
you
check
master
branch
of
argo
cd
repository,
you
will
see
all
the
previous
environments
that
are
deployed
which
make
it
easy
to
delete
afterwards
when
you
close
the
branch,
when
you
close
a
when
you
merge
a
pr,
you
just
delete
the
file
that
is
responsible
for
the
previous
environment,
so
as
well
for
resources.
C
C
You
always
have
this
way
where
you
start
to
committing
your
secrets
to
a
repository.
Hopefully,
a
local,
I
mean
a
private
one
that
you
just
test
stuff
in,
but
then
later
you
want
to
just
store
your
secrets.
So
let's
say
database
credentials
or
anything
like
api
keys,
docker
hub
secrets
to
access
your
private
registry
and
in
our
case
we
will
still
secret.
So
it's
super
easy.
C
You
just
install
sil
secret
and
you
have
a
small
cli
to
use
it
and
what
you
will
commit
is
only
the
still
secret
part,
which
is
a
crd,
and
this
will
be
encrypted
with
a
key
of
our
controller.
So
no
one
has
access
to
this
key
except
the
controller.
So
you
can
give
ups
or
admins
access
to
this
key
and
only
them
can
encrypt
secrets.
And
so
then
you
can
commit
safely
to
get
it's
the
easiest
way
with
fun.
C
I
know
there
are
a
vault
or
whatever
that
you
can
use
but
as
let's
say
fast
to
implement,
it
was
kind
of
very
good
and
then
in
your
cluster
you
have
the
secrets
additional
tip.
If
you
use
helm,
let's
say
you
can
use
condition
so
a
simple:
if,
okay,
if
you
are
deploying,
let's
say
a
production
environment
or
you
are
testing
with
local,
you
can
use
a
different
secret
file
that
you
encrypted
with
maybe
your
local
kind
cluster
key
or
your
staging
cluster
or
whatever,
which
makes
it
easier
to
test.
C
C
Then,
let's
talk
about
the
multi-tenants
so
for
our
applications
at
our
company
rendash
we
have
a
multi-tenant
setup
and
for
every
previous
environment.
So
for
every
pro
request
created
we
want
a
url
and
for
each
url
we
have.
We
want
a
client
on
top
of
it.
So
anyone
can
you
can
test
different
clients.
If
you
sit
clients,
you
can
test
them
easily
and
it
causes
a
bit
of
problems,
because
at
the
beginning
we
hardcoded
on
traffic,
the
wildcard
and
then
how
do
you
do
this?
C
Do
you
modify
the
traffic
manifest
which
is
at
the
core
in
another
infrareport?
Because
it's
just
a
tool:
that's
using
the
cluster,
it's
not
in
the
argo
cd
repo.
So
what
we
use
is
we
combine
traffic
as
in
ingress
controller
and
self
manager,
another
tool
that
will
manage
https
the
great
thing
about
start
manager.
It's
it
will
give
you
as
well
high
availability,
because
then
traffic
won't
have
to
manage
all
the
secrets
and
stuff.
So
those
two
working
together
are
deployed
with
flux,
and
I
will
show
you
next
step.
C
So
that's
how
we
manage,
like,
let's
say,
infrastructure
to
previous
environment.
So
in
one
side
you
have
all
the
search
manager
stuff,
so
you
have
the
helmet
repository
with
cm
for
cell
manager,
so
we
installed
self
manager
with
flux.
We
have
our
cluster
issuer
responsible
for
dns,
wildcards
and
or
in
our
case
digital
sound
secret,
but
you
can
put
any
cloud
provider
spreads
cloudflare
whatever,
and
with
this
once
it's
set
up
all
the
previous
environment
stuff.
C
All
the
argo
will
use
those
resources
so
for
each
environment
that
you
commit,
you
will
have
a
certificate
which,
inside
of
it
the
name
of
the
url.
You
want
to
give
it
and
to
generate
your
wildcard
and
then
ingress
route,
matching
the
secrets
created
by
this
secret
certificate,
and
you
will
have
one
card
on
the
floor
so
for
any
pro
request
created,
you
have
wildcard
certificate,
which
is,
I
find
super
nice,
no
need
to
ssh
into
the
pods,
install
search
bot
whatever.
C
Let's
another
challenge
we
had
to
to
go
through,
let's
say
with
what
are
with
our
elasticsearch
database
is
the
hooks.
We
have
helm
and
that's
how
we
deployed
at
the
beginning
and
with
helm.
You
can
easily
match
them
with
hooks
on
argo
city,
so
hooks
we
just
basically
say:
okay,
every
time
you
reconciliate
and
you
deploy
something
or
you
yeah
in
post-install
mode.
You
will
just
run
a
job,
for
example,
and
then
you
can
run
long-running
operations
after
each
deployment.
C
In
our
case,
we
want
everything,
text
related
to
be
indexed,
and
so
it
runs
on
the
flow.
It's
super
nice
and
you
can
imagine,
I
don't
know
applying
to
whatever
you
want.
So
if
you
want
to
see
new
clients,
new
data,
yeah
testing,
fake
data,
you
can
do
it
on
every
deployment
you
can.
Even
maybe
like
wipe
the
database
and
re
reseed
with
random
data,
everything
makes
it
easy,
then
about
namespace.
C
I
don't
know
who
is
using
lens
here,
but
then
it's
super
nice
because
you
can
give
a
drop
down
and
you
can
see
all
the
your
name
spaces
in
your
kubernetes
cluster,
but
as
well
when
you
do
cubesatl
get
namespaces
after
a
while.
Imagine
I
don't
know
you
release
20
requests
per
week
or
way
more
depending
on
the
size
of
your
organization.
You
will
have
a
huge
list
of
name
spaces
and
then
you
will
start
to
graph
into
the
namespaces
to
find
the
good
one.
C
It's
a
mess
so
an
easy
way
to
do
it
with
argo.
You
can
create
the
namespace
easily
with
adding
just
one
option,
but
you
cannot
delete
it
easily,
and
so,
if
you
create
a
namespace
resource,
then
argo
when
you
delete
the
previous
environment
file
will
go
through
all
the
resources
secrets,
whatever
delete
them
and
then
at
the
end,
we'll
delete
the
namespace
itself.
So
you
don't
hang
up
with
empty
namespaces
in
your
cluster.
C
Now,
let's
talk
about
developer
experience,
because
the
main
goal
of
previous
environment
is
to
improve,
let's
say
time,
to
market
developer.
Velocity,
like
the
you
want
to
push
comments
like
to
test
better
features
and
to
push
more
comments,
so
yeah
a
bit
of
bash,
not
too
hard,
though,
before
deploying
we
check.
If
you
know
ops
repository,
there
is
an
environment
file
so,
as
you
can
see
first
line,
and
if
so
we
just
commit
on
the
pro
request,
so
I'm
sure
there
are
other
tools
to
notify
which
trades
like,
but
the
best.
C
It's
still
on
the
pro
request,
you
left
a
comment.
Okay,
this
is
the
url
of
your
previous
environment.
So
when
a
developer
is
test,
they
open
the
pro
request.
They
have
their
automated
commit,
they
click
on
it
and
they
have
their
previous
environment
where
they
can
do
anything
they
want,
they
can
break
anything.
They
won't
slow
down
the
release
that
will
soon
come
to
production.
They
can
try
to
break
it
and
that's
we
want
if
the
pro
the
previous
environment
is
broken,
that's
good,
because
no,
no
clients,
no,
no
one
cares.
C
If
the
previous
is
broken,
it's
meant
to
be
broken.
Another
one
is
the
good
thing
with
argo.
Cd
is
the
ui,
so
you
want
to
expose
this
way
to
give
it
access
to
your
users
or
developers.
I
mean
by
users,
I
mean
developers,
so
you
can
easily
add
an
ingress
route.
Let's
say
you
have
a
traffic,
so
you
had
an
ingress
route.
You
can
secure
it
with
passwords.
C
So
I
don't
know:
what's
the
default
five
too,
but
to
speed
up
a
bit
the
things,
especially
if
your
docker
build
time
is
taking
long.
You
can
use
what's
called
a
web
book.
So
I
guess
everyone
is
familiar
and
you
can
set
it
up
with
bitbucket
easily
and
then
every
time
you
have
a
change
on
your
ops,
repo.
C
It's
kind
of
nice
a
bit
dirty,
but
it
works
well
and
tips
depends
of
your
maturity
in
security.
But
at
the
beginning
we
were
pre
pre.
We
are
like,
let's
say,
refusing
roots
to
the
containers,
but
then
you
cannot
install
packages.
If
you
want
to
debug,
you
cannot
like
ssh
and
then
start
to
create
files
modifying
stuff.
C
So,
in
the
end
for
previous
environment,
not
production,
I
think
it's
a
good
idea
to
just
allow
roots
to
debug,
but
that's
a
close
environment
like
so
it's
fine
and
last
but
not
least,
thanks
to
flexity
maintainer
kingdom.
I
think
on
the
slack
and
if
you
have
questions
slack
channels
are
great
like
cncf
or
kubernetes.
C
He
told
me
about
this
renovabot,
which
is
a
life
changer
honestly.
So
the
problem
with
installing
resources
is
over
the
time
you
have
upgrade
patches
or
security
issues
that
happens,
or
maybe
you
will,
I
don't
know,
stay
for
one
year
to
the
same
0.5
versions
and
you
want
to
upgrade
automatically
and
you
can
run
this
bot
on
bitbucket,
so
it
will
just
run,
let's
say,
weekly
daily,
depending
of
how
you
trigger
your
pipeline
automatically
and
then
create
pull
requests.
You
would
say:
okay,
your
let's
say
your
loki
instance
need
to
be
upgraded.
C
You
can
change
the
change
logs.
Okay,
you
compare
what's
changing.
Do
I
need
to
do
something
manual?
Maybe
remove
some
crgs.
I
don't
know,
and
then
you
just
click
merge
and
you
have
up
to
date,
clusters
and
tools
so
great
tool,
and
that
was
the
last
slide.
So
thanks
for
everyone
to
listening,
maybe
change
a
bit
of.
I
don't
know
huge
clusters
and
stuff,
but
that's
how
we
do
it
in
house
and
previous
environments
really
helped.
C
Now
you
can
really
easily
test
features
and
with
git
apps,
it's
a
nice
way
to
to
start
using
git
ups.
Let's
say
before
going
to
production
and
maybe
if
something
breaks
you
don't
want,
I
don't
know
bad
things
to
happen
and
that's
it
thanks,
especially
git
sapscon
and
kubecon.
If
you
have
any
questions,
let
me
know.
A
D
C
Why
flux
so
at
the
beginning,
it
was
just
a
random
choice.
Let's
say:
let's
pick
flux,
it
looks
great,
it's
working
well
with
the
helm,
so
I
started
with
with
flux
and
then
when
doing
something
for
developers
cli
I
mean
cli
is
not
the
best
like
to
to
see
quickly
a
change.
You
need
to
learn
a
cli
tool
and
stuff.
So
the
ui
of
ago
cd,
I
checked
there
was
no
project
from
flux
to
have
a
ui,
but
it
doesn't
seem
like
continuated
or
well
updated.
C
A
C
E
C
C
Applications
applications
set,
it's
still
hard
to
say
it
seems
really
good
for
if
you
want
to
generalize
stuff
and
to
maybe
deploy
to
several
clusters
or
stuff,
but
in
our
case
it's
working
great
and
maybe
we'll
move
to
application
application
set
later
I
saw
I
mean
I
wish
that
the
bitbucket
is
integrated
into
the
pull
request,
generator,
which
was
may,
which
will
make
listening
on
events
way
like
faster
and
better,
and
we
can
ditch
the
world.
I
guess
commits
parts
inside
the
pipeline,
so
yeah
future
step,
but
so
much
to
do
like
observability
monitoring.
C
C
So,
what's
the
longest
part
is
the
docker
build
image
because,
especially
with
larval,
we
it's
kind
of
heavy
and
you
need
to
build
engine
x,
php
fm
we
use
mix.
So
you
need
to
pull
a
part
of
the
image
in
the
back
end.
It's
a
bit
of
a
mess
but
to
deploy
the
environment
is
super
fast
because
we
use
some,
let's
say
subshots
like
for
radius
or
sql.
So
everything
starts
quite
easily.
C
It's
not
resource
intensive,
because
it's
just
a
level
app.
It's
not
like.
You
start.
I
don't
know
a
huge
parameters
cluster
or
whatever.
So
it's
super
fast,
I
wouldn't
say
in
minutes,
but
for
the
build
time
it's
roughly
five
minutes
and
then
to
commit
bitbucket
is
a
bit
slow.
I
would
say
no
offense
if
there
are
big
buckets
people
here,
but
I
don't
know
it's
a
bit
slow
to
like
get
the
cash
instead
of
everything.
B
C
With
that
so
with
n-testing,
we
use
cypress
and
cypress
use
just
the
same
like
the
same
test
as
we
have
on
staging.
So
we
just
run
on
the
url.
We
have
and
then
uranus,
I
press,
maybe
okay,
so
we're
just
doing
end
testing
easily.
And
if
you
want
to
test
on
the
docker
image,
you
would
just
add
docker
build,
look
or
push
and
in
between
you
just
build
it
with
a
with
the
test
tools
and
run
the
test.
So
if
it
breaks
it
even
breaks
before
deploying
to
the
the
previous
environment,
so
they
just.
C
I
mean,
I
guess
you
have
several
ways
to
trigger
it.
Maybe
you
can
run
like
your
end-to-end
testing
as
like
a
post-install
job,
a
helm
job
that
will
run
some
smoke
testing
and
other
test
conformance
tests.
You
want
to
have
on
your
cluster
and
you
have
so
many
options.
You
can
run
them
in
the
pipeline.
Maybe
after
it
got
deployed,
then
you
wait
until
the
state
is
reconciliate
and
you
deploy
your
test
or
the
way
I
will
you
use.
It
is
with
the
helm.