►
From YouTube: Event-based Continuous Delivery: The End of the Monolithic Pipeline - Andreas Grabner, Dynatrace
Description
Event-based Continuous Delivery: The End of the Monolithic Pipeline - Andreas Grabner , Dynatrace
While software architects have broken their monoliths into event-driven service architectures, many pipeline architects still try to apply a monolithic pipeline approach to deliver these new architectures. This results in constantly outdated pipeline code, tight integration of process and tools, lengthy diagnostics sessions to fix broken pipelines and puts strains on the underlying resources that build, deploy, test and validate. In this presentation we introduce a new approach: Event-based Continuous Delivery which decouples the declaration of processes from tooling. It uses a “everything as code” approach which includes deployment, testing, quality gate, observability and promotion definitions. By breaking your existing monolithic pipelines into smaller tasks this approach allows you to reuse your existing investment!
A
Hello,
cdcon
community,
my
name
is
andy
gravner.
I
am
recording
this
from
lint
austria,
where
I'm
from
I'm
going
to
talk
about
a
guide
to
event
rhythm
as
serene
inspired
devops.
I
know
this
is
a
lot
of
buzzwords
in
a
single
title,
but
hopefully
you
will
see
that
we're
actually
really
trying
to
solve
a
problem
here.
Who
are
we
well?
A
I
am
representing
captain
a
cloud
native
sandbox
project,
a
cncf
sandbox
project
captain,
as
you
can
see
on
the
bottom
spelled
ke
ptn
if
you're
interested
more
after
this
talk
to
learn
about
captain
to
contribute
to
try
it
out,
you'll
see
how
you
can
follow
us,
how
you
can
store
us,
how
you
can
join
this
lecture
and
lens
on
in
my
day
job.
I
also
work
at
dynatrace,
but
today
this
is
really
focused
on
captain
and
how
we
want
to
change
the
way
we
do
traditional
delivery
and
also
operations
all
right,
let's
get
started.
A
So
what
we
are
a
lot
of
us
are
asked
to
deliver.
Is
a
modern
cloud
native
progressive
to
live
in
operations
workflow.
So
what
that
means?
If
you
have
a
three-stage
pipeline
like
I
have
here,
and
you
have
build
number
three
deployed,
if
you
are
a
developer,
you
want
to
have
an
experience
where
you
do
a
pull
request
that
build
is
then
deployed
and
tested
in
dev.
Then
you
evaluate
against
your
slos
some
quality
criteria
and
depending
on
how
that
goes,
hopefully
everything
is
good.
It
gets
promoted
into
the
next
stage
same
thing.
A
The
pipeline
should
deploy
and
test
because
you
run
probably
more
tests.
You
want
to
evaluate
against
against
your
slos.
You
want
to
make
sure
everything
is
good
and
then,
depending
on
your
organization,
you
may
not
want
to
automatically
promote,
but
you
want
to
get
the
chance
to
say:
let's
pull
this
new
build
that
made
it
through
staging
into
prod.
A
If
that
toggle
switch
back
actually
succeeded,
because
if
not,
then
obviously
you
have
to
interact
anyway,
but
this
is
kind
of
a
way
how
we
can
increase,
speed
and
quality
through
a
lot
of
automation
in
progressive
delivery.
Now,
on
the
operation
side,
right,
if
things
run
in
production,
then
we
want
to
integrate
with
your
monitoring
and
alerting
tools.
So
if
there
is
a
problem,
then
we
want
to
react
on
it.
A
So,
for
instance,
there's
a
failure
rate
increase,
maybe
as
an
automated
action,
we
want
to
scale
up
most
importantly,
so
every
time
we
execute
an
action
we
want
to
evaluate,
we
want
to
make
sure
that
the
system
actually
is
back
to
its
healthy
state
or
its
intended
state.
By
looking
at
dslos
in
case
the
slos
are
not
where
we
are.
Maybe
we
can
execute
another
action
fully
automated
and
the
most
important
thing
here
is:
every
time
we
execute
an
action
we
want
to
evaluate
if
this
action
actually
solved
the
problem.
A
If
none
of
these
actions
is
doing
something
good,
then
obviously
we
can
escalate,
but
in
the
end
this
is
kind
of
the
process.
What
we
call
automate
operations,
some
call
it
self-healing,
you
know
pick
whatever
fancy
term
you
like,
but
this
is
the
world
we
live
in,
that
things
are
asked
for
us
to
deliver
to
our
organizations.
However,
in
reality,
what
we
have
seen
only
a
very
small
number
of
organizations
is
actually
there
and
we-
I
don't.
I
didn't
come
up
with
these
numbers.
We
actually
did
a
survey.
A
We
also
work
with
our
captain
open
source
community,
and
this
is
also
why,
in
captain,
we
want
to
address
the
root
causes
at
least
three
problems
that
we
have
seen
people
struggling
with,
and
this
is
time
wasted
in
maintaining
traditional
pipelines.
Then
time
spent
in
manual
tasks
along
the
pipeline
and
then
also
in
operations.
Time
spent
in
manual
remediation,
and
these
are
the
three
things
I
want
to
focus
on
in
the
next.
You
know
15
minutes
or
so
and
show
you
how
captain
addresses
these
problems
all
right.
A
So
first
one
is
we're
spending
a
lot
of
time
in
maintaining
monolithic
pipelines.
So
what
that
means?
This
is
a
screenshot
of
one
of
our
jenkins
pipelines.
We
actually
have
internally,
it's
not
that's
that
big,
but
350
lines
is
already,
you
know
reasonable
size,
but
the
problem
is
not
the
size.
The
problem
is
in
the
classical
pipeline.
You
have
a
mixture
of
process
definition
and
target
platform.
So
where
do
you
deploy
into
what
type
of
tools
you
have?
Everything
is
really
hard
coded
into
this
particular
pipeline
definition.
A
Whether
this
is
jenkins
or
other
tools,
and
so
there's
really
no
clear
separation
of
concerns
on
how
to
define
the
process,
how
to
define
the
tooling
and
how
the
developer
can
actually
properly
use
it
without
having
to
mess
things
up.
The
problem
is
not
only
these
pipelines
that
are
hard
coded,
but
a
lot
of
the
time.
You
start
with
a
pipeline
that
looks
good
for
one
project,
then
you
take
it
apply
it
to
other
projects
with
some
slight
modifications
and
then
more
and
more
people
are
using
it.
A
And
then
you
have
this
classical
snowflake
effect
where
you
have
an
initial
original
source
of
code
and
then
it
got
modified
slightly
and
then,
if
something
breaks,
you
don't
really
know
anymore.
Why?
Why
does
it
break?
Who
brought
in
this
plug-in?
What
is
this
thing
doing
and
then
it's
really
hard
to
to
keep
this?
You
know
pipelines
running
again,
and
this
is
also
why
we're
spending
so
much
time
in
keeping
the
pipelines
running
because
they
break
a
lot.
So
we
want
to
solve
this
problem
through
an
event
driven
approach.
A
We
want
to
give
you
back
the
time,
because
I
think
engineers
should
not
focus
on
fixing
pipelines
constantly.
So
how
do
we
do
this?
The
solution
is
actually
really
simple.
Is
we
are
breaking
apart
the
dependencies
between
your
process,
definition
and
your
tooling?
So
that
means,
if
you
have
on
the
left
side,
your
classical
you
know
build
pipeline
process
or
your
delivery
process
and
on
the
right
side,
the
actions
that
you
do
instead
of
hard
coding
them.
A
We
rip
it
apart
and
just
as
in
modern
software
architecture,
where
you're
building
event
driven
systems,
you
basically
use
eventing
to
then
tell
the
tools
that
they
should
do
a
particular
job
as
part
of
your
workflow.
So
you
have
on
the
left
side
a
workflow
orchestrator
that
takes
care
of
the
workflow
and
is
then
triggering
events
to
then
actually
trigger
the
right
actions.
A
So
the
idea
is,
if
we
need
to
deploy,
let's
say
container
one
in
a
blue
green
fashion
in
depth,
then
the
event
is
sent
out
and
a
tool
that
is
registering
to
these
events
can
say.
Yes,
I
can
do
this,
so
let
me
deploy
and
when
I'm
done,
I'm
sending
back
the
event
that
I'm
down
and
then
the
workflow
engine
or
the
orchestrator
can
then
say:
okay,
the
next
thing
after
deployment
might
be
testing
and
then
it's
then
sending
a
test
event.
A
But
this
is
a
clear
separation
of
concerns,
process,
definition,
tooling
and
then
in
the
middle
we
use
eventing
to
connect
the
whole
thing,
and
I
think
this
is
the.
This
is
not
a
magic
ingredient,
but
it's
an
ingredient
that
we
want
to
apply
to
continuous
delivery
and
automating
operations,
and
this
is
where
captain
comes
in.
So
the
way
captain
works.
Captain,
as
I
said,
is
a
cncf
sandbox
project.
You
install
it
on
any
kubernetes
flavor.
What
you
really
get
is
a
control
plane
that
is
managing
the
flow
of
the
processes.
A
The
application
flow
and
is
is
using
eventing
to
then
connect
with
the
tools
for
eventing
we're
actually
using
nets
and
some
other
open
source
projects.
But
this
is
kind
of
the
the
control
plane.
We
have
an
api
how
we
can
interact
with
it.
We
also
have
a
ui,
which
you
will
see
later
in
the
demo.
Now
on
the
top,
we
are
allowing,
let's
say,
site,
reliability,
engineers
or
whoever,
that
is
in
your
organizations,
to
define
the
application
plan
or
the
process.
A
A
Then
you
may
have
another
team,
let's
say
the
devops
team,
maybe
it's
your
tooling
team
or
your
pipeline
team.
They
can
define
which
tools
to
be
used.
So
this
is
what
we
call
the
uniform
where
you
say.
I
have
these
tools
and
they
are
registering
for
these
types
of
events,
because
let's
say
you
want
to
use
helm
for
deployment,
you
want
to
use
chain
meter
for
testing.
You
want
to
use
prometheus
for
monitoring.
A
Then
you
can
install
these
tools
that
are
just
listening
for
these
events,
as
the
captain
control
plane
is
executing
the
workflow
now,
the
beneficiary
of
all
of
this
is
the
developer.
So
if
the
developer
has
a
new
artifact
makes
a
pull
request
and
triggers
a
captain
workflow
then
captain
is
sending
exactly
these
events
to
then
trigger
the
tools
that
are
registered
to
handle
these
events
and
is
therefore
pushing
an
artifact
through
deployment,
testing,
validation,
promotion
and
also
in
operations.
A
So
this
is
now
more
focused
here
on
on
the
delivery
process,
but
we
also
have
the
process
for
operations.
If
a
problem
comes
in
from
your
monitoring,
alerting
tool,
captain
will
also
orchestrate
a
workflow
of
evaluating
the
problem
executing
an
action
and
validating
if
the
action
succeeded
and
then
does
this
in
a
repetitive
way.
This
is
the
architecture
of
captain.
The
benefit
here
is
with
a
separation
of
concerns.
A
One
side
can
change
the
process
at
any
time
without
impacting
the
tooling,
and
the
other
side
can
also
change
the
tooling
at
any
point
in
time
without
impacting
the
the
process.
Definition.
There's
no
there's.
No,
let's
say
big
monolithic
pipeline
anymore.
Everything
is
hard
coded.
Now.
Let
me
go
to
a
quick.
My
first
demo,
I
do
have
a
three-stage
pipeline.
As
I
said
earlier,
I
have
my
sample
app
in
four
versions
available.
A
Every
version
has
slightly
different
problems
built
in
and
in
order
to
kick
off
the
build
or
the
deployment
of
version
number
four,
I
just
say,
captain
send
event
new
artifact
and
then
what
captain
does
in
its
event,
driven
fashion?
It
first
makes
updates
to
the
git
repo.
So
in
my
case
it
updates
my
helm
charts
with
the
new
version.
It
then
does
a
helm
deployment.
It
then
does
a
geometer
execution
and
then
the
quality
gates
get
executed.
A
You
know
I've
specified
that
I
have
automated
approval
into
staging,
which
means,
if
it's
good,
the
quality
gate
it
goes
into
staging
the
same
step
happens:
quality
gate
is
enforced
at
the
end,
then
I
specified
manual
approval
because
I
don't
want
everything
to
go
into
prod.
If
it's
a
good
build,
then
I
get
the
choice
to
say
yes
or
no.
This
is
where
you
can
say,
promote
or
not,
as
you
can
see,
on
the
right
and
if
that
happens
same
thing,
works
same
same
process
happens.
A
A
This
is
the
process
definition
that
I
have
in
my
captain
instance.
You
can
see
here
exactly
what
I
said
earlier.
We
call
this
the
shipyard.
I
have
my
dev
stage.
I
have
my
staging
and
I
have
my
prod
for
with
the
different
deployment
strategies,
test
strategies
and
approval
strategies
in
production.
I
also
have
a
remediation
strategy,
which
is
a
use
kit
I'm
showing
later,
and
in
order
to
kick
things
off,
I
only
have
to
do
captain
send
event.
New
artifact
captain
is
organized
in
projects.
A
A
This
is
the
build
number
four
that
I
did
this
morning
when
I
did
the
recording-
and
you
can
see
here
the
full
chain
of
events.
So
captain
is
sending
these
events
and
is
therefore
triggering
the
right
tools.
So,
for
instance,
it
deployed
build
number
four
in
depth.
This
is
my
build
number
four
right
looks
strange
with
the
right:
there's
not
a
whole
lot
to
it
to
the
app,
but
it
brings
a
point
across
then
the
tests
are
executed.
A
I
didn't
specify
extra
slos,
which
means,
depending
on
the
test
result
it
goes,
it
does
go
a
no-go,
then
it
went
into
staging
it
deployed
into
staging.
Let's
also
open
this
one
up
build
number
four
and
staging
that's
great.
Then
more
tests
got
executed.
I
actually
have
some
peak
performance
test
here
with
jmeter
and
then
one
of
the
magic
ingredients
comes
in.
This
is
the
slo
validation.
A
So
in
my
case,
captain
reaches
out
to
my
monitoring
tool
and
pulls
in
defined
metrics
that
I
have
and
then
is
evaluating
it.
And
then
it's
giving
me
a
result,
and
I
got
a
hundred
out
of
a
hundred
points
which
is
great,
which
means
it's
now
ready
to
promote
it
into
production.
I
can
either
select
it
here
to
say,
go
or
I
can
also
go
to
the
environment
overview
where
I
can
see.
I've
built
number
four
in
depth.
Build
number
four
in
staging
in
broad.
A
I've
still
built
number
three,
but
build
number
four
would
be
available
because
we
achieved
a
hundred
percent.
So
in
this
case
I
let
it
go,
and
now
captain
is
going
to
continue
that
workflow.
So
if
I
go
back
here
right,
it's
now
continuing
that
workflow,
which
means
first
the
configuration
change,
then
the
deployment
then
the
the
testing
and
then
either
keeping
it
or
rolling
it
back,
because
this
is
a
blue
green
deployment.
A
A
That
means
once
the
container
is
built
and
pushed
to
the
registry,
then
they're
calling
captain
the
whole
cd
workflow
through
the
captain
api
to
then
do
multi-stage
deployment
with
the
quality
gates
with
the
testing
and
the
integration
into
monitoring
all
right.
So
this
was
the
first
problem
that
I
wanted
to
address.
A
The
second
thing
is
a
lot
of
time
in,
in
pipelines
in
traditional
pipelines,
is
spent
in
manual
deployment
validation.
What
we've
seen
is,
I
assume
you
have
a
lot
of
a
lot.
A
lot
of
you
have
pipelines,
whatever
pipelines
you
have
where
you
do
test
the
build
test
and
deploy,
and
then
you
run
some
tests
and
then
typically
a
lot
of
time
is
spent,
as
we
have
seen
with
manual
approvals.
Why
is
that?
A
Well,
because
if
you're,
if
you
have
a
functional
test
automation,
it's
sometimes
hard
to
say
this
functional
test
failed,
but
is
this
really
a
feature
that
is
actually
critical
for
us
for
the
business?
You
know
why
do
these
questions
come
up,
because
I
think
a
lot
of
organizations
still
haven't
really
specified
good,
slis
and
slo.
So
what
is
really
important?
A
Also
if
you
include
performance
testing,
it's
really
hard
to
look
at
all
these
metrics
and
sometimes
you're
overwhelmed
to
say:
is
this
better
or
worse
and
a
lot
and
more,
a
lot
of
organizations
are
now
also
including
monitoring
data,
which
means
even
more
data,
and
so
it's
it's
sometimes
hard
to
really
make
a
decision.
This
is
why
why
things
take
that
long-
and
this
is
why
we
wanted
to
solve
this
issue
by
automating
the
approval
through
an
sli
and
so
based
approach.
Now,
if
you're
new
to
sls
and
slos,
we
didn't
come
up
with
it.
A
I
think
google
didn't
come
up
with
it,
even
though
they
have
they
brought
it
to
the
world
with
with
some
fancier
terms,
but
essentially
this
is
part
of
their
sre
practices.
The
site,
reliability,
engineering
practices,
they
talk
about
slis,
so
these
are
simple
metrics,
so
something
you
can
measure
like
the
error
rate
of
login.
Then
your
slos,
your
objectives.
So
what
do
you
expect
that
metric
to
be
let's
say,
error
rate
of
login
should
be
less
than
two
percent
over
a
30-day
period.
A
A
So
there's
a
great
video
from
google
and
also
in
general,
I
took
this
basically
from
from
google-
did
a
really
great
job
in
advocating
this.
Now
what
google
talks
about
and
what
the
world
talks
about
is
using
slos
in
production.
So
your
monitoring
tool
of
choice,
I'm
pretty
sure,
can
monitor
report
and
alert
on
slos
on
a
service
basis
on
an
application
basis.
Every
month
you
get
your
slos,
based
on
on
your
your
metrics,
whether
this
is
throughput
error
rate
or
response
time
or
any
other
metric,
but
we
thought
why
not
shift
this
left.
A
Why
not
take
the
same
concept
and
metric
against
the
threshold
over
a
period
of
time
and
do
it
as
part
of
delivery
and
that's
what
captain
quality
gate
does
so
every
time
you
push
an
artifact
through
the
pipeline
after
the
tests
get
executed,
we
automatically
reach
out
to
your
monitoring
tools
or
to
your
testing
tools
or
any
type
of
tool,
pull
in
metrics,
compare
them
either
against
the
threshold
that
is
specified
or
against
previous
builds
for
regression
detection
and
then
tell
you
good
or
no
good,
all
right
now.
This
brings
me
to
the
next
demo.
A
I
want
to
show
you
how
this
works
with
captain
I'm
using
dynatrace
as
an
example,
but
you
can
do
the
same
thing
with
prometheus
or
any
other
monitoring
tool,
because
captain
has
been
is
open,
so
it
can
pull
data
from
any
type
of
data
source.
So,
in
the
case
that
I'm
going
to
show
you
with
dynatrace,
you
specify
a
dashboard
where
you
have
your
metrics
on,
and
these
are
then
the
metrics
that
captain
will
use
to
validate.
So
it's
automating
the
analysis
of
metrics
and
then
it
gives
me
a
score
back.
A
So
let
me
walk
over
you've
seen
this
earlier
right.
This
is
kind
of
my
my
quality
gate
from
build
number
four.
Now,
if
I
click
on
this
dashboard
link
here,
this
is
actually
the
dashboard
that
was
used
in
the
analysis,
so
it
is
as
simple
as
putting
metrics
on
a
dashboard.
I
wanted
to
have
response
time,
p95,
p90
and
p50.
A
I
also
wanted
to
have
some
test
transactions
from
my
tests,
and
I
also
want
to
have
some
process.
Metrics
cpu
memory
event.
Loop,
tick
account.
My
app
is
a
node.js
app,
so
I
just
added
these
metrics.
You
can
add
any
type
of
metric
on
it.
All
these
metrics
are
then
evaluated
against
the
thresholds
that
you
specify
here
either
static
thresholds
or
absolute
thresholds,
or
relative
relative
means
with
the
previous
build
and
really
what
captain
does.
A
A
I
actually
was
rolled
back
again.
Why?
Because
my
build
number
four
failed
in
production,
because
my
build
number
four
actually
had
an
issue,
so
that
was
automatically
rolled
back,
because
the
evaluation
after
the
production
deployment
failed
again
because
my
failure
rate
increased
dramatically
and
therefore
it
was
rolled
back.
So
this
is
how
all
this
this
concept
works.
A
One
example
also
how
you
can
integrate
just
quality
gates
with
your
existing
delivery
pipeline
is
what
christian
is
doing.
They
are
also
using
gitlab
they're,
doing
deployment
testing
and
in
the
verify
stage,
they
then
trigger
a
captain
evaluation
where
captain
is
then
collecting
all
the
data
comparing
the
slis
against
the
slos
and
then
telling
gitlab
whether
this
is
a
good
way
that
build
and
with
this
automating
and
otherwise
manual
task.
A
Now.
Third
problem
a
lot
of
time
once
things
are
in
production
and
there
are
problems
in
production
is
spent
in
remediation,
and
we
want
to
solve
this
also
through
an
event-driven
sre
inspired
approach.
So
what
that
means
is
whatever
monitoring
tool
you
have.
That
can
send
an
alert
whether
it's
a
prometheus
alert
or
a
dyna
trace
problem.
A
So
in
this
case,
if
there's
a
conversion
rate
drop
coming
in
and
the
root
cause
is
a
cpu
pressure,
then
my
remediation
workflow
tells
captain
first
trigger
the
scaling
up
of
my
system,
but
then
very
important,
evaluate
if
that
action
actually
had
the
desired
impact
by
looking
at
the
slos
again,
I
also
added
blo
business
level
objectives
because
you
can
also
add
any
type
of
business
metrics,
like
conversion
rates,
user
experience
and
so
on.
If
this
doesn't
solve
the
problem,
you
can
define
a
next
action
again
re-evaluate
afterwards.
A
If
nothing
of
this
solves
the
problem,
then
obviously
can
we
we
will
escalate
now.
This
is
what
we
call
closed
blue
permediation,
and
this
is
something
that
people
are
really
love,
but
some
people
are
scared
to
start
with
this
in
production.
This
is
why
I
believe
the
marriage
of
this
approach
with
chaos.
Engineering
is
a
really
cool
thing,
so
we're
working
with
litmus
and
others
out
there.
A
So
if
you
have
a
safe
environment
or
a
test
environment
where
you
can
run
chaos
experiments
the
first
thing
is
it
validates
your
monitoring
and
alerting,
but
then
you
can
use
captain
to
also
define
test
and
and
kind
of
strengthen
your
all
the
remediation
scripts.
So
this
is
really
a
way
to
do
test
driven
auto
remediation,
because
you
want
to
make
sure
that
if
you
enforce
chaos
in
the
environment,
that
your
system
is
not
only
detecting
it,
but
can
also
react
to
it.
A
So
in
case
this
problem
ever
happens
in
production,
you
already
know
you
have
tested
this
remediation
script.
I
think
this
is
what
we
also
want
to
propose
here.
I
think
this
is
a
cool
thing,
all
right,
so
to
wrap
it
up.
Hopefully,
by
now
you
know
what
captain
is
it's
an
event:
driven
control
plan
for
continuous
delivery
and
automate
operations.
A
A
We
are
addressing
these
three
problems
and
probably
some
more,
but
these
are
the
three
problems
that
I
have
shown
you
today
about
modern
delivery.
Essentially,
waste
spend
saving
a
lot
of
time
that
is
otherwise
manually
done
and
if
you
are
interested
in
more
go
to
tutorials.captain.sh
where
you
can
get
started
now,
I'm
ready
for
q
a
hi
there.
A
Hopefully
my
talk
gave
you
a
couple
of
new
ideas
on
what's
possible,
with
an
event-driven
approach
to
delivery.
Now
I
assume
with
captain
we're
not
the
only
ones
that
are
following
that
path,
but
hopefully
we,
you
know,
give
you
some
new
ideas
and
an
option
in
case
you're,
looking
into
a
new
way
of
delivery
and
yeah.
If
there
are
any
questions,
I
would
be
very
happy
to
take
them.
A
I
am
sitting
here
in
linds
austria,
so
if
you
have
any
questions
which,
if
all
of
you
had
the
chance
to
see
the
full
presentation,
so
captain
is
a
cncf
sandbox
project.
Atlanta
welcome-
and
you
know,
check
us
out
on
captain.sh
is
the
website
on
github.
You
can
find
us
on
github.com
captain
and
captain
spelled
ke
ptn.
A
We
really
believe
that,
with
the
approach
we
took
of
you
know
doing
an
event-driven
workflow,
but
giving
you
the
chance
to
take
individual
workflows
or
individual
parts
like
just
the
quality
gates,
allows
you
to
easily
adapt
parts
of
it
around
the
content.
With
questions
later,
probably
perfect.
If
you
have
questions
later
on,
we
also
have
a
slack.
So
we
are
both
on
the
cncf
slack,
there's
a
captain
channel,
but
we
also
have
our
own
captain
slack.
You
can
join
it
on
slack.captain.sh.
A
Where
does
the
name
come
from?
So
captain
spelled
ke
ptn
everything
in
kubernetes,
as
you
know,
is
nordic,
has
nordic
terms
and
captain
is
a
captain
of
a
ship
now.
The
way
we
spell
it
is
the
german
phonetic
version
of
a
captain,
so
kptn
most
of
the
contributors
to
that
open
source
project
come
from
the
german-speaking
region
of
europe,
and
I
guess
yeah,
I
think
I'm
still
here,
but
somebody
just
left.
A
A
Now,
what
we're
doing
in
upcoming
versions
is
where
we
allow
you
to
really
separate
the
control
plane
from
the
execution
plane,
meaning
you
can
install
the
different
captain
services
like
the
helm,
deployment,
spinnaker
integration,
whatever
you
want
into
other
kubernetes
clusters.
So
that's
one
thing.
The
other
thing
that
I'm
excited
about
is
the
next
version
of
the
shipyard
shipyard.
Remember
that's
the
way
how
we
define
the
process
of
what
should
happen
in
which
stage
meaning
what
type
of
deployment
or
type
of
testing
and
what
type
of
remediation.
A
So
it's
really
like
right
now,
a
very
opinionated
way
what
happens
within
a
stage
what
we're
doing
in
the
next
version
of
shipyard
is
where
we
allow
you
to
define
your
own
set
of
actions
and
your
own
workflow
within
a
stage
so
you're
no
longer
just
like
you
know,
constrained
with
our
opinionated
way,
but
you
can
say
before
deploy
you
want
to
do
something
else
between
deploy
and
testing.
You
want
to
do
something
else,
so
you
can
really
define
your
own
process
steps
within
what
happens
within
a
stage.
A
I
think
that's
also
important,
there's
also
stuff.
We
learned
from
feedback
another
cool
thing
that
is
coming
with
o7
0.7.2.
I
believe
that's
when
they're
implementing
it
is
for
the
quality
gates
right
now,
as
you
have
seen,
quality
gates.
Basically,
you
pull
data
back.
We
pull
data
back
from
your
sli
providers,
but
what,
if
you
had
a
bad
deployment,
a
bad
test
right
now,
there's
no
way
to
invalidate
quality
gate
results
so
that
they
should
be
ignored
for
the
future,
because
again,
maybe
something
that
happened
in
the
environment.
A
So
this
is
coming,
there's
a
good
issue
that
the
team
is
already
working
on
it,
where
you
can
invalidate
individual
results
right,
which
makes
a
lot
of
sense
if
you
had
a
bad
run,
and
you
don't
want
that
to
kind
of
mess
up
your
your
your
heat
map,
view
or
also
impact
the
calculation
of
future
quality
gate
runs.
So
that's
also
coming
there's
also
a
cool,
a
lot
of
cool
improvements,
ui
improvements
coming
into
the
bridge.
A
So
that's
these
are
kind
of.
I
think
my
my
my
highlights
that
I'm
looking
for
and
then
more
and
more
integrations
that
people
build.
I
know
that
somebody's
currently
building
an
sli
provider
for
for
wavefront
we
have
people
working
on
integrations
from
a
testing
perspective
with
a
load
runner
and
I
think
source
labs.
If
I'm
not
mistaken,
so
there's
going
to
be
more
and
more
tools
that
are
being
integrated
through
captain
service
same
as
curious,
which
tools
do
you
use
for
chaos,
engineering
other
than
litmus?
So
we
are.
A
We
have
the
first
litmus
integration
already,
I
think
out
there
on
the
captain.
Community
we've
also
worked
with
gremlin,
so
they
have
also
shown
and
committed
that
they
are
going
to
build
an
integration
with
captain
where
the
idea
is
that,
as
I
explained
in
the
presentation,
captain
can
then
trigger
a
chaos
experiment,
while
your
tests
are
running
while
you're
putting
some
load
on
there
on
the
system.