►
From YouTube: Accelerating Collaborative Plugin Development - Joe Cavanagh & Benjamin Powell, Apple, Inc.
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Accelerating Collaborative Plugin Development - Joe Cavanagh & Benjamin Powell, Apple, Inc.
Spinnaker's plugin system can significantly benefit an organization by empowering technical users to solve their own problems. Joe and Ben will discuss how we can maximize code reuse, eliminate repository maintenance and toil, and unify CI/CD across many plugins. They will also discuss the mutual benefits of a well-maintained organizational plugin ecosystem for Spinnaker users, developers, and operators. * What is a plugin? * Why plugins? * What to consider when planning your ecosystem * Code Reuse * Plugin Repository * Build * Publish * Operation
A
B
B
B
They
can
be
created
for
both
the
UI
and
the
back
end
like
creating
a
new
stage,
for
example,
and
could
have
any
kind
of
configuration
that
they
need.
The
technical
basis
of
the
plug-in
system
is
the
Spinnaker
extension
Point
interface,
which
defines
which
components
of
Spinnaker
are
intended
to
be
extendable.
B
So
in
the
example
that
we
have
here,
we
have
a
sample
stage.
This
implements
the
stage
definition
builder.
This
Builder
is
used
to
build
new
stages
within
Spinnaker.
This
interface
also
implements
the
stage
the
Spinnaker
extension
Point
interface,
which
allows
for
plugins
to
have
the
entry
point
that
they
need
further.
Plugins.
Can
provide
Orchid
tasks
and
stages,
Atomic
operations
and
pipeline
expressions
and
many
more.
B
Plugins
can
also
provide
any
new
implementation
of
a
Spinnaker
extension
component
and
can
ship
with
any
dependencies
that
they
need,
in
addition
to
being
able
to
ship
with
any
dependencies
that
they
need.
They
can
also
inject
any
application
spring
Bean
within
to
themselves.
Just
like
how
internal
components
can
this
makes
plugins
very
powerful,
but
also
a
dangerous
concept
with
inside
of
the
system.
B
B
B
So,
however,
internal
platforms
are
generally
safer.
Internal
contributors
are
generally
not
out
to
cause
harm,
but
there
is
always
the
risk
of
unintentional
misbehavior
and
always
the
slight
risk
of
a
malicious
internal
actor.
These
things
are
very
rare,
but
they
do
happen.
This
really
highlights
the
importance
of
review,
testing
and
vetting
understanding.
What
you
are
running
is
key
to
success.
B
Has
often
been
said
that
small
problems
have
small,
Solutions
and
I
think
that's
very
true.
We
as
Engineers
often
just
live
with
small
problems,
because
they're,
either
too
hard
to
fix
or
other
priorities
come
up.
Adding
functionality
to
the
main
Spinnaker
is
not
a
trivial
task.
It's
very
it's
a
lot
of
work,
so
that
can
mean
sometimes
that
you
have
to
now
commit
to
a
very
long-term
maintenance
commitment
there.
B
So
the
small
scope
of
a
plug-in
also
allows,
for
you
know
less
technical
people
to
effectively
contribute
a
few
samples
of
of
plugins
can
get
someone
very
far.
I
myself
am
not
an
expert
in
every
tool
that
spiritual
might
talk
to
and
general
CI
CD
teams,
Within
orgs
oftentimes
don't
have
the
bandwidth
to
support
everything
in
a
corporate
ecosystem.
B
So
we
do
have
a
lot
of
technical
users,
though
that
will
be
very
happy
to
build
things
that
they
need
and
utilizing
those
talents
is
good
for
everyone
plug-in
use
cases
are
often
very
similar
in
that
making
a
new
stage
has
the
same
basic
structure,
no
matter
what
that
stage
is
doing
so
creating
samples,
documentation
or
Library
classes.
For
your
plugin
authors
can
dramatically
speed
up
their
work
and
focus
their
efforts
down
the
correct
path.
B
A
Oh,
thank
you
Ben.
So
one
of
the
main
things
we're
working
on
internally
is
having
a
plug-in
platform.
That's
making
Spinnaker
a
target
for
develop
that
engineering
teams
can
reasonably
develop
for
then,
within
the
context
of
an
organization.
There
are
dozens,
hundreds
of
tools
and
services
that
people
use
to
deliver
whatever
it
is
that
they
create
Spinnaker,
probably
supports
many
of
them
out
of
the
box,
but
there's
always
gaps.
A
Obviously,
there
are
a
lot
of
organizations
that
cannot
or
do
not
wish
to
take
on
such
a
huge
burden,
and
this
drives
them
to
seek
other
tools.
Instead,
if
we
can
reduce
the
scope
of
work
to
a
small
self-contained
plug-in,
the
value
proposition
is
suddenly
much
more
attractive.
An
extending
Spinnaker
becomes
a
much
more
viable
option
than
building
bespoke
tooling.
A
A
Teams
don't
want
to
wait
forever,
so
they're
going
to
end
up
doing
their
own
thing,
plugins
provide
a
way
for
them
to
help
themselves,
while
still
having
a
relatively
small
scope
of
work.
This
is
much
more
palatable
to
your
average
project
manager
and
it's
much
more
likely
that
it'll
actually
get
done.
A
But
let's
not
forget
that
it's
always
hardest
to
go
from
zero
to
one.
The
first
plug-in
anybody
writes
is
always
going
to
be
the
most
difficult.
So
what
we
can
do
is
build
a
plug-in
platform
that
takes
away
everything
that
isn't
plug-in
development.
It
makes
it
as
easy
as
possible
for
otherwise
technical
users
to
contribute
to
Spinnaker.
A
A
So
I'm
sure
we
all
love
golden
paths
here.
So
why
not
a
golden
path
for
extending
your
own
tools,
and
so
these
are
the
components
that
one
would
need
to
provide
a
reasonable
basis
for
extending
Spinnaker
and
we'll
go
through
some
of
them
now
number
one.
We
need
to
make
our
code
reusable
one
of
the
major
problems
with
Spinnaker
plugins
is
they
tend
to
exist
in
their
own
little
Islands.
A
These
islands
can
get
quite
stale
if
they're
not
actively
maintained
and,
let's
be
honest,
the
small
plug-in
repo
is
not
the
kind
of
thing
that
often
gets
active
maintenance,
and
once
you
have
more
than
a
few,
it
becomes
necessary
to
have
the
ability
to
quickly
update
and
share
code
among
many
projects
at
once.
The
most
obvious
ways
to
just
extracts
and
publish
some
libraries
very
straightforward
and
gets
the
job
done.
Engineers
have
been
doing
that
for
decades,
however,
I
hate,
bumping
versions
and
I
hate
making
robots
to
bump
versions.
A
It
achieves
this
through
some
dependency
rewriting
magic
within
Gradle
itself.
So
if,
in
the
example
of
a
Java
project
it'll
match
on
the
group
and
the
the
the
second
part-
and
you
know,
it'll
rewrite
it
and
use
the
source
code,
it
just
built
from
right
adjacent
to
the
thing.
So
this
has
a
number
of
advantages.
Anytime,
you
make
a
change
to
Shared
code.
You
get
immediate
compiler
feedback
from
every
other
plugin.
This
makes
refactoring
very
safe
and
you
can
very
quickly
extract
reusable
code
from
existing
plugins.
A
A
The
second
major
item
is
making
use
of
code.
Your
organization
already
has
every
company
writes
code
for
themselves
and
has
libraries
or
clis
or
whatever
it
is
to
talk
to
internal
external
Services.
If
Spinnaker
can
use
those
same
components
that
you
already
have
to
connect
to
those
Services
it'll
be
much
more
useful
and
Powerful
tool
in
your
organization
now,
obviously,
your
internal
libraries
cannot
and
should
not
be
a
dependency
of
the
main
open
source
project.
A
A
So
this
is
greatly
preferable
in
general
to
owning
and
maintaining
a
fork
and
you'll
still
be
able
to
do
everything
you
need
to
do,
but
perhaps
the
most
important
part
of
a
plug-in
platform
is
build
and
test
plug-in
compatibility
is
always
going
to
be
the
number
one
problem
to
solve.
Fortunately,
plug-ins
have
very
similar
builds
and
test
needs,
so
it
makes
perfect
sense
to
unify
the
process
level.
A
It's
also
possible
to
do
full
startup
compatibility
testing
in
CI
if
you're
familiar
with
the
main
Project's
code
base,
you'll
see
some
startup
spring
boot
tests
that
live
there
in
the
code
base,
which
essentially
starts
Orca,
starts
Cloud
driver
and
just
make
sure
the
spring
situation
is
sane
and
everything
is
getting
wired
up
and
the
app
will
actually
start
so
same
thing
as
possible.
Here
you
just
give
it
a
plug-in.
A
A
If
you
have
test
instances
of
Spinnaker,
you
can
also
test
by
running
real
pipelines
using
plug-in
provided
components,
set
up
some
test
pipelines
and
run
them
any
way.
You
wish
on
the
plugins
that
you've
configured
in
your
test
instance
and
based
on
the
complexity
and
the
criticality
of
the
plugin,
you
can
choose
the
level
of
testing.
That's
right
for
you.
A
Not
everything
needs
the
full
test
experience,
but
it
should
be
there
if
it's
needed
plug-in
publishing
is
the
penultimate
step
in
the
process
and
is
the
most
operationally
focused
of
of
all
the
various
steps
and
the
procedure
for
publishing
and
retrieving
plug-in
bundles
is
going
to
vary
almost
entirely
based
on
your
infrastructure,
where
you
store
files.
What
things
you
use,
what
your
Source
controls
product
of
choice
is
it's
all
going
to
change
with
all
of
that,
but
somewhere
you
need
somewhere
to
store
them.
So
these
plug-in
bundles,
they're,
zip
files.
A
They
have
metadata
that
comes
along
as
Json.
They
need
to
be
stored
somewhere
anywhere
that
can
store
stuff
and
serve
files
over
https
good.
To
go
so
and
again,
within
the
storage
we
have
the
bundles
and
the
index.
The
index
is
a
Json
file
in
the
format
you
see
here
it
has
each
plugin
with
its
ID
and
the
list
of
releases
essentially,
and
something
needs
to
regenerate
this
file
whenever
you
make
a
new
plugin.
So
this
is
ideally
another
fully
automated
part
of
the
process
and
should
be
part
of
your
CI
tooling.
A
A
So
Helm
is
a
good
parallel
to
this
kind
of
design.
Helm
has
a
similar
like
root
level
index
yaml
file,
which
just
lists
everything
that
there
but
humans
don't
read
that
unless
something's
broken,
you
know,
that's
read
by
other
tools.
Same
concept
applies
here
and
now
once
you've
written
built
and
published
your
plugin,
and
it's
now
time
to
run
it
somewhere.
Plugins
can
unfortunately
cause
an
operational
burden.
So
it's
important
to
have
a
collaborative
relationship
with
whoever
operates
your
Spinnaker.
This
is
also
true.
A
The
other
way
operators
should
have
collaborative
relationships
with
plug-in
authors,
see
there's
going
to
be
problems
and
mutual
respect
and
resolving
problems
in
a
constructive
way
is
going
to
be
going
to
be
the
best
way
to
do
that.
If
you
do
happen
to
operate
your
own
Spinnaker
you're
done,
congratulations
configure
your
plugin.
However,
you
can
figure
anything
else
and
run
it.
However
you'd
like,
but
if
someone
else
operates
your
Spinnaker,
then
you
must
be
ready
to
work
with
them.
If
there
are
issues,
as
mentioned
before,
a
robust,
build
and
test
process
will
catch.
A
The
vast
majority
of
issues
well
ahead
at
this
point,
but
inevitably
something
will
explode,
and
this
is
normal.
Plug
and
authors
are
not
always
Spinnaker
Wizards
you're
not
going
to
get
like
the
world's
most
excellent
code
in
there
all
the
time,
because
you
know
they're
looking
for
something
that
solves
their
use
case
and
is
good
enough.
They're,
not
always
Professional
Engineers
they're,
just
technical
people
who
want
to
contribute-
and
they
should
be
able
to
so-
but
this
will
require
a
little
bit
of
patience
from
the
operational
side
on
on
rare
occasions.
A
So,
but
at
this
point
the
proper
course
of
action
is
just
to
collaborate.
If
the
plugin
is
very
important,
super
critical,
you
know,
maybe
have
a
a
line
of
communication
always
open.
Otherwise,
the
fact
that
it's
all
in
one
place
makes
it
very
easy
for
anyone
to
go
in
and
fix
it.
So,
for
example,
if
there's
a
new
Spinnaker
release
and
it
breaks
every
plugin
I
have
the
ability
to
go
in
and
fix
everything
myself,
for
example,
should
that
be
necessary,
I
don't
have
to
track
down
27
000,
plug-in
authors
and
be
like
hey.
A
Well,
you
got
to
change
this
thing
to
this
other
thing,
not
just
go
in
and
do
it
to
everything
and
Bam
everything's
republished
everything's
done,
but
along
the
way
we
did
find
some
items.
That
would
be
good
candidates
for
refinement.
The
most
critical
is
safety
and
stability.
Plugins
are
very,
very
powerful,
but
that
power
magnifies
the
wrist
tremendously.
As
mentioned
before,
plugins
have
access
to
absolutely
everything
within
Spinnaker.
A
It
might
be
useful
to
control
what
spring
resources
and
beans
a
plug-in
can
use,
and
you
know
mitigate
some
of
the
plug-in
risk
that
way,
but
plugins
that
fail
spring
Auto
wiring
will
also
fail
the
entire
service,
because
it's
all
part
of
the
main
spring
context
in
the
end
plug-ins
and
their
classes,
they
all
get
promoted
and
slurped
up
into
the
main
spring
pile
of
spring
stuff,
and
if
it
doesn't
come
together
correctly
spring
is
just
gonna
fold
over
and
be
sad.
So
we
don't
want
spring
to
fall
over
and
be
sad.
A
We
want
it
to
be
running
and
relatively
happy,
so
the
nuts
and
bolts
of
the
Spinnaker
code
base
can
also
be
a
little
bit
problematic
for
extensibility.
So
the
most
obvious
way
to
write
spring
in
general
is
to
have
configuration
classes
with
Factory
methods
that
make
some
beans
and
do
that
but
and
spring
will
collect
and
provide
all
their
various
dependencies.
You
know
that's
kind
of
the
point
of
spring,
but
plugins
aren't
yet
loaded
when
most
of
these
configuration
classes,
Constructors
and
Factory
methods
are
called,
so
they
won't
see
those
plug-in
providing
components.
A
So
if
you
have
a
factory
method
that
takes
a
list
of
some
object
and
one
of
those
is
meant
to
be
provided
by
a
plug-in
you're
not
going
to
get
the
plug-in
one
because
it
doesn't
exist
yet
so
what
you
have
to
do
is
build
the
code
to
consume
plugins,
so
spring
has
ways
to
dynamically.
Provide
beans
of
a
certain
type,
notably
the
object
provider
construct
within
spring
and
lots
of
classes
within
Spinnaker
have
already
been
updated
to
use
object
provider
to
fetch
to
fetch
beans
dynamically.
A
So
we
can
avoid
this
by
keeping
extensibility
top
of
mind
when
doing
new
development.
If
a
feature
can
be
reasonably
augmented
by
plugins,
it
should
be
a
Spinnaker
extension
point
from
day
one
and
it
should
also
be
capable
of
consuming
plug-in
provided
components
dynamically.
So
the
more
stuff
that
works
with
plugins
out
of
the
box,
the
better
plugins,
are
going
to
be
so
I
have
a
bit
of
a
demo
for
you
as
to
what
such
a
thing
might
look
like
if
it
were
running
on
public
GitHub,.
A
All
right,
so
here's
the
various
components.
What
we
have
here
is
a
set
of
default
configuration
that
is
intended
to
run
Spinnaker,
basically
out
of
this
folder
and
I'll
get
to
that
in
a
minute.
So
this
is
a
bit
of
build
plugin
code
that
helps
with
all
these
various
tasks.
This
is
a
postgres
initialization
which
will
init
the
postgres
DB,
which
lives
on
a
Docker
volume.
A
We
have
a
common
Library.
This
is
just
a
regular
Java
library
that
provides
some
Java
code
to
our
sample,
plug-in
a
and
Sample
plugin
B.
These
plugins
don't
actually
really
do
anything
they're
just
here
to
show
you
know,
take
up
some
space
and
make
some
GitHub
releases,
and
then
we
have
a
template
to
use
to
generate
a
new
plugin
based
on
whichever
Services
you'd
like
to
extend
so
as
far
as
Gradle
composite
builds.
The
way
that's
set
up
is
here
in
settings.gradle.
This
is
a
very
standard.
A
A
Gradle
will
again
go
find
it
in
this
repo
because
we've
told
it
where
it
is,
and
it
will
build
this,
and
it
will
use
that
in
whatever
dependency
so
plug
in
a
and
plug
in
B
sample,
both
use
this
and
that
gets
built
every
time
they
get
built
and
that's
the
essence
of
a
composite,
build
there's.
Also
a
Docker
compose
set
up
here,
which
has
all
of
the
Spinnaker
public
container
releases.
Here
you
can
choose
any
release
or
the
release
from
master.
A
So
what
I
have
running
is
the
if
you
can
see
this
right
here,
so
this
is
Docker
PS.
This
is
running
a
variety
of
Spinnaker
Master
images
we
live
on
the
edge
over
here
so
what's
also
included,
is
a
postgres
and
a
redis
and
including
that
default
configuration
I
mentioned
before
is
postgres
and
redis
already
set
up
for
Spinnaker
to
use
for
local
development,
and
that's
how
this
is
intended
to
be
used.
A
You
know
you
have
a
local
Spinnaker,
runs
and
compose
you
publish
plugins
to
configure
it
that
config
gets
mounted
to
each
container
and
then
all
you
have
to
do
to
load.
Your
plugin
is
restart
Gorka
or
Cloud
driver,
whichever
plug-in
whichever
service
the
plugin
is
for.
If
it's
deck
you
just
reload
the
page,
so
that
part
is
pretty
pretty
pretty
painless.
A
A
A
So
you
can
see
that
the
the
other
plug-in
builds
did
succeed
because
the
API
didn't
change.
The
functionality
of
the
code
was
just
broken,
so
we've,
but
the
the
process
has
told
me:
your
common
code
is
broken,
you'd,
better
fix
it
and
the
same
goes
the
other
way.
So,
if
I
make
an
API
change
to
Shared
code,
I
get
instant
feedback
from
every
other
plugin
that
uses
that
Library.
So
here's
my
sample
common
code,
it's
nice
and
happy
the
test
passed,
but
I
changed
the
name
of
of
a
function.
A
So
instead
of
is
blank
I've
named
it
is
this
string
blank.
You
know,
because
I
I've
heard
that
being
explicit
is
a
good
thing.
So
we're
going
to
change
all
my
change.
All
my
function
names
to
be
more
explicit.
Unfortunately,
that
broke
everything.
And
luckily,
for
me
the
CI
across
all
of
my
plugins
at
the
same
time,
told
me
that
I
just
broke
every
plugin
and
I
should
probably
reconsider
that
change.
Probably.
A
And
over
here
we
have
I'll,
give
an
example
of
what
a
release
management
looks
like
so
here
I'm
bumping
the
version
of
sample
plugin
a,
and
this
looks
good
yep.
That's
definitely
a
version
so
we'll
just
we'll
just
merge
that
in
there
and
then
we'll
head
over
to
our
our
GitHub
actions
page
and
run
the
publish
job
for
sample
plugin
a
and
while
that's
running
I'll
go
through
the
fact
that
this
is
also
a
fully
fledged
plug-in
repository
that
updates
its
list
of
plugins.
A
Every
time
you
publish
anything
so
that
plugins.json
file,
you
saw
in
the
presentation
right
before
that's
also
right
here.
This
is
automatically
generated
by
the
build
tooling
and
automatically
updated
every
time
that
a
new
release
happens
and
it
just
Auto
commits
it
right
back
to
the
repo,
and
so
everything
in
here
is
every
release.
That's
been
made
from
this
repo
gets
stored
in,
in
this
case
GitHub
releases.
If
I
click
this
link,
you
can
see,
it
will
give
me
a
nice
happy,
zip
file
and
there
it
is,
and
there
we
go
this
space.
A
B
A
That's
your
entire
development
flow,
we'll
see
if
this
has
finished
yet
it
hasn't
come
on
I
believe
in
you
go
GitHub
github's
trying
its
best
in
the
meantime,
this
is
actually
I
actually
have
all
this
running
locally
on
my
machine
as
well.
So
this
is
all
those
containers
you
mentioned
we're
starting
from
that
Docker
compose
file
and
if
I
look
in
this
pipeline,
I
can
see
that
my
sample
plugin
a
is
present
here
and
I.
Can
you
know
I've
already
added
a
couple?
A
A
A
A
A
Well,
this
is
a
configuration
default
that
I
put
in
my
sample
plugin,
so
plugins
have
configuration,
as
we
mentioned,
So
and
I've
written
in
its
default
config
that
this
is
the
string
that
it
should
use
whenever
it
doesn't
have
a
string
and
there
it
is
so
there
we
go
it's
if
I
wanted
to
make
a
change.
I
can
just
as
I
mentioned
change.
The
code
rebuild
the
plugin,
restart
Orca
in
this
case
and
I'll
be
I'll,
be
iterating
very
quickly.
A
All
right,
so
let
me
let
me
repeat
the
question,
so
the
question
was
about.
If
we,
if
and
when
we
do
break
something
you
know,
do
we
not
have
an
obligation
to
fix
all
that
and
the
answer
I
think
is
yes,
because
you
really
like
it's
very
possible
to
develop
when
you're,
using
this
kind
of
a
setup,
it's
very
easy
to
develop
in
a
way.
That's
either
a
Backward,
Compatible
or
B.
You
just
go
in
and
fix
it.
So
you
know
it's
very.
You
know
you're
in
your
report.
A
You
just
like
you
know,
IntelliJ.
It's
like
find
me
all
usages
of
this.
Replace
with
this
and
like
you,
you
know,
that'll
get
you
there
pretty
much
all
the
time.
So,
whichever
way
is
most
appropriate
with
the
groups
you're
you're
working
with
some
people,
don't
like
it
when
other
people
touch
their
code
and
that's
totally
fine,
but
so
what
we've
set
up
in
the
GitHub
repo?
There
is
a
code
owner's
file,
so
they'll
at
least
get
pinged,
be
like
hey,
there's,
an
incoming
change
to
your
code
base.
A
This
is
a
just
a
simple
refactor
and
they're
like
okay,
yep
looks
good.
So
the
intended
use
case
is
for
everyone
to
be
okay
with
that
and
be
like
all
right
well
now,
but
if
someone
else
breaks
it
all
right
well,
now
you
might
be
a
little
mad,
but
we'll
we'll
work
together.
It'll
be
okay,
we'll
undo
it
we'll
fix
it.
It's
very
easy
to
revert.
You
can
revert
10
plugins
by
reverting
once
and
running
the
published
job.
So
it's
like
you
know
again,
it's
it's
not
like
a
thing.
A
A
So
there's
a
few
things
that
we
wanted
to
do
so
of
the
parts
that
exist
in
Spinnaker
stages
are
definitely
the
most
popular
and
the
thing
we
write
the
most
of
internally
stages
to
do
a
thing,
to
talk
to
a
tool
to
talk
to
something
and
that's
definitely
number
one.
However,
in
Orca
there's
also
an
expression
you
know
in
pipelines
in
Spinnaker,
there
are
expressions
and
those
expressions
are
actually
plugable.
A
So
if
you
can
make
you
can
make-
and
we
have
made
several
pipeline
expression
helpers-
just
to
accomplish
various
tasks,
so
a
different
form
of
input
data
coming
in
you
know,
slice
and
dice.
It
turned
into
something
that
you
know
a
helm-bake
stage
or
a
customized
stage
can
understand
so,
but
you
have
free
limited,
it's
totally
totally
open
what
sort
of
pipeline
expression
helper
you
can
provide,
for
example,
that's
another
one
and
then.