►
From YouTube: Ephemeral Environments Paradigm Powered by Spin... Christos Arvanitis & Edgar Ulises Garcia Gallegos
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Ephemeral Environments Paradigm Powered by Spinnaker - Christos Arvanitis & Edgar Ulises Garcia Gallegos, Armory
How do you run a full test cycle in a short-lived production replica environment in the most reliable, easy and cost effective way possible? How do you give your stakeholders an early view of the new features before your code is merged? And how does this workflow across the SDLC look for us at Armory? In this session we will explore how Spinnaker can unlock the paradigm of ephemeral environments for software and product teams and how we can bring production closer to development before the code is merged. Using Pipelines as Code and from Github actions to Spinnaker, Edgar and Christos will present and demo an end-to-end workflow spawning on-demand Spinnaker environments.
A
Today
we
will
talk
about
the
ephemeral
environments
which
you
may
know
as
a
preview,
dynamic
or
PR
validation
environments
powered
by
Spinnaker
by
Spinnaker
how
we
are
using
Spinnaker
to
spawn
up
the
femoral
environments.
What
it's
not
included
in
the
title
is
how
we
are
using
this
paradigm
in
Armory
to
test
our
release
process
and
validate
and
ensure
the
quality
of
our
releases.
B
Hi,
my
name
is
Edgar
Garcia
I
am
Senior
software
engineering
Armory.
How
many
of
you
are
familiar
with
the
Paradigm
of
using
FML
environments
in
your
sdlc?
Also,
how
many
of
you
are
familiar
on
are
currently
using
ephemeral
environments
as
part
of
your
pull
request,
validation.
All
those
questions
is
something
that
we
are
going
to
just
explain
how
you
can
Empower
this
using
Spinal
Care.
B
A
A
It
is
a
short.
It
has
a
short
time
to
leave,
which
is
me,
cancer,
ephemeral
right
so
and
can
be
used
for
automated
testing
demo
or
pocs,
or
simply
Gathering
feedback
from
any
team.
Other
teams
in
your
organization,
like
for
brand
new
product
features
Etc,
so
the
dynamic
nature
of
the
ephemeral
environments
allow
us
to
run
multiple
environments
with
under
on
demand
configuration,
but
at
the
same
time,
with
less
cost
than
having
multiple
static
environments.
A
B
Cool
so
before
going
forward
on
our
use
case,
let's
use
compare
a
normal
staging
environment
with
an
FML
one
using
examples.
So
here's
an
a
basic
example
of
how
an
staging
environment
looks
like
the
basic
flow
of
a
developer
team
is
that
every
developer
Works
in
their
features
independently
and
they
deploy
their
changes
in
an
staging
environment.
Every
new
feature
that
is
deployed,
one
is
deployed
one
by
one
in
the
staging
environment,
has
its
own
environment
configuration
and
limited
production
data.
B
Once
the
feature
is
deployed,
we
used
to
run
a
series
of
tests
to
validate
the
functionality
is
not
broken,
and
one
of
the
things
that
I
would
like
to
highlight
on
this
is
that
we
used
to
have
like
a
queue
of
changes.
So,
most
of
the
time
when
there
is
a
lot
of
changes
that
we
want
to
prove
that
we
used
to
have
a
queue
that
is
waiting
for
the
staging
environment
to
be
available.
B
In
this
other
example,
this
is
for
using
FML
environments.
In
this
case,
we
have
the
same
developers
team
with
their
features,
but
we
have
an
environment,
Factory,
the
environment,
Factory,
irresponsible,
on
create
a
temporal
environment
based
on
an
environment
configuration
and
it
will
load
test
definitions
on
it.
The
feature
is
developed.
The
feature
of
the
developer
is
deployed
as
well
as
part
of
the
FML
environment
creation.
B
One
of
once
the
environment
is
ready.
The
automated
test
will
run
to
validate
the
functionality
and,
after
that,
the
environment
Factory
will
destroy
the
femoral
environment.
As
we
can
see
in
this
diagram,
we
might
have
multiple
environment
running
at
the
same
time
for
validating
different
features
in
all
these
validation
process.
B
Now,
let's
talk
a
little
bit
about
our
use
case
in
Armory
in
our
release
process
for
armored
spinaker
platform,
we
have
a
few
points
to
cover
that
are
interested
in
all
these
process.
We
need
to
validate
functionality
with
multiple
Cloud
providers
across
the
platform
as
a
CI.
Cd
schema
also
support
open
source
Spinnaker
changes
that
comes
through
our
platform
as
we
support
multiple
Branch
multiplayer
branches
for
the
open
source
and
the
Armory
ones.
We
require
Dynamic
configuration
for
those
and
on
failures.
B
B
So
as
we
want
to
validate
the
platform
in
a
pull
request
level,
we
will
have
a
GitHub
action
that
will
sense
a
signal
to
create
and
destroy
the
ephemeral
environment.
So
at
the
end,
this
is
going
to
be
a
custom,
GitHub
action
that
is
only
like
orchestrating
when
a
validation
needs
to
happen.
In
all
these,
like
process
validation
process,
the
next
layer
would
be
would
would
be
the
control
plane,
spinal
cord.
B
We
have
a
spinal
cord
to
help
us
provision
in
infrastructure,
for
the
ephemeral
environment,
for
the
ephemeral,
spanaker
deployed
and
lower
the
end-to-end
test
in
the
family
spanaker.
Also,
the
control
plane
would
be
responsible
on
Destroy
the
femoral
spanner
deployment
and
tear
down
any
infrastructure
that
was
created
as
part
of
this
validation.
B
Finally,
the
last
layer
would
be
the
femoral
spine
occurs.
Those
of
emerald
spanakers
will
be
created
with
pipelines
and
execution,
and
the
execution
for
those
pipelines
will
be.
Will
be
notified
in
the
pull
request
that
starts
the
process.
In
this
way,
we
have
a
big
picture
on
how
the
GitHub
action
and
the
Spinnaker
itself
works
together
to
validate
the
functionality
across
the
releases.
B
Another
key
piece
here
is
the
open
source
Spina
care.
It
is
composed
by
multiply
repositories
like
Cloud
driver,
Orca,
Fiat
and
so
on,
and
the
Armory
Spinnaker
platform
is
composed
by
extension
projects
and
Spinnaker
plugins.
So
in
normally
we
have
a
in-home
service
that
is
responsible
on
watching
the
changes
for
the
open
source,
Spinnaker
repositories,
the
Armory
extension
projects
and
also
the
Spinnaker
plugins.
B
B
In
the
GitHub
action
layer,
the
GitHub
action
is
a
simple
action
that
triggers
all
the
flow.
Every
time
there
is
a
new
pull
request.
The
action
check
out
the
stack,
then
it
triggers
the
create
FML
spanner
pipeline
inner
control
plane
and
pass
all
the
information
about
the
stack
to
choose,
deploy
the
Spinnaker
in
the
same
version
that
is
up
top
of
of
or
pull
requests.
A
A
We
need
to
run
multiple
environments
in
parallel
and
in
isolation
using
the
same
manifest
definitions.
At
the
same
time,
every
generated
environment
should
be
shareable
and
accessible
within
our
company.
Spawning
and
destroying
employee
environment
should
be
reliable
and
triggered
either
Beyond
automated
automated
way
or
manual.
A
Our
control
plane
is
nothing
else,
but
our
production,
internal
production
screen
occur.
The
whole
process
is
defined
in
a
single
ephemeral
environment
repository
where
we
store
the
our
pipeline
has
code
that
everything
the
definitions
for
the
pipelines
for
the
creation
and
the
destroy
of
the
ephemeral
environments.
A
Also,
we
are
storing
all
the
Manifest
for
the
application
stack
and
the
third
party
services.
We
store
the
infrastructure
as
code
for
all.
The
shared
and
the
dedicated
per
environment
resources
we
are
also
store.
The
test
suits
definitions
again
using
pipelines
as
code
and
documentation
around
that.
A
So
as
as
we
needed
as
we
need
every
environment
to
be
fully
Dynamic
and
created
like
we
are
templating
our
manifest
using
customize
without
an
explicit
reference
to
any
configure
and
dynamic
any
configuration
during
the
deploy
stages,
the
spinner
care
is
evaluating
the
variables
and
based
on
the
received,
artifacts
and
add
other
parameters.
It
is
deploying
for
us,
an
ephemeral
environment.
A
So
yeah,
as
we
mentioned
before,
we
are
provisioning,
multiple
environments
in
parallel,
so
every
environment
is
deployed
to
its
dedicated
namespace.
We
are
deploying
MySQL
radius
as
a
persistent
stores
and
also
an
S3
bucket.
We
are
deploying
an
Opa
server
to
test
any
of
our
policy
engine
features
with
some
predefined
policies.
We
are
also
deploying
a
Jenkins
server
with
pre-loaded
C
jobs,
a
Prometheus
server
to
test
the
automatic
automatic
Canary
analysis.
A
We
are
also
deploying
some
kubernetes
resources
and
we
are
enabled
the
kubernetes
provider
and
there
are
more
reagent
as
well
to
test
our
kubernetes
kubernetes
functional
beam
spinach.
Last
but
not
least,
we
are
deploying
the
full
stack
of
Anonymous
environment,
integrated
with
all
the
above
and
ready
to
be
used
as
as
the
system
under
test
all
right.
So
we
will
jump
into
some
demos
right
now
and
hopefully
everything
will
go
away.
All
right.
B
Okay,
so
for
this
demo,
I
am
going
to
choose,
show
how
this
is
working
end
to
end.
So
in
this
example,
this
is
a
pull
request.
That
is
just
it
was
created
because
there
is
a
new
version
of
the
platform
and
we
have
here
a
GitHub
action
that
is
in
charge
of
creating
and
destroying
the
ephemeral
environment.
So
it
just
proved
this.
If
I
Execute
Order
run
this
this
job,
this
is
going
to
start
the
all
the
validation
process
that
we
already
explained.
B
So
the
GitHub
action
is
going
to
check
out
the
project
review,
all
the
artifacts
and
the
definitions
that
the
stack
has
at
the
front
of
the
pull
request.
And
then
it's
going
to
send
a
signal
to
the
control,
plane
or
spanaker
to
just
create
and
spin
up
an
ephemeral
environment.
Then
it's
going
to
create
all
the
infrastructure
and
everything
that
is
required,
but
the
femoral
environment
used
to
start
the
testing.
A
A
Let's
wait
for
GitHub
to
wake
up
for
now
and
we
will
move
to
the
next
demo
all
right.
So,
as
we
mentioned
at
the
beginning,
we
are
using
the
ephemeral
environments,
not
just
for
automated
testing.
We
are
using
the
them
across
multiple
teams.
Our
our
technical
writers
are
using
ephemeral
environments
to
write
up
documentation.
A
Our
sales
Engineers
are
using
ephemeral
environments
to
do
demos
and
pocs.
Our
team
is
using
them
for
debugging
any
issues
with
what
we
are
might
facing
might
or
might
not
facing
with
a
with
a
customer
or
a
release.
So
in
order
to
do
that,
we
needed
a
final
to
find
a
way
to
scale
the
usage
of
the
ephemeral
environment.
If
the
pipeline
is
too
complex
and
to
be
created
by
any
end
user,
we
will
get
pushback.
A
It
will
be
very
hard
to
onboard
new
teams
and
really
this
Paradigm
of
the
ephemeral
environments
to
take
off
in
our
organization.
So
what
we
have
done
is
we
have
verified
pipelines,
and
these
here
these
are
the
pipelines
that
we
have
created.
They
are
verified,
they
are,
we
are
doing
all
the
changes
and
these
are
the
pipelines
to
basically
create
and
destroy
an
ephemeral
environment,
and
once
we
want
to
abort
any
of
the
of
the
teams.
Basically,
there
is
a
simple
PR,
a
simple
pull
request.
A
A
A
Here
it
is
the
new
application
that
we
created
to
two
Pipelines
to
create
and
destroy
an
ephemeral
environment.
So
simple,
as
that,
a
new
team
can
onboard
they
are
Engineers
to
the
to
the
use
of
the
fmri
environments
and
keep
in
mind
that
this
pipeline
might
seem
complex.
But
actually
it's
not
it's
basic
input
process
output
and
we
move
to
the
next
stage
and
at
the
end
of
the
pipeline,
when
the
pipeline
completes,
we
have
an
ephemeral,
spinaker
and
an
ephemeral,
Armory
platform.
B
Okay,
so
moving
back
again
to
My
Demo,
now
that
the
action
is
running
basically,
the
most
important
part
in
all
these
steps
is
that
is
checking
out
the
artifacts
ID
for
all
the
stack
that
we
want
to
test
and
then
it
sends
or
it
triggers
the
ephemeral
spanner
care
in
the
control
plane.
So
this
action
is
actually
leveraged
all
the
responsibility
to
the
control
plane,
passing
all
the
information
about
what
Spinnaker
or
what
versions
of
all
the
services
needs
to
be
deployed.
B
Yeah,
so,
as
you
can
see,
this
is
an
a
pipeline
that
is
executed
by
the
control
plane
Sorry
by
the
GitHub
action
and
is
creating
all
the
infrastructure
also
is
deploying
the
tools
around
spinal
cord
that
is
required
by
the
test,
like
my
sequel.
Radius
also
is
deploying
an
ephemeral
Jenkins
that
is
going
to
be
used
as
part
of
the
testing
is
going
to
deploy,
spanner
care
and,
finally,
he's
going
to
load
all
the
end-to-end
tests
that
we
would
like
to
run
as
part
of
these
chains.
B
So
this
is
something
execution
that
you
used
to
take
a
few
minutes
to
execute.
So
I
already
have
an
environment
here.
That
is
a
an
ephemeral
environment,
and
if
we
take
a
look
at
this
application,
we
can
find
all
the
pipelines
or
the
end-to-end
tests
that
we
load
by
default
or
as
part
of
this
process.
So
basically
we
are
using
pipelines
in
a
spanner
to
choose,
verify
and
validate
all
the
functionalities
working
correctly,
and
this
FML
spanner
is
responsible
on
delivering
the
execution
status
for
each
test
in
the
pull
request.
B
We
connect
with
a
pull
request,
for
example,
this
one
that
has
all
the
executions
and
and
the
test
that
pass
or
not
in
all
this
process.
So
all
these
statuses
are
delivered
by
the
ephemeral
spanner
care.
So
in
this
way
we
can
validate
and
review
in
with
immediately
feedback
if
a
test
pass
or
no
and
what
changes
or
what
this
we
are
just
running
as
part
of
this
change.