►
From YouTube: Reducing Deployment Risks with Progressive Automated Canary and Spinnaker in a Reg... Carlos Martini
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Reducing Deployment Risks with Progressive Automated Canary and Spinnaker in a Regulated Environment - Carlos Martini, Vanguard
We've all been there: we've spend countless hours creating automated tests and manually testing new functionality to ensure our applications work well only to have production users use our system in unexpected ways and break the application. So how can we reduce risks even further when deploying to production? And how do we do this in a highly regulated environment? Progressive automated canary allows us to slowly and, more importantly, automatically ramp up production traffic to a new version. This talk will not only focus on how to setup progressive automated canary using Spinnaker, but on how to do it in a way where large and highly regulated companies can meet their regulatory requirements. We'll dive into using pipeline templates and different stage types to provide consistent deployments, meet custom regulation requirements, and integrate with change management systems.
A
All
right,
good
morning,
everyone
am
I
good
to
go
in
the
back
good,
all
right
well,
good
morning,
everyone
I'll
I'll
apologize
in
advance.
I
was
at
a
sporting
event
on
sunday
and
I
always
say
you:
can
you
know
how
good
and
exciting
the
the
game
is
by
how
bad
your
voice
is
the
next
day,
and
my
voice
is
not
doing
that
good.
A
So
lesson
learned
not
to
do
that
in
in
the
future,
but
at
any
rate,
let's,
let's
talk
how
we
can
reduce
our
deployment
risk
with
progressive,
automated
canary
in
a
regulated
environment.
My
name
is
carlos
martini,
I'm
a
senior
cloud
architect
at
vanguard.
If
you've
never
heard
of
anger,
that's
okay!
We
don't
do
a
lot
of
advertising,
but
we
are
a
multi-trillion
dollar
asset
management
firm.
So,
as
you
can
imagine
we're
very
heavily
regulated
and
at
the
same
time
we
we
take
that
responsibility
very
seriously.
A
So
there's
a
lot
of
controls
and
in
place
before
somebody
can
deploy
to
to
production.
So,
as
we
were
trying
to
implement
progressive
automated
canary
a
lot
of
the
challenges
we
ran
into
actually
had
nothing
to
do
with
progressive
automated
canary
itself.
But
just
how
do
we
implement
a
lot
of
these
controls?
So
I'm
kind
of
hoping,
in
addition
to
sharing,
how
to
set
up
progressive,
automated
canary,
to
also
share
some
of
those
lesson
learned
so
that
you
can
you're
able
to
take
that
back.
If
you
work
in
a
regulated
environment
such
as
me,.
A
All
right
so
there's
three
things
that
I'm
hoping
you
guys
will
will
get
out
of
this
presentation.
The
first
one
is:
why
would
you
even
bother
using
progressive,
automated
canary
at
all
the
second
one
I'll
show
you
guys
how
to
set
up
a
very
simple
pipeline
within
spinnaker
and
then,
finally,
again
I'll
show
you
guys
some
strategies
within
spinnaker
on
how
to
implement
some
of
those
regulatory
requirements
that
you
might
have.
A
All
right
before
we
get
started,
though
this
you
know
there
is
some
assumptions
baked
into
it
as
a
30-minute
presentation.
So
there's
only
so
much
that
we
can
cover
here
right
so
sort
of
when
you
go
on
a
ride.
You
must
be
this
tall
there's
a
few
things
that
need
to
take
place
before
you're
you're
able
to
get
started
on
on
your
journey
here
right.
So
the
first
one
is
your
applications
need
to
have
a
way
to
gather
metrics
right.
So
that's
good
practice.
A
A
The
second
one
is
you
really
need
something
set
up,
whether
it
be
a
service
mesh
or
some
other
way
to
to
orchestrate
that
splitting
of
traffic
right.
So
one
of
the
things
that
we'll
learn
here
for
a
progressive,
automated
canary
is
you
want
to
be
able
to
send,
you
know,
say
80
of
traffic
to
a
specific
version
of
your
application
20
to
another
version.
A
So
you
really
need
some
mechanism
in
enable
to
to
be
able
to
do
that
and
then
finally,
the
the
last
thing
is,
you
really
need
to
have
an
identity
provider
set
up
with
spinnaker,
so
you
really
want
to
limit
any
kind
of
access
to
spinnaker
without
knowing
who
you're,
who
that
user
is
all
right.
Let's
level
set
a
little
bit
lots
of
buzzwords
and
they're
progressive
order,
brandy
canary
what
does
that
mean?
What
is
the
difference?
I'm
sure
most
people
have
heard
of
canary
in
the
past
right.
A
So
let's
try
to
break
that
down
a
little
bit
right,
so
canary
at
his
most
basic
level.
Just
implies
from
you
know,
sending
a
canary
into
a
coal
mine
that
you're
gonna
send
some
percentage
of
your
users
to
your
new
version
to
see
whether
or
not
that
version
actually
works,
as
you
would
expect
it
to
canary
on
its
own.
A
A
A
All
right,
so
why
would
you
want
to
use
progressive
automation
canary
well
in
this
slide,
I'm
just
kind
of
showing
the
at
a
high
level,
some
of
the
other
deployment
strategies
that
are
out
there
right
so
at
the
top
we
kind
of
have
the
most
risky
at
the
bottom,
the
the
less
risky
right.
So
we'll
start
off
with
highlander
at
the
top,
which
is
sort
of
the
most
risky
deployment
strategy.
You
can
have
right.
So
the
way
that
works
is
you
just
have
your
version
one
out
there
you
deploy
your
version
two
and
right
away.
A
All
your
users
are
seeing
that
version
too
right,
so
you
can
see
the
issue
there.
I'm
sure
most
people
have
done
their
due
diligence,
tests
and
non-prod.
But
let's
say
you
have
an
environment
variable
that
gets
set
and
is
different
for
non-pro
versus
prod.
You
have
a
typo
all
of
a
sudden.
Your
application
is
not
working
in
prod
and
all
your
users
are
affected
until
you
realize
you
have
an
issue
and
either
roll
back
or
fix
the
issue
in
the
middle.
We
have
blue
green,
so
blue
green
is
better
than
the
highlander
right.
A
So
with
blue
green,
you
have
your
version.
One
out
there
you
deploy
your
version.
Two
version,
two
is
inactive,
meaning
your
users
are
still
going
to
version
one
you're
able
to
do
some
validation,
so
whether
you're
looking
at
logs
or
you
know,
you're,
hitting
your
application
and
playing
around
with
it
to
make
sure
that
it
works.
So
it
gives
you
some
level
of
confidence
right.
So
in
the
previous
example,
if
you
have
an
environment
variable
that
had
a
typo
for
production,
you
will
be
able
to
see
that
and
your
users
wouldn't
be
affected
by
it.
A
Where
blue
green
doesn't
work
as
well.
Is,
let's
say
you
know
your
application
works
fine
until
it
comes
under
load
right.
So
let's
say
your
application
works
fine
until
40
of
your
users
are
hitting
it
at
which
point
you
start
to
notice.
A
spike
in
your
latency
right,
blue
green
is
not
really
going
to
be
able
to
help
you
with
that,
because
you
won't
be
able
to
see
that
right,
you're
only
able
to
do
that,
verification
in
isolation
without
any
real
users
and
then,
finally,
at
the
bottom,
you
have
progressive
automated
canary.
A
So
the
way
that
this
will
work
is
you
have
your
version,
one
you
deploy
your
version
two,
and
only
a
small
percentage
of
your
users
are
hitting
your
version
two
at
first
right,
so
let's
say
10
of
your
users,
you
let
that
run
for
a
little
while
you're
doing
your
canary
analysis,
so
now
you're
conver,
comparing
the
metrics
for
your
version,
two
with
your
version,
one.
If
that
looks
good,
then
you're
bumping
up
traffic
to
to
your
next
bump
in
traffic.
But
if
it
doesn't
look
good,
you
can
automatically
roll
back
right.
A
So
there's
a
couple
advantages
here
right,
one
is
your
blast.
Areas
is
a
lot
smaller
with
only
10
and
then
the
other
one.
Is
you
you
kind
of
get
that
automatic
roll
back
right?
So
now,
if
you
went
out
for
coffee
and
that
took,
you
know,
10
minutes
longer
than
you
expected
by
time.
You
come
back.
It's
already
rolled
back
right
with
some
of
the
other
deployment
strategies.
A
All
right,
so,
let's
take
a
look
at
how
all
the
different
pieces
here
can
can
work
together
right.
So,
on
the
left
hand,
side
we
have,
you
know
spinnaker
cloud
driver
is
the
the
microservice
that's
going
to
do
the
deployment.
You
have
your
application
on
the
right
hand,
side
right.
You
have
some
way
to
split
the
traffic,
whether
it
be
service
mesh
or
something
else,
and
you
also
have
your
metric
store.
A
A
The
the
key
part
here
is
that
when
you
deploy
your
canary,
you
do
not
want
to
do
your
comparison
to
your
existing
version
of
production.
In
other
words,
you
want
to
do
a
fresh
deploy
of
your
version,
one
and
that
becomes
your
baseline
and
then
do
the
comparison
to
that
baseline
as
opposed
to
your
version.
One.
A
The
reason
you
wanna
do,
that
is
you,
wanna,
keep
your
canary
and
your
baseline
as
close
as
possible
in
terms
of
how
they
look
right.
So
let's
take
an
example
where
you
know
you're
doing
caching
for
your
application.
So
your
version,
one
is
out
there
for
two
weeks
by
the
time
the
canary
comes
along,
that
cache
is
already
pretty
pretty
filled
up
and
so
that
prod
version
one
is
going
to
be
able
to
respond
a
lot
faster
right.
A
So
when
you
do
your
canary
analysis,
that
canary
analysis
might
fail,
because
your
canary
has
a
higher
latency
but
in
reality
there's
nothing
really
wrong
with
it,
and
if
you
were
to
do
that
canary
analysis,
two
weeks
later,
you
will
likely
get
a
similar
result
right.
So
when
you
deploy
that
version
one
again,
neither
neither
version
has
the
application
warm,
so
you'll
get
similar
results,
which
is
exactly
what
you
would
want
there.
A
So
once
you
have
those
two
versions
out
there
they're
going
to
be
running
for
some
period
of
time,
and
then
your
users
are
going
to
come
along
here
and
they're,
going
to
get
split
up
between
the
the
different
versions.
Right
so
let's
say
you
want
a
10
of
your
traffic
to
go
to
your
canary,
which
means
10
also
should
go
to
your
baseline,
and
then
you
know
80
percent,
to
your
version.
That's
already
in
prod.
A
What's
going
to
happen,
then
at
that
point
kayenta,
which
is
the
canary
analysis,
microservice
and
spinnaker,
it's
going
to
pull
your
metrics
from
your
metric
store
and
do
the
comparison
for
your
canary
and
in
baseline
and
then
at
that
point
it's
kind
of
a
starts
to
become
a
repetitive
cycle
right.
So
at
that
point
either
the
analysis
will
pass
or
fail.
A
A
A
Then
you
also
have
your
canary
analysis
stage.
This
is
a
stage
that
will
use
the
canary
configs
to
pull
the
metrics
and
then
do
the
comparison.
So
there's
some
configuration
there
that
you
can
set
up,
for
instance,
how
long
do
you
want
to
run
your
analysis
for
right
and
the
riskier
or
the
the
more
confident
you
want
to
feel
the
longer
that
that
should
be
for
your
change
and
then,
finally,
the
one
of
the
the
key
parts
is
really
that
automatic
rollback
right.
If
something
goes
wrong.
A
All
right,
so,
let's
do
demo
here.
If
this
screen
comes
back
awesome
all
right.
Let
me
zoom
out
a
little
bit,
so
let
me
let
me
set
the
stage
a
little
bit
in
terms
of
what
I've
done
prior
to
the
presentation.
So
I
have
a
a
kubernetes
cluster.
That's
running
a
sample
application
sample
application
is
extremely
simple.
All
it
does.
It'll
return
a
200
or
a
500
hdp
status
code
based
on
a
parameter
that
I
pass
in
telling
it.
What
percentage
should
be
200
right,
so
I've
deployed
the
application.
A
I
said:
100
of
the
request
should
get
a
a
200..
So
let's
try
out
the
failure
scenario
first
right.
So
we'll
do
a
manual
start
here
and
we're
going
to
tell
it
for
this
canary
version.
Let's
only
have
a
success
rate
of
30
right.
So
that's
a
70
difference.
This
should
easily
fail
our
canary
analysis
and
then
roll
back
to
our
production
version
as
as
well
all
right.
A
So
while
that's
running
it's
going
to
take
a
second
here,
let's
start
to
look
at
what
the
pipeline
actually
looks
like
right.
So
the
stuff
in
the
front
we'll
cover
here
in
a
second,
let's
start
with
our
deploying
the
canary
and
deploying
baseline.
All
this
is
is
I'm
using
kubernetes
here
in
this
demo,
but
all
this
is
is
basically
just
a
kubernetes
deployment
manifest
right.
The
the
key
part
is
you
want
some
labels
or
the
naming
convention
to
tell
you
which
version
of
the
application.
This
is
right.
A
So,
for
example,
here
we're
saying
this
is
the
canary
and
the
reason
why
this
is
key
is
when
you
go
to
extract
your
metrics,
you
want
to
be
able
to
keep
them
separated
and
filter
them
out,
based
on
whether
it's
canary
or
baseline
baseline
looks
exactly
the
same.
Only
here
we're
telling
it
this
is
the
baseline
right.
A
The
next
stage
is
we're
just
telling
it
to
send
10
of
the
traffic
to
canary
and
baseline,
so
now
for
this
demo,
I'm
using
istio
with
the
service
mesh,
but
what
I've
seen
I've
done
this
with
with
other
products
as
well.
It
looks
pretty
much
the
same
in
that
you're
able
to
say
you
have
some
weight
and
then
that's
linked
to
some
some
version
of
your
application.
A
A
The
other
neat
thing
that
spinnaker
has
when
you're
doing
canary
analysis
is
this:
has
this
good
visual
representation
of
your
metrics
right?
So
this
is
a
simple
demo,
so
I
only
have
success
rate
as
a
metric
right,
but
you
should,
at
a
minimum
at
least
have
latency
along
with
accessory
for
your
application
right.
A
All
right,
so,
let's
try
running
the
success
scenario
now
so
we'll
also
have
100
success
rate
on
this
one
and
we'll
run
it.
This
one
will
also
take
a
little
while
to
to
go
so,
let's
start
looking
at
some
of
the
other
stuff,
we
we
didn't
look
at
before
right.
So
let's
look
at
the
canary
analysis
and
how
that's
actually
set
up
so
the
first
thing
you'll
notice
here
is
this
analysis
type
when
you're
running
this
for
real,
you
will
want
to
do
real
time.
A
A
A
So
I
ran
this
in
advance
and
then
it's
basically
looking
at
the
metrics
from
the
time
frame
where
I
ran
it,
and
this
is
just
an
ex
and
if
else
statement
just
you
know,
if
I'm
running
the
failure
scenario,
you
use
this
if
I'm
running
the
success
scenario,
use
that
time
frame,
that's
all
that
is
when
you're
running
this
for
real.
You
want
to
use
real
time
and
the
two
key
things
here
is
hey.
A
How
long
do
you
want
to
run
your
analysis
for
so
again,
if
you
want
to
feel
really
confident,
you'll
probably
run
that
for
a
longer
period
of
time,
if
it's
a
low
risk
change,
maybe
you
run
it
for
less
period
of
time.
So
this
is
a
lifetime
of
the
entire
analysis.
There's
also
this
interval
field
here.
A
So
if
you
want
to
run,
let's
say
your
final
analysis
before
you
switch
everybody
over
for
for
two
hours,
you
can
also
set
an
interval
say
of
30
minutes
and
you're
essentially
running
for
analysis
during
that
time,
right,
like
I'll,
do
it
every
every
30
minutes,
it
will
run
a
new
analysis
for
you
just
to
make
sure
that
you
got
your
your
things.
There.
A
Actually,
before
I
leave,
let's
talk
through
the
the
rest
of
the
pipeline
right
so
now
this
is
going
to
go
in
it's
going
to
pass
for
all
the
different
stages.
Right,
as
you
can
see
like
this
starts
to
become
pretty
repetitive
after
the
the
first
time
right.
So
again,
this
is
a
demo.
Another
great
strategy
here
might
be
that
you
might
want
to
have
a
rollback
pipeline
that
you
invoke
from
this
right
as
opposed
to
having
all
this
duplication.
A
The
other
thing
that
I'll
show
you
guys
here
is
towards
the
end
right
before
we
switch
all
the
traffic
over.
I've
also
set
up
this
manual
judgment
stage.
So
again
you
don't
need
to
have
this,
but
if
you
know,
if
your
requirements
say
there
needs
to
be
some
kind
of
manual
intervention
or
somebody
needs
to
approve
it
before
you
can
flip
everybody
over.
A
There
is
start
to
change
your
labels
on
your
canary
deployment
right
at
that
point,
your
canary
becomes
your
new
prod,
and
so
you
want
to
make
sure
that's
being
labeled
correctly,
and
then
you
also
want
to
send
100
of
the
traffic
now
to
your
new
prod
right
and
you
want
to
delete
your
old
canary
and
your
your
old
baseline.
You
want
to
do
some
some
cleanup
there
as
well
all
right,
so
let's
go
back
to
our
pipeline,
which
should
be
stopped,
and
it
is
here
at
this
manual
stage.
A
So
this
again,
this
comes
in
pretty
handy.
If
you
need
to
do
that,
so
we're
going
to
tell
it
to
to
continue
here
and
it
will
go
ahead
and
flip
the
canary
to
the
new
version
all
right.
So
I
think
at
this
point
this
is
kind
of
where
we
were
starting
to
feel
really
good
about
our
canary
pipeline.
We
were
excited,
it
worked
pretty
well,
but
I
think
you
know
we
kind
of
have
that
new
sports
car
feel
like
we
just
felt
like
we're
going
a
million
miles
an
hour.
A
It
was
cool,
but
then
we
kind
of
put
on
the
brakes
right,
we're
in
a
regulated
environment.
We
started
noticing
some
things
right,
so
the
first
thing
was
as
we're
creating
these
pipelines.
Anybody
can
really
do
anything
and
edit
those
pipelines
at
will
right.
So
we
needed
to
have
some
stages
that
needed
to
run
for
compliance
reasons.
A
A
So
you
know
those
type
of
things
can't
be
removed
from
the
pipeline.
The
other
one
that
we
had
was
any
team
can
really
edit
and
deploy
other
teams
codes
right.
That
was
another
big
no-no.
Right
like
we
wanted
to
ensure
that
only
teams
that
owned
the
code
were
able
to
deploy
to
production
and
then
finally,
the
last
thing
we
kind
of
ran
into
is
we
kind
of
had
these
complex
and
custom
requirements
that
we
needed
to
meet
that
were
a
little
bit
difficult
to
implement,
with
some
of
the
stages
that
that
spinnaker
provided.
A
But
if
you're
in
a
regular
environment,
that's
kind
of
risky
right,
like
you,
probably
want
something
where
you're
kind
of
building
that
race
car
for
the
teams
and
they
might
be
able
to
customize
certain
things
on
it,
but
at
a
minimum
you
probably
want
like
at
least
an
engine
or
something
in
there
that
teams
aren't
able
to
to
modify
right.
It
kind
of
has
your
regulatory
requirements
in
there.
A
You
also
probably
want
to
restrict
teams
from
removing
stages
in
that
pipeline,
and
you
want
to
control
who
can
read
and
execute
those
those
pipelines
and
then.
Finally,
as
I
mentioned,
you
might
want
to
have
an
easy
way
to
execute
some
of
those
requirements
that
don't
fit
very
well
within
the
existing
stage
types.
A
The
next
one
is
pipeline
templates,
so
those
are
great
for
ensuring
that
stages
are
always
being
executed
and
that
teams
can't
remove
certain
stages
that
that
are
key
and
then
finally,
we'll
talk
about
the
authorization
to
your
apps
and
pipelines
to
kind
of
limit
what
teams
are
are
able
to
do
for
different
applications
all
right.
So
let
me
go
back
here
and.
A
So
as
you're
running
that
image,
you're
able
to
provide
any
inputs
that
you
might
need
in
order
to
run
your
logic,
but
it
it's
pretty
straightforward
from
a
spinnaker
side
right.
So
this
kind
of
allows
you
to
have
that
complexity.
Now
in
code
it
can
be
unit
tested
whatever
you
need
to
do,
and
really
the
the
sky
is
the
limit.
At
that
point.
The
really
neat
thing
about
this
stage,
though,
is
from
spinnaker
perspective.
A
Is
spinnaker
kind
of
gives
you
a
you
know
a
first
class
setup
for
handling
those
those
outputs
right,
so
once
you
run
that
that
job
stage
you
you're
actually
able
to
output
certain
variables
that
you
might
need
to
use
throughout
your
pipeline
right.
So
let's
use
the
the
change
record
example
where
you're
creating
a
change
record
when
the
pipeline
starts.
You
might
want
to
close
that
change
record
if
everything
goes
well
towards
the
end.
So
it's
not
open.
This
gives
you
a
great
way
to
do
that
right.
A
So
what
you
see
here,
the
first
line
is
just
a
just
a
regular
log
right,
but
then
spinnaker
will
look
through
the
rest
of
it
and
it
will
look
for
the
spinnaker
property
throughout
your
logs
right
and
what
it
will
do
is
anything
after
the
underscore.
So
in
this
example,
change
number
is
what
I
named
it.
It
will
turn
that
into
a
spinnaker
variable
that
you
can
just
use
right
away
within
your
pipeline,
so
that's
kind
of
like
a
property
one
by
one.
A
Another
option
is,
if
you
have
multiple-
and
you
don't
want
to,
you
know
essentially
have
a
whole
bunch
of
spinnaker
properties.
Here
is
you
can
also
configure
this
spinnaker
config
json?
The
effect
is
the
same,
just
two
ways
to
do
different
things
and
basically
again.
Anything
here
is
a
key
value
pair
and
it
will
turn
these
into
variables
right.
So
then
you'll
be
able
to
access.
You
know
a
time
created
later
on
in
your
pipeline
as
an
example.
A
So
that's
really
useful
for
handling
outputs.
From
from
that,
the
next
thing
I'll
show
you
guys
is
the
the
pipeline
templates.
So
pipeline
templates
are
actually
let
me
go
back
here.
Real
quick
are
very
simple
right,
so,
if
you
don't
know
spinnaker,
all
these
pipelines
are
essentially
just
json
under
the
covers
right.
A
So
the
way
pipeline
templates
work
is,
you
can
actually
just
build
out
the
pipeline
kind
of
on
the
on
the
ui
here
and
then
you're
able
to
copy
and
paste
this
json
into
a
pipeline
template
json,
which
looks
almost
identical
to
this.
It
has
a
few
extra
fields,
but
then
it
also
has
a
pipeline
field
and
that's
basically
a
one-to-one
mapping
to
to
this
json
here.
A
A
And
because
users
are
not
able
to
edit
anything
in
that
pipeline,
so
one
of
the
features
that
spinnaker
provides
is
parameters
for
that
pipeline
right.
So,
even
though
you
might
not
want
to
let
them
have
free
range
to
edit
or
delete
anything
in
that
pipeline,
you
might
want
to
let
them
customize
certain
things
right.
So
if
you
want
to
control
how
a
deployment
happens,
for
example
at
a
high
level,
but
you
still
want
to
allow
say
you
know
how
many
replicas
of
your
application
are
running.
A
A
And
the
first
thing
you'll
see
is
manual:
edits
are
not
allowed,
so
let's
say
you
know,
I
don't
want
to
deal
with
change
record
right
and
I
try
to
remove
it.
It
looks
like
it
works.
The
spinner
could
have
better
support
for
this.
For
sure,
like,
I
would
expect
to
see
an
error
there,
so
it
looks
like
it
works,
but
in
reality
it
doesn't
right.
So
if
I
leave
the
pipeline
and
then
come
back
to
it,
the
stage
is
still
there.
So
you
can't
actually
delete
or
modify
anything
in
here
all
right.
A
The
last
thing
I'll
show
you
guys
here
as
we're
running
out
of
time,
is
just
set
up
authorizations
and
there's
only
two
ways
to
do
that
right.
So
in
here
I've
set
up
some
an
application
where
we
have
a
couple
teams:
the
first
one
only
team
one
can
read
edit
or
execute
and
then
the
other
one
other
teams
are
able
to
read
it,
but
only
team
one
is
able
to
actually
execute
or
edit
right.
A
So
the
first
way
is
probably
the
simplest,
where
you're
able
to
go
into
the
application
go
to
config
and
then
under
application
attributes.
You'll
see
this
permission
field
and
then
here
as
you're
hooked
into
our
your
identity
provider,
it
will
bring
back
the
different
groups
that
that
user
is
a
part
of
so
here,
for
example,
we're
saying
the
role
of
team,
one
will
have
read,
execute
and
write,
and
everyone
else
can
can
do
read.
A
The
other
options
spinnaker
provides
it's
a
little
bit
more
enterprise
ready.
I
think
in
that
you're
able
to
within
your
configuration
for
fiat,
local,
you
are
able
to
to
set
it
up
for
a
a
regular
expression.
So
what
this
is
saying
is
you
know
prefix,
so
it's
going
to
look
at
the
the
application
name.
You
can
set
this
up
to
whatever
you
want.
It's
a
regular
expression
right.
So
in
here
I
said
if
it
starts
with
team
one
and
then
just
start
so
team,
one
application,
one
team,
one
application,
two
etc.
A
We're
gonna
set
up
these
defaults
right.
So
by
default
we're
gonna
say
nobody
will
have
access
to
team
teams,
ones
applications
by
default.
So
if
team
one
creates
an
application
two
weeks
from
now-
and
you
know
as
long
as
we're
following
that
naming
convention
of
team
one-
it
will
inherit
these
these
permissions.
So
you
can
also
add,
as
you
can
see,
there's
a
list,
so
you
can
have
multiple
applications
and
you
can
set
this
up.
A
However,
you
need
to
and
if
you
need
to
override
it
for
a
certain
application,
you
can
do
that
either
here
or
if
it's
just
like
a
one-off.
The
previous
way
that
I,
that
I
showed
you
guys
all
right,
so
I
think
I
want
you
guys
to
take
three
things
away.
Why
use
progress
for
the
american
airy
again?
It
reduces
the
risk
of
downtime
for
your
clients.
It
reduces
the
blast
area.
A
How
do
you
set
up
progressive
automation
area?
Show
you
guys
a
sample
pipeline,
but
I
think
the
key
points
here
are:
don't
compare
your
canary
to
what's
already
out
there
deploy
a
baseline
and
compare
it
to
that
again.
You
want
to
make
sure
you're
using
the
right
metrics
for
your
applications,
but
at
a
minimum
you
want
to
set
up.
A
Some
kind
of
you
know,
error,
success
rate
and
latency
and
then,
finally,
how
to
meet
your
regulatory
requirements,
try
to
give
you
guys
three
strategies
there
pipeline
templates
job
stage
and
how
to
set
up
a
authentic
authorization
for
your
apps
all
right
we're
at
time.
I
am
happy
to
stick
around
and
answer
questions.
I
will
also
be
around
for
the
remainder
of
the
afternoon
and
early
tomorrow
morning.