►
Description
Spinnaker as Code SIG - Rob Fletcher & Luis Pollo, Netflix
The Spinnaker-as-Code SIG is focused on enabling usage of Spinnaker via declarative formats that can be stored as source code, such as manifests or templates. We're primarily focused on Managed Delivery at the moment.
Everyone is welcome to join, ask questions, and share ideas.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
So,
if
you're
unfamiliar
with
what
managed
delivery
is,
we
won't
really
be
covering
a
whole
overview
of
it,
but
we've
done
that
in
previous
spinnaker
summit
events.
So
I
encourage
you
to
go
check
out
those
materials
all
right,
so
let's
get
right
to
it.
So
what
were
our
highlights
for
2021,
the
first
half
of
the
year?
I've
we've
divided
this
slide
into
the
stuff
that
we've
done
at
netflix
and
then
some
of
the
work
that
aws
folks
have
done
because
we've
been
the
primary
contributors
to
managed
delivery
over
the
last
several
months.
A
But
as
we
are
hoping
for
at
the
end
of
the
session,
we
are
definitely
always
looking
for
others
to
be
engaged
and
contribute
to
to
evolving
it.
So
the
first
thing
we've
improved
in
the
these
last
two
quarters
were:
was
our
slack
notification
story.
So
now
you
get
really
nice
lack
notifications
pretty
much
all
across
your
delivery
flow
and
we're
going
to
take
a
look
at
that
during
the
demo
as
well.
A
We
added
support
for
finding
artifacts
based
on
the
source
control
metadata
instead
of
having
users
worry
about
versions
which
can
be
very
messy
and
hard
for
users.
To
reason
about.
This
has
been
really
a
nice
enabler
here
in
netflix
we
added
first
class
support
for
verifications,
which
is
the
term
we
use
to
describe
these
post
deployment
integration
or
smoke
tests
that
you
run
against
your
live
environments.
Using
task
containers,
we've
enabled
all
new
java
and
node
apps
and
netflix
to
be
onboarded
to
manage
delivery
by
default.
A
They
still
have
a
choice
to
go
use
pipelines
if
they
want
to
and
if
you're
familiar
with
spinnaker,
which
I'm
guessing
you
are
since
you're.
Here,
the
classic
delivery
workflows
was
using
pipelines
and
managed.
Delivery
in
a
nutshell,
is
just
a
a
way
to
rethink
how
you
do
delivery
using
a
declarative
approach,
and
so
all
new
apps
now
netflix
for
both
those
app
types
are
being
onboarded
by
default
onto
manage
delivery.
A
We've
also
rolled
out
an
entirely
new
ui,
so
for
those
of
you
who
might
have
seen
our
presentations
in
previous
events,
you'll
notice,
when
I
do
our
little
demo
today,
that
the
ui
looks
much
cleaner
and
we've
refactored
it
quite
a
bit
based
on
feedback
that
we
got
from
our
internal
users
and
then
last
but
not
least,
I
just
wanted
to
point
out
that
we've
been
seeing
huge
adoption
increase
here
at
netflix
with
managed
delivery.
So
in
the
last
quarter
we've
actually
doubled
the
number
of
apps
on
boarding,
and
we're
really
excited
about
that.
A
A
They
added
support
for
for
kubernetes
resources
on
the
ui,
and
I
should
prefix
this
by
saying
that
aws
has
been
primarily
contributing
to
a
plug-in
for
managed
delivery
that
enables
kubernetes
resources
to
be
managed
via
this
new
paradigm
and
they've
done
a
whole
lot
of
work
to
make
that
work
and
and
turn
out
into
a
really
nice
experience
for
users.
So
ui
support
was
was
a
big
deal
to
to
enable
the
next
thing
they
did
was
to
add
validation
of
the
kubernetes
resource
progression
between
the
environments
in
the
ui.
A
They
also
started
doing
some
work
on
templating
tools
and
working
with
other
partners
in
the
community
to
think
about
next
steps
within
the
kubernetes
plugins
in
order
to
kind
of
raise
the
level
of
abstraction
and
allow
users
to
not
have
to
worry
too
much
about
the
details
of
the
kubernetes
resources
that
are
under
the
hood
and
kind
of
related
to
this.
They
did
do
some
work
already
with
helm
and
customize.
I
believe
we
have
demos
of
some
of
these
things
in
our
sig
meeting.
A
Videos
which
you're
always
welcome
to
check
out
there
is
a
link
to
where
you
can
find
all
that
material
at
the
end
of
this
presentation
as
well.
Alright,
so
let
me
go
over
this
little
video
here.
That
shows
you
what
we've
been
up
to
in
the
last
half
of
the
year,
so
we
start
with
a
simple
app
in
git
and
it
has
this
delivery
config
file,
which
is
the
manifest
that
describes
your
resources
and
your
delivery,
workflows
and
netflix.
We
use
bitbucket.
A
So
this
is
what
you're,
seeing
here
and
by
convention
we
store
these
files
under
the
dot
netflix
directory
in
a
file
called
spinaker.yaml.
So
this
is
what
I'm
clicking
here
and
you
can
see
here.
I
just
highlighted
that
netflix,
where,
like
I
mentioned
before,
we
are
auto
generating
these
files
doing
project
scaffolding
for
java,
apps
and
node
apps
such
that
users.
Don't
have
to
write
all
of
this
yaml
by
hand
which
is
an
enabler
for
them
to
get
started.
A
So
I'm
not
going
to
go
into
a
whole
lot
of
detail
about
this
format,
because
we've
done
that
in
previous
events,
as
I
mentioned,
but
you
can
see
here
that
there
is
a
test
environment
defined
and
it's
got
a
few
resources.
Titus
clusters
cluster,
which
is
a
docker
cluster
and
then
a
security
group.
Then
we
also
have
a
prod
environment
that
has
the
same
resources
and
the
difference
between
test
and
prod.
Is
that
broad?
A
Has
these
constraints
and
constraints
are
just
gates
that
allow
you
to
control
how
and
when
your
artifacts
are
going
to
be
promoted
into
that
environment,
so
for
prod?
You
can
see
that
it
has.
This
depends
on
constraint,
meaning
that
it
will
only
an
artifact
will
only
deploy
into
prod
once
it's
been
successfully
deployed
to
test,
and
then
it
also
has
this
manual
judgment
constraint,
which
I'll
show
you
in
a
bit
here
and
what
that
means
is
that
essentially,
a
human
being
needs
to
push
a
button
to
approve
the
deployment
into
that
environment.
B
A
I
was
saying
it
has
both
the
same
types
of
resources
that
are
in
test,
which
is
pretty
common
as
well
all
right.
So,
let's
see
what
this
looks
like
in
spinnaker.
First
thing
I
wanted
to
show
you
in
this
new
ui
is
what
we
call
the
environments
overview
page,
and
this
is
where
you
can
see
your
app
at
a
glance
and
anything
and
everything
that
should
be
important
for
you
to
note
at
any
given
point
in
time.
A
So
it's
as
you
can
see
here,
it's
divided
in
the
environments
that
you
have
so
we
have
a
test
and
a
broad
environment
and
within
each
you
have
the
artifacts
and
the
resources,
meaning
infrastructure
resources.
Artifacts
to
be
honest,
is
more
like
deployments
if
you're
familiar
with
that
terminology
from
like,
say
kubernetes
so
essentially,
you'll
see
like
what
versions
of
your
artifacts
are
deployed
in
each
of
these
environments.
A
Resources
like
we
were
just
looking
at
the
config
file,
you
have
a
security
group
and
a
cluster
there,
so
they
show
up
on
the
ui.
The
other
thing
you
can
do
from
this
view
is
to
see
the
history
of
your
resources,
so
there's
a
little
view.
History
link
on
there
next
to
every
resource
and
when
you
click
that
this
modal
pops
up,
where
you
can
see
the
whole
history
of
your
resource.
A
So
in
this
case
that
the
history
is
relatively
short
and
it's
got
like
a
lot
of
green
events,
which
is
what
we
want
to
see
generally.
But
basically
this
allows
you
to
see
what
happened
to
the
resource
over
time
and
for
those
that
have
the
little
expansion
icon
here.
You
can
also
expand
and
see
more
details
if
you
want
to.
A
Same
thing
for
the
cluster
resource
here,
and
in
this
case
you
can
see
there
was
a
warning
event
in
the
middle
there,
because
I
messed
up
my
config,
so
eventually
things
resolved
and
but
anyway,
that's
how
you
can
see
what
happened
to
that
resource
over
time.
Next,
I
wanted
to
show
you
the
artifact
version
history
page-
and
this
is
where
you
see
your
code
and
deploys
through
time.
Essentially
it's
a
timeline
of
of
your
delivery
flows.
A
So
let's
take
a
look
at
that.
It's
that
second
tab
on
the
ui.
So
when
you
click
that
you
can
see
all
of
the
versions
that
we
know
about
in
spinnaker
and
they're
represented
in
terms
of
the
commits
from
source
control,
so
that
allows
you,
like,
I
was
saying
earlier
as
a
developer
or
a
user
to
immediately
correlate
the
code
that
you're
working
on
for
your
app
with
what
you
see
here
in
terms
of
artifacts
and
deployments.
A
Each
of
the
bubbles
for
the
environments
are
color-coded,
it's
color-coded,
so
gray
is
for
previously
deployed,
meaning
it's
it
was
deployed
at
some
point.
It
was
replaced.
White
is
for
skipped
again
previously
deployed
green
is
for
currently
deployed.
So
in
this
case,
you
can
see
that
this
second
version
on
the
list
here
is
the
one
currently
deployed
to
prod
and
then
the
very
top
version
is
currently
deployed
to
test,
and
that
version
is
spending
for
prod
right
now.
A
A
I
just
went
back
to
the
overview
to
show
you
that
you
can
do
that
same
thing
over
on
the
overview
page
and,
like
I
said,
since
this
page
calls
you
your
attention
to
what
needs
to
be
done
at
any
given
point
in
time.
This
is
generally
when,
where
you'll
do
take
action
on
these,
so
I'm
going
to
approve
this
deployment
here
and
so
now,
both
of
the
constraints
are
approved.
B
A
So
eventually,
things
should
be
deployed
there,
while
that
deployment
is
going,
I'm
just
going
to
go
over
the
some
stuff
on
the
ui,
so
you
can
also
see
environments
side
by
side
in
addition
to
one
on
top
of
the
other.
This
applies
on
both
the
overview
page
and
the
history
page.
So
I
think
our
users
have
found
this
nice
because
it's
easier
to
see
what's
common
and
what's
different
between
the
environments,
especially
if
you
don't
have
like
a
ton
of
them
here,
the
deployment
started.
A
So
while
that's
going
we're
going
to
take
a
look
at
some
other
stuff
as
well,
I
wanted
to
show
you
how
the
system
is
integrated
with
the
build
and
source
control
system.
So,
like
I
mentioned
earlier,
every
version
that
we
display
on
the
ui
is
actually
tied
to
a
commit,
and
so,
as
you
would
expect,
these
links
take
you
to
that
commit
in
the
source
control
system.
A
So
here,
if
I
click
that
link,
it's
going
to
take
us
to
bitbucket
again,
which
is
the
system
we
use
at
netflix,
and
you
can
see
exactly
what's
changed
in
that
version
right.
So
this
is
a
huge,
huge
win
for
our
developers
where,
before
this
with
pipelines,
they
used
to
have
to
hop
from
the
pipeline
open
the
stages
find
which
image
was
deployed
and
go
find
what
builds
correlated
with
that
image
and
then
from
there
find
the
source
commit.
So
here
you
can
see
it's
just
a
click
away.
A
This
is.
This
is
also
some
of
the
stuff
that
aws
contributed
to
making
open
source
recently
so
they've
rolled
out
support
for
jenkins
and
github.
If
I'm
not
mistaken,
you
can
always
click
and
go
see
stuff
in
jenkins
if
you
want
to,
or
whatever
your
ci
system
is
but,
like
I
said,
the
nice
thing
about
this
is
that
you
don't
really
have
to
next
is
branches.
So
here
you
can
see
basically
the
branches
that
we
are
aware
of
at
this
time.
A
A
Next,
just
really
quickly
wanted
to
show
you
that
while
managed
delivery,
kind
of
abstracts
away
a
lot
of
the
details
of
provisioning
infrastructure
and
all
that
you
can
still
drill
down
into
the
details.
If
you
really
want
to
so
remember,
I
showed
you
that
history
view
right.
So
whenever
something
is
going
on
with
the
resource
like
in
this
case,
you
can
see
it's
saying
the
resource
is
being
updated.
If
you
click
that
view
history
link,
you
can
see
that
it
that
message
about
the
update
has
a
link
to
the
task
as
well.
A
View
for
that
specific
task-
and
here
you
can
see
everything
right-
you
can
see
all
the
steps
of
provisioning
the
server
group.
In
this
case
you
can
click
to
go,
see
the
server
group
and
on
this
ui,
which
is
kind
of
like
let's
say
the
classic,
spinnaker
ui
you,
you
see
your
resources
like
clusters,
slow
balancers
security
groups,
etc.
A
You
can
see
that
we
have
a
little
bit
of
integration
with
managed
delivery
as
well
in
these
little
light
blue
icons
next
to
the
that
show
up
next
to
the
resource
names.
So
from
these
you
can
access
similar
functionality.
As
I
was
showing
you
in
the
environments
view
like
the
history,
the
icons
also
have
meaning.
So,
for
example,
in
this
case
there
was
a
little
gear
icon
there,
because
the
resource
was
still
being.
B
A
A
A
All
right
so
here
you
can
see
now
that
we've
got
both
of
those
versions
deployed
right
great,
our
artifact
is
deployed
to
both
tests
and
prod,
but
what
if
things
will
go
wrong?
So,
let's
just
go
over
a
few
of
the
features
that
we've
developed
that
help
you
in
those
cases
as
well.
So
just
for
the
sake
of
the
example,
let's
pretend
that
I'm
adding
a
cool
feature
to
my
app
and
that
I'm
really
eager
to
roll
it
out.
A
So
you
know
it's
here,
it's
rolled
out
to
test
and
then
I
get
trigger
happy.
I
don't
really
test
it
well
enough
and
I
go
and
click
on
that
approve
button
there
to
to
approve
the
version
to
go
to
prod,
even
though
I
haven't
really
done
a
whole
bunch
of
testing.
So
let's
see
what
happens
there
cool
so
I
approved.
A
Eventually,
you
will
deploy
to
prod
and
we'll
get
back
to
that
situation
where
both
of
the
versions-
sorry,
that
same
version
is
running
on
both
test
and
prod,
as
you
can
see
here
and
they're,
both
going
to
be
green
on
the
ui
as
well,
but
there
is
a
bug
on
the
feature
right
so
then
what
do
we
do?
The
first
thing
I'm
going
to
show
you
is
this
feature
called
pinning,
which
is
what
you
use
to
roll
back
in
manage
delivery.
A
Also,
I
should
have
said
earlier
when
I
was
talking
about
this
integration
with
source
control.
You
can
see
here
on
this
menu
that
there
are
also
two
links
called
compared
to
current
version
and
compared
to
previous
version.
What
this
comparison
is
about
is
not
like
artifact
versions
but
really
the
source
code
that
changed
between
those
versions.
So
this
is
a
huge,
huge,
valuable
feature
that
our
users
really
love
and
it
allows
you
to
see
exactly
what
changed
between
one
version
and
the
next
or
one
version
and
the
previous
one.
A
So
what
happens
here
is
you're
gonna
say
I
want
this
version
to
be
this
previous
version
to
be
pinned
to
the
prod
environment.
Let's
see
but
then
eventually
you're
going
to
want
to
unpin
that
version
right
to
keep
rolling
forward,
and
so,
if
you
do
that,
and
this
version
is
still
around
and
it
happens
to
be
the
latest
one
that's
approved,
we
are
still
going
to
pick
this
up
and
redeploy
it
right.
And
you
don't
want
that
to
happen,
because
you
know
that
this
version
has
a
bug.
A
A
Same
similar
model
here,
so
you
can
type
a
message,
a
reason
that
will
display
on
the
ui.
You
can
use
emojis,
I'm
going
to
mark
as
bad.
So
now
that
version
will
never
ever
get
deployed
into
prod
again
and
it
shows
on
the
history
page
as
well
here.
So
you
can
see
that
particular
version
is
marked
as
bad
and
eventually
the
previous
one
deployed.
A
A
So
that's
gonna
deploy
to
test
as
usual
and
this
time
around
we're
gonna
make
sure
that
we
test
it
really
well
and
eventually,
when,
when
things
are,
are
good,
we're
gonna
want
to
deploy
that
fix
right.
So
here
let's
say:
we've
tested
the
fix
and
in
this
environment,
and
now
we
want
to
approve
right.
So
we
approve
it
and
what
happens
next?
A
Will
it
deploy
to
broad
or
no
what
happens
so,
as
I
was
saying
earlier,
it
will
not
deploy
to
prod
at
this
point,
because
you
still
have
a
pinned
version
in
prod
and
that's
the
previous
version.
That's
shown
in
yellow
there.
So
until
you
unpin,
like
I
said,
the
point
of
pinning
as
the
name
implies,
is
that
it
will
stick
there
until
you
unpin.
So
in
order
to
allow
the
new
version
to
roll
out,
we
just
unpin.
B
A
And
that
should
allow
the
that
newest
version
to
deploy
all
right.
While
that's
going,
I
wanted
to
show
you
notifications
really
quickly.
I
know
I'm
spending
a
whole
lot
of
time
here,
but
let
me
try
to
go
a
little
faster,
so
notifications
are
also
control
view
via
that
config
file.
For
the
vast
majority
of
use
cases,
our
users
are
using
slack.
We
also
support
email,
but
the
really
nice
notifications
are
via
slack.
So
this
is
what
I
wanted
to
show
you.
A
A
You
can
see
that
there's
that
new
version
there
got
picked
up
as
well.
It
was
deployed
to
test,
and
it's
currently
pending
in
prod.
So
let's
go
take
a
look
at
what
the
notifications
look
like.
So
here
you
can
see
the
notifications,
the
first
one
is
about
a
deployment
and
the
second
one
is
what
we
call
this
manual
judgment
constraint
right,
which
is
the
one
that
requires
approval.
You
can
always
click
on
the
links,
they're
fully
integrated
the
ui
and
slack
to
go
back
and
forth.
A
A
B
You,
okay
yeah,
so
so
verifications
as
louis
said,
was
just
kind
of
missed
out
of
that
video.
What
verifications
gives
you
is
basically
the
ability
to
run
a
container
typically
containing
like
smoke
tests
or
integration
tests
against
the
cluster
we
just
deployed
in
an
environment.
So
a
lot
lots
of
teams
at
netflix
use
this
in
in
like
a
test
or
staging
environment
before
they
go
to
a
production
environment,
but
there's
also
nothing
to
prevent
you
using
this
directly
in
your
production
environment,
because
we
dog
food
managed
delivery
on
the
project
itself.
You
know
we.
B
So
what
you'll
see
in
the
artifacts,
the
artifact
section
of
the
environment
view
here
for
a
given
environment,
is
that
you
know.
In
this
case
we
are
running
a
verification.
That's
just
been
launched.
It
shows
you
the
details
of
the
container
it's
running
and
where
it's
running,
how
long
it's
been
running
for
you
but
I'll
link
to
view
the
logs
of
whatever
tests
are
going
on
there.
B
An
improvement
we're
going
to
make
it
at
some
point
is
to
like
integrate
test
reporting
somewhat
better,
but
right
now
you
can
kind
of
jump
to
the
logs
and
you
can
also
you're
also
able
on
the
platform
we
use
to
download
the
test
reports.
If
you
do
get
failures,
so
you
can
see
exactly
what's
what's
gone
wrong
if
you
jump
onto
the
next
slide,
louise
sure
a
verification
halts
deployment
to
any
environments
that
are
depending
on
the
one
that
is
being
verified.
B
So
you
know,
for
example,
in
this
case
we
have
our
staging
environment,
that's
depending
on
our
test
environment,
and
things
won't
start
deploying
there
until
that
verification
is
complete
and
let's
go
to
the
next
one
once
complete,
you
can.
We've
got
some
ui
notifications
there
it's
worth
pointing
out
as
well
that
the
verifications
are
also
integrated
with
slack
notifications.
So
you
do
get
a
nice
notification
of
success
or
failure
posted
in
slack
as
well
of
your
verifications
and
then,
as
soon
as
verify
verifications
are
complete.
B
It's
maybe
more
of
an
issue
for
for
managed
delivery
itself
than
it
would
be
for
some
systems,
but
we
want
to
automate
the
clean
or
declaratively.
Allow
specification
of
cleanup
steps.
That's
not
there!
Yet
it's
pretty
simple
at
the
moment
in
terms
of
what
our
plans
are
for
the
second
half
of
this
year.
B
Let's
take
a
look
through
this
list
here
we
have
one
thing:
that's
pretty
exciting
is
first
class
git
integration.
So
right
now
we
have
people
use
a
a
traditional
spinnaker
pipeline,
there's
a
specific
stage
type
for
importing
delivery.
Config
you're
not
going
to
have
to
do
that
anymore,
we'll
be
able
you'll
be
able
to
just
point
manage
delivery
directly
at
your
get
re
repository,
coordinates
and
we'll
pick
up
changes
directly
from
there
without
using
the
pipeline.
B
B
In
order
to
do
some
testing
you
you'll
be
able
to
do
that
and
manage
delivery
will
handle
cleaning
up
that
in
that
ephemeral,
environment
after
you're
done
with
it.
This
is
something
that
a
lot
of
people
within
netflix
a
lot
of
teams
with
the
netflix,
are
super
interested
in
having
because
they
do
this
extensively,
especially
where
they're,
whether
bringing
up
you
know
entire
segmented
infrastructure
for
different
applications.
B
Then
we
have
environment
versions
which
is
kind
of
what
I'm
I've
been
busy
with
recently.
What
this
is
planning
to
do
is
kind
of
integrate
the
changes
to
your
delivery
config
and
the
changes
to
your
artifacts
into
one
stream
of
of
events,
so
that
you'll
be
able
to
promote
changes
to
infrastructure
in
the
same
way
that
you
promote
changes
to
the
actual
deployed
artifact
on
that
infrastructure
and
apply
things
like
constraints
and
verifications
to
rolling
out
infrastructure
changes
into
into
environments.
B
Deployment
dependencies-
this
is
something
we
don't
support
right
now
is
if
you
have
kind
of
multiple
deployment
targets
that
are
to
some
extent
dependent
on
one
another,
and
you
want
to
pin
or
roll
them
back
in
conjunction
with
one
another.
For
example,
one
thing
that
we
see
a
lot
of
times
is
that
you
know
you'll
have
your
your
server
application
and
then
you'll
want
to
deploy
out
a
graphql
schema,
that's
dependent
on
it,
and
if
one
of
those
fails,
the
other
one
really
needs
to
get
rolled
back.
B
B
One
and
abstracting
away
security
groups
and
other
low-level
infrastructure
details
like
load
balancers
is
something
that
seems
very
desirable,
because
people
don't
really
like
to
deal
with
the
details
of
security
groups
on
ec2
they're,
pretty
complicated
and
a
lot
of
you
know
a
lot
of
typical
application
developers
aren't
too
concerned
with
with
the
fine-grained
details
of
those
things.
So
netflix
in
conjunct,
you
know
the
conjunction
of
the
managed
delivery
team
and
our
security
team
and
netflix
is
trying
to
come
up
with
a
way
that
we
can
declaratively
say.
B
Oh,
I
need
to
expose
my
application
to
this
other
application,
or
I
need
to
accept
traffic
from
this
other
application.
That
kind
of
thing,
rather
than
having
to
specify
in
ingress
rules
and
torts,
and
all
that
all
those
kind
of
fine-grained
details,
that's
going
to
be
pretty
big
if
we
can,
if
we
can
get
that
right
and
last
but
not
least,
figuring
out
temp
how
we're
going
to
handle
templating.
So
I
mentioned
earlier
this
idea
of
rolling
out
infrastructure
changes
and
testing
them
in
the
same
way
that
we
test
changes
to
the
software.
B
That's
being
deployed
itself,
I
think
that
has
maybe
somewhat
limited
utility
until
we
really
have
an
enforced
concept
of
homogeneous
environments.
So,
right
now
the
expectation
is
that
your,
for
example,
your
test,
staging
and
production
environments
look
pretty
much
the
same
and
you
consist
of
the
same
types
of
resources,
but
there's
nothing
actually
enforcing
that.
So
if
you
make
a
change
to
your
production
environment
only
is
there
really
much
point
testing
it
in
the
preceding
environments
if
it's
only
actually
actually
going
to
affect
the
production
environment.
B
So
we
we
need
to
grasp
the
nettle
here
and
come
up
with
a
way
of
templating
things
you
can
already
use,
and
we
do
internally
use
yaml
anchors
and
aliases
to
to
do
this
to
some
extent,
but
that
only
gives
you
fairly
crude
control
over
entire
blocks
of
code
that
you
can
block
some
of
the
ammo
code
that
you
can
kind
of
reuse
in
other
areas
of
the
file
it
doesn't.
It
doesn't
give
you
the
the
kind
of
control
that
the
customize
gives
you,
for
example.
B
So
that's
something
we're
going
to
be
just
exploring
what
we
want
our
approach
to
look
like
in
terms
of
aws
and
their
contributions,
we're
looking
at
helm,
charts
and
using
git
repositories
as
managed
delivery,
artifacts
supporting
using
those
verifications
that
I've
just
showed
you
with
kubernetes
jobs,
the
internally
in
netflix.
We
use
our
own
container
cloud
called
titus
and
we're
running
our
verification
jobs
on
that.
B
So
this
will
be
bringing
equal
support
to
regular
kubernetes
deployments,
layering
and
templating
strategies
so
again,
tiring
and
tying
into
the
last
point
I
was
making
on
the
netflix
side
there
and
resource
management
strategies
which
actually
luis.
You
may
want
to
explain
to
me
what
that
is,
because
I'm
not
sure.
A
You
know
I
I
also
I'm
not
100
sure
what
nema
meant
by
that
I
wanted
to.
By
the
way
I
wanted
to
give
a
shout
out
to
neiman
caviani
again
and
manabu
mccloskey
from
aws,
who
have
been
doing
a
lot
of
work
to
both
bring
manage
the
delivery
into
open
source,
make
sure
that
you
can
install
the
service
backing
manage
delivery
with
the
rest
of
spinnaker,
with
an
open
source
install
and
also
doing
all
this
feature
work
to
support
kubernetes
resources
as
well.
A
A
A
B
Yeah
there
was
a
question
earlier
about
when
the
new
ui
enhancements
that
luis
was
showing
had
hit
the
code
base,
and
that
was
within
the
last
month.
I'm
not
100
sure
of
exactly
where
os
open
source
is
with
that,
because
in
netflix
we
deploy
all
of
our
apps
straight
off
the
master
branch.
So
we
I
don't
personally,
have
any
concept
of
the
open
source
version
numbers
for
spinnaker,
unfortunately,
but
so.
A
B
Okay,
we've
got
a
question
over
in
the
q
a
there
about
whether
it's
possible
to
create
spinnaker
pipelines
from
code
rather
than
by
the
ui.
That's
not
really
the
focus
of
managed
delivery.
We
part
of
the
part
of
the
idea
of
managed
delivery
is
that
we
kind
of
abstract
you
from
the
from
the
how
of
your
deployments,
and
you
tell
us
what
you
want
deployed
where
and
what
the
rules
governing
that
are,
as
opposed
to
having
to
define
the
steps
for
getting
there.
B
We
do
have
managed
pipeline
templates,
which
was
a
way
of
kind
of
templating
pipelines
for
standardization
across
an
organization
I'm
not
quite
up
to
speed
with
where
the
current
version
of
that
is
because
I
know
google
was
working
on
it,
but
I
don't
know
what
the
state
of
that
is
right
now,
but
yeah.
It's
not
something
built
into
managed
delivery,
because
we're
kind
of
trying
trying
to
hide
away
the
any
any
pipeline
configuration
from
you.
There
may
be
some
kind
of
integration.
B
You
know
in
terms
of
doing
a
more
complex
version
of
what
I
showed
for
verifications
with
with
a
pipeline,
maybe
or
for
if
you
have
unusual
deployment
strategies,
for
example,
something
that
you
would
model
with
a
customer
deployment
strategy
in
in
regular
spinnaker.
We
may
add
some
support
for
that,
but
I'm
that's
not
concrete
on
the
roadmap
right.
B
A
Any
other
questions
I
I
just
so
tracy
had
a
question
on
the
chat
and
I
just
answered,
but
just
for
everyone's
awareness,
she
was
asking
whether
we
have
a
public
roadmap
tracking
the
features
that
we
talked
about
for
the
second
half
of
2021,
and
I
was
mentioning
we
used
to
use
one
of
our
github
open
source
projects
for
that
we
haven't
in
a
while.
But
I
am
happy
to
take
this
suggestion
to
the
manage
delivery
team
here
at
netflix
to
discuss
how
we
can
make
that
process
a
little
bit
more
transparent
yeah.
A
A
A
Yeah,
by
the
way
I
was
going
to
say,
I
have
a
feeling
that
maybe
the
folks
who
have
joined
us
have
had
not
had
a
chance
to
previously
see
any
material
on
managed
delivery.
So
if
you
have
any
questions
on
the
basics
on
what
are
the
goals,
what
are
we
trying
to
do
feel
free
to
to
ask
those?
It's
no
problem
at
all.
I'd
be
happy
to
take
those
as
well.
A
B
B
I
think
the
exception
in
spinnaker
is
is
cloud
driver
which
has
some
fairly
complex
deployment
pipelines
for
the
way
we
deploy
it
within
netflix,
and
in
addition
to
that
that,
I
think
today
we
hit
174
apps
in
in
netflix
managed
with
managed
delivery,
which
is,
as
louise
mentioned
earlier,
on
in
the
presentation
that
that's
like
a
a
100
growth
over
the
last
quarter.
I
believe
yep
yeah,
so
174,
apps
and
now
we're
deploying
oh,
we
are
templating
new
node,
apps
and
java
apps
by
default
with
managed
delivery
at
netflix.
A
Curve
going
that
direction,
of
course,
there's
still
a
ton
of
room
to
grow
because
we
have
like,
I
think,
in
the
order
of
tens
of
thousands
or
a
few
tens
of
thousands
of
applications.
The
last
time
I
I
checked
so
they're
still
yeah,
I'm
not
even
sure
it's
crazy,
but
it's
a
lot
so
there's
still
a
whole
lot
of
room
to
grow,
but
this
is
definitely
the
the
vision
going
forward
for
how
we
expect
most
teams
and
netflix
to
approach
their
their
delivery.
Continuous
delivery
workflows
is
to
use
managed
delivery.
B
Newman
was
just
asking
if
there's
any
eta
on
versioned
environments,
some
of
some
of
the
version
version
environment
stuff
is
already
in
the
code
base
under
the
hood
most
most
of
it's
invisible
to
users,
but
we
are
doing
some
interesting
things
on
the
server
side
to
kind
of
track,
changes
to
environments
and
changes
to
resources
within
that
environment
from
version
to
version
in
terms
of
when
it'll
be
done.
I
always
hate
answering
this
question,
but
I
I
definitely
definitely
like
by
the
end
of
the
year.
A
A
B
A
Just
to
clarify
when
you,
when
you
mention
jenkins
files,
do
you
mean,
as
in
actual
jenkins
files
used
to
create
jenkins
pipelines,
because
that
that
okay,
thanks
for
clarifying
that's
a
very
good
question?
So
I
guess,
if
you
or
your
company
are
using
jenkins
files
today
to
create
pipelines
that
include
the
deployment
step
of
your
delivery
workflow.
In
addition
to
just
like
the
build
and
and
like
unit
test
steps,
then
a
piece
of
that
pipeline
would
be
replaced
by
what
managed
delivery
does
so
our
contract
starts
with
a
published
artifact.
A
This
is
what
we
kind
of
listen
to
right.
Manage
delivery
is
constantly
monitoring
the
artifact
repositories,
based
on
what
you
specified
on
specified
on
that
declarative,
config
file,
and
whenever
we
detect
a
new
one
is
when
everything
that
we
showed
you
in
the
demo
kicks
off
so
like
deploying
a
new
version
etc
evaluating
if
it's
ready
to
be
deployed,
etc.
A
I
only
manage
delivery.
Does
everything
else
yeah
right?
So
that's
what
I
I
mentioned
that
if
you're
using
jenkins
to
do
ci
ncd
both
in
a
pipeline
which
is
I
know,
a
common
pattern
in
the
industry,
is
something
that
I
used
to
do
in
a
previous
job.
Then
you
would
replace,
like
half
of
that
pipeline,
let's
say
with
managed
delivery.
You
wouldn't
have
to
worry
about
the
deployment
part.
This
kind
of
goes
back
into
the
the
basics
and
the
benefits
of
managed
delivery.
A
If
something
fails
during
the
that
particular
execution
of
the
pipeline
to
deploy
your
your
build,
then
you
get
an
error
and
you
have
to
like
manually
retry
when
you
have
to-
or
you
have
to
add
your
own
automation,
on
top
of
the
pipelines
to
automatically
retry
periodically
etc
right.
You
generally
need
to
dig
in
to
figure
out
what
was
wrong
to
decide
what
to
do
and
with
managed
delivery.
A
We
drive
every
action
based
on
that
declarative
state
that
you
specify
in
your
config
file,
which
we
call
the
desired
state
of
your
application
and
so
managed.
Delivery
is
essentially,
in
a
nutshell,
a
whole
bunch
of
monitoring
loops
that
constantly
look
at
the
state
of
the
world
as
it
exists
today
and
compares
that
with
the
state
that
you
declared
in
your
file
to
see
if
the
the
two
match
and
if
they
don't
match,
then
we
take
action
to
correct
it,
and
that
in
turn
gives
us
like
natural
resilience
to
these
temporary
failures,
for
example.
A
So
let's
say
aws
had
a
glitch
in
one
of
the
services
and
when
deploying
an
ec2
instance,
your
pipeline
failed
well,
like
I
said
you
need
to
wait
for
aws
to
recover
and
then
eventually
trigger
that
pipeline
again
with
managed
delivery.
You
don't
have
to
do
that
because
we'll
automatically
retry
periodically
and
let
you
know
what's
going
on
in
that
history
of
the
the
resource
on
the
ui.
B
B
Couple
of
other
questions
over
in
the
qa
q
a
now
I
just
want
to
address
quickly
the
different
deployment
strategies
like
canary
deployment,
fit
into
managed
delivery.
So
canaries
are
available
as
a
constraint
on
an
environment.
So,
for
example,
that
can
mean
that
you
run
a
canary
much
as
you
would
in
a
pipeline
before
deployment
is
allowed
to
go
to
a
particular
environment.
B
That's
an
interesting
one,
because
yeah
netflix
is
so
kind
of
freedom
and
responsibility,
driven
that
we
tend
to
allow
most
people
to
do
anything.
One
thing
that
is
worth
pointing
out
is
that
you
know
your
your
configuration
for
resources
and
infrastructure
is
typically
stored.
Alongside
of
your
code
in
the
git
repository,
so
only
people
who
have
commit
rights
to
that
repository
can
make
changes
to
that
configuration
and
spinnaker
also
takes
actions
using
an
authority
that
is
specified
in
that
manuscript
reconfiguration.
So
you
can
lock
down
you
know.
A
I
was
just
going
to
add
that
I
think
that
sounds
like
a
really
interesting
topic
for
the
sig
meeting,
so
please
just
drop
a
link
on
the
chat
there,
because
the
slides
are
actually
not
attached
to
this
talk
today,
but
please
do
join
us.
It's
open
for
every
for
anyone
to
join.
The
document
is
open
for
editing
with
the
agenda,
so
you
can
just
throw
in
your
suggested
topics
on
there
join
us
on
our
bi-weekly
call,
and
we
will
be
super
happy
to
have
you
over.
A
I
wanted
to
mention
on
the
canary
question
that
we
did
have
a
presentation
from
our
resilience
team
recently
at
the
siege
meeting
going
over
this
plug-in
that
they
developed
for
managed
delivery
internally
at
netflix
and
that
leverages
the
latest
and
greatest
canary
solution
here
in
netflix,
which
unfortunately,
is
not
fully
open
source
at
this
stage,
and
so
that
particular
implementation
is
not
currently
available.
But
I
think
it's
still
a
useful
presentation
to
look
at
just
to
see
what's
possible
and
maybe
get
some
ideas
about
what
could
be
done
in
open
source.
As.
A
B
B
A
A
That
can
call
sorry
not
a
constraint.
It
was
a
deployment,
a
custom
deployment
strategy
which
you
were
talking
about
earlier
about.
That
would
basically
use
a
pipeline
under
the
covers,
and
that
could
then
do
anything
you
needed
really
to
decide
when
it's
okay
to
do
a
deployment
or
not
so
that
feature
request
has
not
been
prioritized.
Yet
we
are
just
about
to
get
started
on
our
q3
planning
here
in
netflix,
but
it's
something
to
watch
out
for
so
again.
B
B
A
A
B
And
also
yeah
putting
ids
into
the
managed
delivery
configuration
is
something
we've
really
tried
hard
to
avoid
so,
for
example,
anytime
you're,
referring
to
like
an
account
or
a
region
or
a
vpc
or
yeah
anything
like
that.
We
we
always
try
and
have
it
as
user
friendly
as
possible
and
have
you
entered
the
name
of
something
but
that's
tricky
with
pipelines,
because
they
don't
have
to
be
unique
and
yeah
and
they
can
be
changed.
Yeah.
A
Yeah,
but
that's
a
good
point,
I
I
believe
that,
when
the
resilience
team
did
their
demo
of
the
managed
canary
plug-in
at
the
the
sig,
they
were
still
using
ids
for
the
for
the
canary
experiments.
It's
just
not
a
great
example
of
what
you
were
just
saying.
We
don't
know
if
that's
been
abstracted
away
yet,
but
to
rob's
point:
whenever
we
can,
we
try
to
remove
the
need
for
you
to
know
the
nitty-gritty
details
of
things,
including.
B
A
We
got
an
update
from
marcel
and
they're
saying
that
for
for
different
from
different
events,
he's
seen
that
the
such
links
have
been
posted
to
the
schedule
afterwards,
I
believe
that's
the
case
with
spinnaker
summit
as
well,
so
yeah.
If
you're
looking
for
the
recording
notes
or
or
any
associated
materials
from
this,
I
would
encourage
you
to
check
back
on
the
main
website
and
the
schedule
afterwards.