►
From YouTube: Introduction to Keptn (Part II) | Rawkode Live
Description
In this episode, we will continue with our look into Keptn; including automatic remediation.
This episode is part of the Guide to Keptn series.
-- Introduction to Keptn (Part I) - https://youtu.be/fjfj97Vb4ds
-- Introduction to Keptn (Part II) - This Video
🍿 Rawkode Live
Hosted by David McKay / 🐦 https://twitter.com/rawkode
Website: https://rawkode.live
Discord Chat: https://rawkode.live/chat
#RawkodeLive
🕰 Timeline
00:00 - Holding Screen
00:37 - Introductions
03:15 - Overview of Part I (Slides)
16:30 - Quality Gates for Continuous Delivery
53:00 - Automatic Remediation
👥 About the Guests
Jürgen Etzlstorfer
Jürgen is a maintainer of the Keptn open-source project since its beginning. He also takes care of its community and ecosystem and loves to welcome new contributors. Join him! :)
🐦 https://twitter.com/jetzlstorfer
🧩 https://github.com/jetzlstorfer
🔨 About the Technologies
Keptn
Keptn is a control-plane for DevOps automation of cloud-native applications. Keptn uses a declarative approach to build scalable automation for delivery and operations which can be scaled to a large number of services.
🌏 https://keptn.sh
🐦 https://twitter.com/keptnProject
🧩 https://github.com/keptn/keptn
A
Hello
and
welcome
to
today's
episode
of
rockhold
live.
I
am
your
host
raw
code
today,
we're
going
to
be
taking
a
look
at
the
captain
project.
We
have
done
an
episode
in
this
previously,
where
we
looked
at
using
captain
for
a
continuous
delivery,
with
some
really
cool
corrections
inside
that
help
gate
and
protect
your
deployments
from
errors
and
bugs
today,
I'm
going
to
be
joined
by
jurgen
once
more
jurgen
is
an
engineer
at
diner
trace
and
a
maintainer
of
the
captain
project.
Hello,
jurgen,
welcome
back.
B
Sure,
thank
you.
So
my
name
is
jurgen.
I'm
one
of
the
captain
maintainers.
I
think
we've
started
this
project
around
two
years
ago.
It
was
originating
from
more
an
idea
of
how
we
can
make
continuous
delivery
and
operating
software
better.
It
was
the
whole
idea
was
about
automating
a
lot
of
steps
and
then
we
first
found
we
built
kind
of
a
methodology,
and
then
we
from
this
we
built
the
whole
captain
project.
So
it's
been
around
for
some
time.
It
was
initially
started
by
dynatrace.
B
It's
now
a
open
source,
cncf
project.
We
are
in
the
sandbox
phase
of
the
cncf
and
yeah
in
the
beginning.
I
was
also
one
of
the
main
developers
right
now,
I'm
more
taking
a
look
at
the
captain
ecosystem
how
we
can
integrate
with
other
tools.
We
just
built
the
litmus
integration
recently
we're
building
a
locust
integration.
We
have
other
integrations
for
different
testing
tools,
automation
tools,
deployment
tools,
so
this
is
what
what
I
care
about
these
days
and
I'm
pretty
excited.
A
Okay,
awesome
yeah.
I
think
what
I
what
I
realized
last
time
when
we
were
looking
at
this
project,
is
that
it
really
is
like
the
one
complete
tool
for
implementing
continuous
delivery.
There
was
a
lot
of
different
components,
a
lot
of
different
features
that
we
can.
You
know,
adopt
and
and
leverage
inside
of
our
kubernetes
environments,
and
we
only
got
halfway
through
the
tutorial.
So
today
we're
gonna,
try
and
take
a
look
at
the
rest
of
that
tutorial
and
other
features
that
captain
brings
to
the
table.
B
Cool
yes,
so
I
just
want
to
share
a
little
bit
of.
Let
me
just
am
I
already
in
presenting
mode,
I'm
not
sure
I
think
now
I
am
yep
there.
You
go
okay,
perfect,
so
I
just
want
to
give
you
again
a
brief
overview
of
captain
and
what
we
did
already
last
time
and
what
we
are
going
to
see
today.
So
it's
a
captain
itself
is
the
cloud
native
application
life
cycle
orchestration,
so
you
can.
B
B
Last
time,
I
think
we
already
covered
the
part
why
we
did
it.
It's
a
lot
of
the
main
part
is
really
automation
and
making
your
continuous
delivery
more
robust
and
also
giving
you
guidance
and
framework
for
automated
remediations
and
last
time
we
already
did
a
couple
of
the
first
two
use
cases.
So
we
took
a
look
at
how
to
automatically
configure
observability
and
dashboarding
tools.
We
were
using
last
time
already
promethouse.
B
We
will
do
this
also,
today,
it's
we
we've
been
using
two
major
concepts
and
two
major
files
of
captain.
The
first
one
is
the
environment
definition.
We
call
it
the
shipyard
file
and
I
am
from
austria.
We
speak
german
here.
Captain
for
us
sounds
like
the
captain
of
a
ship.
So
it's
really.
We
have
a
shipyard
file.
We
have
a
captain's
uniform,
which
defines
the
tooling
that
you
need
or
that
you
want
to
use.
B
We
have
a
a
lot
of
things
in
in
captive.
We
have
the
captain's
bridge,
for
example,
which
is
our
ui
a
lot
of
things.
They
have
like
these
nautical
terms
and
then
this
this
idea
behind
it.
Our
tagline
still
is
nobody.
Ships
apps,
like
the
captain,
so
it's
yeah.
We
we
like
this
theme,
so
the
shipyard
file
is
basically
describing
your
environment
and
just
with
a
couple
of
lines,
you
can
describe
a
multi-stage
environment,
and
this
multi-stage
environment
basically
also
reflects
a
multi-stage
delivery
pipeline
between
the
stages.
B
Captain
automatically
executes
a
quality
gate,
and
this
quality
gate
can
be
based
on
slos,
as
we
can
also
see
here.
But
these
slos
service
level
objectives
can
also
be
used
for
configuring
and
setting
up
your
alerting
and
your
dashboarding
and
your
observability
tools.
So,
for
example,
we
can
use
the
slos
to
configure
the
prometheus
alert
manager
to
set
up
grafana
and
also
have
alerts
in
grafana
and
just
in
general,
scrape
jobs
rules
also
what
we
can
do
with
this
slo
file.
As
I
already
said,
it's
the
definition
for
our
multi-stage
delivery.
B
We
will
see
a
little
bit
of
this.
Also
in
today's
presentation.
We
saw
this
also.
Last
time
we
went
in
more
detail
last
time.
I
know
that
david
has
already
prepared
a
couple
of
things
for
today,
so
we
can
kind
of
have
the
we
have
everything
that
we
did
last
time.
We
just
continue,
so
we
will
see
a
little
bit
of
this
also,
and
I
will
just
explaining
as
we
go
through
it.
B
The
new
part
that
we
will
see
is
actually
more
in
the
remediation
part,
but
just
as
a
reminder
how
accepting
quality
gates
is
is
working.
We
are
based
on
two
concepts
coming
more
or
less
from
the
sre
community.
So
if
you've,
if
you're
familiar
with
the
sre
book
from
google
or
if
you
are
interested
in
this
book,
it's
a
great
book
and
they
are
promoting
two
concepts
there,
the
one
is
the
slis
and
which
is
for
service
level
indicator
and
service
level,
objective
short
slo.
B
These
are
the
one
of
the
major
concepts
there,
so
the
first
one
is
basically
an
indicator
is
something
like
a
metric.
You
can
think
of
a
metric,
so
in
captain
you
can
define,
I
would
call
it
the
library
or
a
list
of
indicators
and
you
map
the
name
of
the
indicator
to
a
prom
ql.
So
then
you
can
reuse.
The
name
of
the
indicator
in
your
slo
file
and
the
slo
file
defines
an
objective
for
an
indicator.
So,
for
example,
the
error
rate
has
to
stay
lower
or
equal
to
one
percent.
B
So
in
this
case
we
can
easily
define
the
error
rate
and
in
the
slo
file
we
do
not
define
where
the
data
is
coming
from.
So
whenever
we
want
to
change
how
we
retrieve
the
data,
maybe
we
want
to
change
from
one
tool
to
the
other.
Maybe
we
just
have
to
to
clarify
the
granularity
of
the
data.
We
can
do
this
in
the
indicator
file.
We
don't
have
to
change
our
quality
gate
definition,
and
it's
not
that
we
only
care
about
one
objective
and
one
sli,
but
we
can
mix
and
match
different
slis.
B
We
can
have
absolute
thresholds.
We
can
have
relative
thresholds
that
will
be
then
compared
to
previous
runs.
For
example,
the
number
of
database
calls
is
allowed
to
increase
by
2
to
the
previous
runs,
but
it
also
should
stay
within
10
database
calls
per
transaction,
so
there
are
different
ways
to
define
this
quality
gate
and
whenever
it's
triggered
by
either
by
an
external
tool
or
within
the
captain,
continuous
delivery
workflow
here
this
is
just
an
example
to
to
trigger
it.
B
With
the
captain
cli,
then
captain
will
reach
out
to
the
different
observability
tools
and
data
providers
will
query
all
this
data
based
on
the
service
level
indicators
and
will
then
score
the
service
level
indicators
whenever
each
time
it's
a
full
pass
of
the
criteria.
You
will
get
a
full
point
if
it's
not
a
full
pass,
but
it's
still
inside
a
warning
criteria.
You
will
get
half
the
points
and
then
in
total
captain
will
come
up
with
a
score
and
this
core.
B
You
can
then
use
to
decide
if
it
should
be
promoted
to
the
next
stage.
If
you
want
to
keep
it
in
this
stage,
you
want
to
roll
it
back.
This
is
then,
if
you're,
just
using
captain
quality
gates,
it's
totally
up
to
you.
If
you're
using
captain,
I
would
say,
like
the
full
installation
of
captain
captain-
can
automatically
initiate
a
roll
back,
for
example,
of
of
this
deployment,
and
we
can
also
use
the
same
file
to
configure
our
alerting
and
then
react
on
our
on
problems
or
alerts
that
are
coming
in.
B
So
an
alert,
for
example,
sent
from
the
prometheus
alert
manager
can
be
then
consumed
by
captain,
and
if
there
are
some
remediation
actions
defined
and
added
to
captain
captain
can
trigger
this
evaluation.
These
remediation
actions
can
again
evaluate
if
the
action
was
actually
successful,
based
again
on
the
slo
file
and
then
either
execute
the
next
action
or
close
close
the
issue.
B
B
Whatever
and
again,
if
you
might
remember
from
last
time,
captain
is
based
on
on
a
git
approach.
So
all
the
configuration
files
are
stored
in
its
internal
git
repository
or
on
github
or
gitlab
or
bitbucket,
where,
wherever
you
want
to
use
it,
and
it
will
store
its
configuration
files
in
this
git
repository.
So
it
will
also
take
a
look
in
the
git
repository.
If
there
is
some
kind
of
remediation
configuration.
B
B
B
So
this
is
actually
what
we're
going
to
look
at
today.
I
think
we'll
start,
maybe
with
the
quality
gate,
since
we
already
have
up
and
running
working
environment.
I
I'm
not
going
into
the
architecture
right
now.
Maybe
if
we
have
time
in
between,
I
can
always
come
back
to
this
and
show
a
little
bit
of
the
architecture.
A
Cool
so
now
we
let's
get
my
screen
up
then,
so
what
I
want
to
do
is
just
go
over.
What
I
prepared
in
advance
make
sure
that
we're
on
the
same
page
there.
I
really
hope
I've
not
messed
it
up,
which
has
you
know,
only
happened
nine
out
of
ten
times
on
this
show.
So
it's
green,
and
we
also
have
a
hello
comment:
hey
philip
from
berlin,
thanks
for
joining
us,
so
hi
phillip,
I
just
my
calendar
just
chilling
there
don't
know
why.
A
A
B
Yes,
I
believe
we
have
two
different
or
even
three
namespaces
stock
shop
depth
production
staging.
So
that's
also
one
thing
so
captain
is
in
the
current
version.
We
are
kind
of
making
the
distinction
between
environments
by
namespace.
We
are
already
working
on
this,
making
this
distinction
between
environments
also
per
cluster.
So
in
the
future,
with
the
next
release
of
captain,
it
will
be
possible
to
have
a
multi-cluster
setup
and
move
and
have
a
dedicated,
let's
say
staging
cluster
and
a
dedicated
production
cluster
right
now
is
separated
by
namespaces.
A
Nice,
I
think
that
would
be
a
very
welcomed
addition.
I
think,
from
the
people
that
I
speak
to
there,
there's
a
lot
of
growing
support
for
the
multi-cluster
setup.
Definitely
so
that's
nice
to
hear
okay.
So
how
do
we-
oh
yeah,
in
this
repository,
the
captain
repository-
is
available
online.
This
is
what
we're
continuously
right
into
when
we
make
changes
and
we
have
the
captain's
bridge
available
too
so
perfect.
A
B
Yes,
so
in
your
preparation,
also
in
the
last
episode,
what
we
already
did
was
deploying
in
a
multi-stage
environment,
deploying
the
shopping
cart
of
our
sock
shop
application.
So
we
were
deploying
this.
It
went
through
dev
staging
all
the
way
through
production,
and
now
we
we
are
adding
slo
files,
a
quality
gate
definition
file
and
we
trigger
another
build
or
actually
and
we
trigger
another
deployment
with
already
pre-built
image,
and
we
will
see
how
captain
will
prevent
it.
Moving
to
production.
A
B
B
The
screen
is
a
little
bit
blurry
on
my
end,
so
I'm
not
sure
if
I
can,
if
I'm
a
bit
behind,
but
in
the
git
repository
we
should
see
in
the
staging
branch
we
should
see
in,
there
will
be
a
prometheus
folder
and
all
the
configuration
files
that
are
responsible
for
prometheus
should
be
there,
and
we
should
be
able
to
see
the
sli
definition
if
it's
not
there.
We
just
execute
this
command
and
captain
will
upload
prometheus
sli
configuration
into
the
parameters.
Folder.
B
Yeah
all
good
here,
so
that's
basically
the
definition:
how
to
query
different
different
metrics
from
prometheus.
In
this
case,
it's
a
lot
about
the
response,
it's
all
about
the
response
time,
but
you
could
add
error
rate
throughput
memory,
consumption,
cpu
saturation,
whatever
you
want
to
add
here
with
your
prom
ql
or
captain,
comes
with
a
couple
of
predefined
metrics
that
you
could
also
reuse
in
this
case,
we're
just
making
it
clear
how
the
concept
of
sli
is
actually
working.
So
we
just
define
our
own
sli,
putting
it
into
our
git
repository.
A
A
B
A
A
There
we
go,
and
so
we've
now
added
the
resource
that
has
this
slo
file.
Let's
see
if
I
can
work
out
what
this
is
doing,
so
it
adds
a
it's
got,
a
comparison
key
which
has
an
aggregate
function.
It
could
pair
with
an
included
result
and
a
number
of
comparison
results.
Do
you
want
to?
Maybe
just
tell
us
roughly
what
this
is.
Slo
is
doing.
B
Yeah
sure
so
it's
basically
the
definition
of
the
quality
gate
defining
how
we
want
to
evaluate
it
and
how
we
want
to
compare
it.
So
we
are
comparing
to
the
previous
result,
just
a
single
result,
and
we
only
comparing
it
to
previous
results
that
passed.
So
if
we
have
a
quality
gate
that
failed
and
another
one
is
also
failing
and
we're
just
comparing
it
to
the
previous
failing
one,
and
we
have,
for
example,
relative
thresholds.
B
We
would
not
get
really
good
numbers
because
we
would
compare
the
failing
error
rate
to
another,
failing
error
rate
and
we
would
maybe
allow
it
to
pass
so
we
in
this
era,
in
this
quality
gate,
we
only
want
to
compare
it
to
previously
passed
results
and
for
if
we
are
using
more
than
one
result,
we
would
do
the
aggregate
function.
We
would
just
do
an
average.
So
we
are
not
taking
the
minimum
or
maximum
of
the
error
rate
of
previous
runs,
but
we
would
we
would
take
the
average.
B
B
And
then
we
have
a
couple
of
objectives
and
these
objectives
are
defined
on
slis
and
actually
in
this
case
we
only
have
one
sli,
which
is
the
response
time
in
the
95th
percentile,
it's
defined
in
the
sli
file
that
we
just
that
david
just
showed
you-
and
here
it
says
key
sli
is
false.
That
means,
if,
if
a
key
sli
is
true,
then
the
captain
quality
gate
fails.
If
only
this
one
single
evaluation
fails.
B
So
if
you
have
50
slis,
but
one
is
very
crucial
that,
with
the
key,
cli
or
five
are
very
crucial,
we
all
otherwise
they
are
weighted
with
the
same
weight.
You
can
also
change
this
with
the
weight
key
here
and
then
we
have
the
the
passive
warning
criteria
with
the
combination
of
relative
and
absolute
thresholds.
So
it's
allowed
to
pass
if
it's
faster
than
600
milliseconds
and
if
the
increase
to
the
previous
run
that
also
passed
is
below
the
10
percent.
A
A
A
B
B
B
Can
we
take
a
look
at
the
staging
here,
so
it
was
not
moved
to
production
because
the
quality
gate
was
failing.
So
actually
we
have
to
prove
that
is
already
working.
So
it's
not
the
quality
gate
that
we
set
up
right
now,
but
it's
actually.
I
assume
the
quality
gate
that
you
set
up
yesterday
for
the
preparation
for
today.
So
we
can
take
a
look
and
at
the
carts,
probably
clicking
on
the
quality
gate
here,
will
give
us
a
little
bit
more
detail.
A
B
Kind
of
kind
of
yeah,
so
we
did
not
get
any.
Let
me
just
get
the
light
here,
so
it
says
the
response
time
was
actually
failing
here,
so
it
was
probably
too
slow
to
or
the
response
time
was
was
not
satisfying.
So
let
us
just
do
another
deployment,
probably
with
the
same
version.
Maybe
there
was
some.
Maybe
there
was
too
much
traffic
on
the
cluster
or
it
was
not
coming
up.
A
B
A
B
And
what
it
does
is,
basically,
it's
sending
a
cloud
event
to
captain,
so
it's
building
a
cloud
event
and
sending
this
cloud
event
to
the
captain
control
plane
and
it
tells
captain
there
is
a
new
image
of
of
our
service
carts
of
our
project
sock
shop.
So
that's
the
project
sock
shop
in
the
service
carts
was
previously
onboarded
to
captain
david
has
done
this
in
the
preparation
and
also
in
the
last
episode.
B
B
Defined
capture
will
start
to
deploy
it
first
in
the
in
the
first
stage
of
this
delivery
file,
and
in
our
case
it's
called
def.
So
it's
start
to
upgrade
the
helm,
charts
release
version
in
our
def
environment.
We'll
then
apply
this
helm
chart.
It
will
also
apply
this.
The
changes
to
the
git
repository
in
this
case.
B
It
might
take
a
couple
of
seconds
since
it
also
waits
if
the
deployment
is
actually
finished,
the
basically
a
helm
upgrade
if
it's
finished
and
our
I
think
it's
the
the
readiness
probe
takes
about
30
seconds
50
seconds
something
like
this
to
for
for
the
pot
to
be
ready.
So
it
just
takes
a
couple
of
seconds
and
then
captain
will
tell
you
it's
finished
upgrading
the
chart
and
it's
already
deployed
in
the
first
version
or
in
the
in
the
first
environment,
yeah.
A
B
Yes,
we
can
take
a
look
here
in
in
services,
so
we
have
the
environment,
we
can
see
all
the
different
stages,
but
in
services
we
can
see
all
the
different
services
that
we
have
already
onboarded
and
we
could
see.
For
example,
yesterday
there
was
the
quality
gate
was
failing
and
we
can
see
the
the
current
run.
The
last
configuration
changed
so
configuration
changed.
Here
means
we
changed
either
the
image
or
we
changed,
the
load
distribution.
B
B
There
are
a
couple
of
approval
events,
but
we
set
the
approval
to
automatically
so
whenever
there
is
a
quality
gate,
which
is
if
there
is
no
quality
gate
or
the
quality
gate
is
passing,
there
will
be
an
automatic
approval
so
for
between
dev
and
staging.
We
just
allow
it
to
pass.
Basically,
and
now
it
says
there,
it
changed
the
configuration.
So
it's
basically
triggering
the
deployment.
The
next
event
will
be
once
the
deployment
is
finished
and
once
the
deployment
is
finished,
captain
will
trigger
the
tests.
B
That's
right
now,
I
have
to
admit
the
small
hiccup
in
the
captain's
bridge,
because
it's
not
indicating
that
right
now
tests
are
executed
so
also
in
the
last
episode.
What
we've
done
is
we
have
added
some
jmeter
tests
and
also
here
gmeta
tests
are
added
and
they
are
automatically
triggered
by
captain
again
with
the
same
approach.
B
B
They
might
take
about
two
minutes
to
finish.
They
are,
I
think,
5
000
requests
are
sent
to
the
to
some
endpoint
of
our
shopping
cart
and
once
the
tests
are
finished,
jmeter
will
send
back
a
cloud
event
to
to
the
captain
control
plane.
Forming
captain
tests
are
not
finished.
Please
go
ahead
with
the
next
phase,
whatever
the
next
phase
is,
and
the
next
phase
is
our
evaluation.
So
we
can
see
tests
are
finished
for
the
evaluation
we
we
are
doing.
B
We
will
retrieving
data
from
prometheus,
so
we
can
see
data
retrieval
and
we
can
see
it's
not
actually
failed.
It's
not
working
yeah,
it's
it's
failing!
So
let
us
take
a
look
at
the
response
time.
P95
at
the
icon,
there
was
a
red
icon
that
should
give
us
a
little
bit
of
indication.
Why
it's
failing
yes
here
so.
B
So
there
should
be
all
right:
okay,
there
is
no
prometheus
here.
So
no
worry.
What
we
can
do
is
we
can
configure
prometheus
with
captain
and
actually,
I
think,
in
step
number
13.
There
is
some
promethouse
information,
so
we
are
here
in
again
in
this
version
of
captain
we
are,
a
captain
is
managing
the
prometheus
installation.
So
with
the
first,
with
with
this
command,
we
are
adding
the
prometheus
service
to
captain,
which
is
also
responsible
for
configuring,
the
promethouse
and
with.
B
B
But
prometheus
itself
is
might
not
be
running,
so
there
is
another
command
for
captain
configure
promethos
and
this
one
we
need.
That's
also
setting
up
the
setting
up
prometha
setting
up
the
alert
manager
setting
up
the
slo,
setting
up
the
scrape
chops,
all
based
on
the
sli
file,
the
slo
file
and
the
the
shipyard
file.
A
B
The
prometheus
sli
server
is
living
in
the
captain.
Namespace
same
is
true
for
the
prometheus
service,
which
is
responsible
to
reach
out
to
prometheus
and
configure
this
prometheus
instance.
So
those
have
not
been
changed
and
you
those
have
been
running
in
the
captain
namespace
since
18
hours,
but
prometheus
itself
was
not
yet
started.
B
We
it's
only
triggered
when
you
do
a
captain,
configure
monitoring
and
then
you
can
provide
the
name
of
the
different
monitoring
solutions.
Captain
configure
monitoring
promethos
will
then
kick
off,
send
a
cloud
event
to
the
prometheus
service
which
will
forward
it
to
prometheus.
So
only
with
this,
you
will
start
actually
the
promethos.
A
B
A
Yeah
yeah,
you
know
it's
nice,
seeing
the
the
bridge
and
showing
you
how
this
failed
and
then
even
getting
that
error
to
say.
Oh,
we
had
no
previous,
like
we
didn't
actually
really
have
to
debug
anything
there.
We
just
had
to
go.
Oh
this,
we
don't
have
what
we
expect.
I
missed
a
command,
we
run
the
command
and
now
we
should
see
less
work
through
properly.
Hopefully
this
time
so
nice.
B
A
B
Yes,
most
of
the
time
is
spent
on
the
actual
deployment
and
then
the
the
the
execution
of
the
tests
in
depth.
It's
not
a
lot
of
tests.
We
just
ping.
If
there
is
something,
if
the
end
point
is
available
in
staging,
we
do
a
little
bit.
We
actually
execute
a
little
bit
more,
but
it
will
should
come
up
just
in
a
second.
A
B
B
Maybe
just
wait
wait
for
this.
We
will
wait
for
this.
To
finish,
also,
the
same
is
true.
Here
we
are
moving
the
one
version.
It's
right
now,
it's
the
same
version,
but
we're
moving
one
version
as
a
blue
or
green
version
into
staging
we're
executing
the
tests
against
this
version,
and
then
we
are
executing
and
triggering
the
cap
to
qualificate.
B
A
A
B
Exactly
and
for
this
automated
approval,
yeah
deployment
finished
so
now
the
tests
will
be
executed
for
disapproval.
That's
also
quite
nice.
Here
we
have
it
automated
just
for,
for
the
sake
of
the
demo,
that
we
don't
have
to
to
click
here
and
wait,
but
our
friends
from
citrix
they
have
built
an
integration
to
captain
with
a
slack
bot.
B
So
whenever
there's
an
open
approval,
they
get
this
mesh
message
directly
in
the
slack
and
can
click
either
accept
or
reject,
and
they
will
also
get
the
all
the
data
from
the
quality
evaluation
from
the
previous
stage.
So
they
will
see
what
is
the
quality
of
the
service
and
then
based
on
this,
they
can
make
the
decision
and
they
are,
they
don't
have
to
leave
slack.
They
just
work
in
slack.
A
All
of
the
above,
to
be
honest,
so
yeah
that
I
can
see
there's
a
lot
of
value
in
that
I
know
you
know
getting
those
kind
of
information.
You
know
we're
all
using
slack
these
days
right.
It's.
We
spend
a
lot
of
our
time
there,
communicating
with
our
colleagues
I've
not
on
zoom,
so
it's
nice
that
it
has
that
integration
and
we
can
see
the
performance
results
and
improve
it
directly
from
slack.
I
can
see
a
lot
of
value
there.
A
B
A
B
Yeah,
sometimes,
for
sometimes
you
just
want
to
deploy
something
we
actually
what
we
see
with
with
feature
flags.
It's
the
same
that
you
have
the
feature
flags.
You
cannot
test
all
the
combination
of
your
feature,
flags
in
pre-prod
or
hardening
staging
whatever
you
call
it.
So
it's
basically,
your
customers
are
your
your
testers,
and
this
is
one
of
the
ideas
that
we
also
built
into
captain
with
combining
feature
we
can.
B
B
We
also
have
integrations
in,
I
think
it's
azure
devops,
where
we
just
one
one
guy
from
the
captain
community
with
the
name
bear
panda
he's
from
the
netherlands
and
or
from
belgium,
I'm
not
yet
sure,
but
what
he
what
he
did
is.
He
was
building
an
integration
into
azure
devops,
where
the
whole
quality
gate
part
is
captain
and
the
whole
other
part
with
the
delivery
is
azure
devops.
So
you
can
think
of
this
that
you
can
just
use
parts
of
captain
in
your
existing
environment.
A
You
know
codify
their
sls
and
our
slos
and
that's
what
what
captain
is
doing
here
like
we
have
this
yaml
syntax,
that's,
hopefully
intuitive
and
easy
for
people
to
pick
up
and
then
commit
that
to
get
and
then
have
all
of
these
checks
built
around
that
automated.
For
them
such
a
powerful
set
of
tools.
A
B
A
B
What
we
should
already
see
is
how
it's
deployed
into
depth,
you
know
into
our
deaf
environment.
So
if
you
can
open
up
the
deaf
environment
again,
we
should
already
see
the
yeah
that's
kind
of
the
broken
version
indicated
by
the
red
background
kind
of
yeah
obvious
in
staging.
It
should
also
be
deployed
already.
I
think
it
says
in
the
in
the
bridge
that
was
deployed,
but
not
sure.
B
It's
about
to
be
deployed,
but
traffic
has
not
been
shifted
yet
to
the
to
the
new
version
it
will
be.
We
will
get
the
information
here
in
the
bridge.
Once
traffic
is
shifted
and
deployment
has
finished,
then
we
will
be
able
to
see
this
version
also
in
in
the
browser,
and
it
will
be
there.
I
can
already
spoil
a
little
bit
here.
It
will
be
there
for
a
couple
of
minutes.
B
While
the
tests
are
running
and
after
the
tests,
we
will
have
another
evaluation
of
the
captain
quality
gate,
and
so
here
we
are
and
the
captain
quality
gate.
If
it's
failing
it
will
roll
it
back
to
version
number
one
to
the
green
version.
If
it's
not
failing
the
captain
quality
gate,
then
we
will
keep
this
version
here
and
we
will
move
it
also
to
production.
So
hopefully
we
don't
move
this
version
to
production,
it's
it's
kind
of
the
the
slow
version.
B
A
B
Yeah
we
can
talk
about
our
next
steps.
We
don't
have
to
execute
it
already,
but
this
is
what
we
will
see.
It
will
not
be
promoted
to
the
next
stage
because
of
the
blocking
quality
gate
and
again
in
the
demo.
The
quality
gate
is
very,
very
simple.
We
just
care
about
the
response
time
in
this
demo,
but
again
you
can
build
your
quality
gates
having
all
different
kinds
of
metrics
and
data
in
it.
B
For
example,
you
most
often
you
want
to
care
about
the
error
rate,
so
you
want
to
make
sure
that
errors
are
below.
I
don't
know
two
percent
or
not
increasing
by
more
than
five
percent
to
the
previous
runs.
You
want
to
make
sure
that
throughput
is
high.
You
want
to
make
sure
that
the
response
time
is
low.
So
all
of
these
things
you
can
build
in
your
captain
quality
gates
and
if
you
don't
know
the
exact
values
yet,
then
we
see
a
lot
of
captain
customers
or
captain
users.
B
B
A
Okay,
can
I
ask
a
question,
I'm
overwhelmed
so
assume.
We
know
that
that's
broken,
you
know,
maybe
we're
just
adopting
captain
and
we,
you
know
the
automation
is
really
cool
but
at
the
same
time
we're
still
checking
the
metrics
ourselves
manually
during
the
plays
like
what
happens.
If
I
trigger
this
new
artifact
now
well
we're
still
in
the
middle
of
another,
currently
processing
deployment.
Does
it
get
queued
up
afterwards?
Does
it
start
to
roll
out
to
dev
just
now
what
would
go
on
there.
B
So
in
the
current
version
of
captain,
this
is
actually
a
problem
because
it
you
would
just
kick
off
another
workflow,
it
will
move
it
to
def
and
it
will
also
move
it
to
to
staging
so
right
now
there
is
no
blocking
mechanism.
This
is
also
what
we're
going
to
fix
in
the
next
version.
The
the
reason
why
it's
it
was
built
like
this
is
that
actually,
most
of
the
time
the
artifacts
are
coming
out
from
some
kind
of
ci
system
and
after
the
ci
system
you
decide.
B
Is
it
a
version
that
I
really
want
to
deploy
into
dev
or
staging
or
whatever?
Is
it?
Is
it
the
version
that
I
already
want
to
deploy,
or
was
it
just
a
like
a
test
build,
and
once
you
decide
you
want
to
deploy
this
version,
there
should
be
kind
of
a
blocking
mechanism
that
you
cannot
deploy
anything
into
staging
where
it's
currently
deployments
going
on
or
tests
going
on.
But
in
this
version
you
would
it
would
not
be
blocked
by
captain.
So
in
the
current
version.
A
Okay,
so
do
you
see
like
going
back
to
the
currently,
we
are
using
captain
in
a
a
multi-name
space
approach,
so
we
have
a
namespace
for
dev,
a
name
space
for
staging
and
a
name
space
for
production.
But
you
also
set
that
you
know
in
the
next
version.
We
can
expect
to
be
able
to
have
a
dev
cluster
stage
cluster,
a
production
cluster.
Do
you
see
captain
as
something
that
runs
on
like
a
management
control,
plane,
cluster
outside
of
those
other
clusters
or
with
captain
running
my
dev
cluster
and
then
promote
to
other
clusters
like?
B
That's
a
good
question.
I
I
think
it
really
depends
on
the
use
case
where
we
also
see
that
captain
is
just
running
on
the
keys
inside
k3s
on
the
keys
insulation,
where
you
just
run
the
captain
control
plane
on
the
on
on
a
small
kubernetes
distribution.
You
don't
want
to
run
a
full
kubernetes
cluster
because
you're
only
using
parts
of
captain,
so
you
run
it
on
a
small
kubernetes
distribution.
B
If
you're
going
full
captain,
then
you
might
want
to
run
it
on
a
stable
environment,
maybe
not
in
the
deaf
environment,
because
if
it's
one
that
you
tear
down
and
recreate
a
couple
of
times,
you
don't
want
to
have
to
install
captain
all
the
time
again,
so
that
might
be
living
in
a
more
production
related
cluster,
the
captain
control
plane.
And
then
you
still
have
captain
services
running
on
different
clusters
because
they
have
to
be
able
to
execute
some
actions
on
these
clusters.
A
B
A
Yeah,
I
think
that's
a
really
good
idea.
Actually,
like
you
mentioned,
you
know,
maybe
using
like
a
single
node
kcs
cluster
running
a
captain
there
as
a
control,
plane
and
speaking
to
other.
You
know
federated
clusters
in
some
fashion.
That
would
probably
be
a
really
good
pattern.
I
think,
for
this
kind
of
thing,.
B
This
is
what
we've
seen
with
captain
users
also
having
this
the
quality
gates
with
with
more
monolithic
applications.
So
they
are,
they
just
want
to
do
quality
gate
check
every
now
and
then
or
regularly,
and
they
are
not
running
yet
in
kubernetes.
So
they
just
want
to
do
this
with
in
a
install
captain
on
a
on
the
vm
with
k3s
and
then
trigger
captain
via
the
api
or
by
the
cli,
no
need
to
go
full
kubernetes.
B
If
you
are
not
yet
ready
and
you
don't
have
to
re-architecture
your
your
application,
if
you
just
want
to
use
parts
of
captain
like
the
quality
gates,
you
have
to
have
some
kind
of
monitoring,
because
you
need
some
data
for
the
quality
gates
to
evaluate,
but
we
don't.
Actually,
there
are
no
restrictions
where
the
data
can
come
from
right
now
we
have
integrations
with
a
couple
of
tools:
it's
open
source,
so
everyone
is
more
than
welcome
to
provide
more
integrations
with
more
tools.
A
A
B
B
Going
to
remember
so
then
the
next
part
yeah
we
can
actually
deploy
the
regular
cards
version.
We
can
actually
skip
this
part
why
we
can
skip
it
is
if
the
captain
quality
gate
is
working
correctly
and
I'm
pretty
positive
that
it
will.
Then
we
will
not
move
the
broken
version
into
production
and
for
our
final
part
of
of
the
stream,
we
will
do
the
self-healing
part,
and
we
will
take
a
look
at
how
actually
I
want
to
call
it
autoremediation.
B
It's
not
self-healing
in
a
way
that
will
fix
your
code,
but
it
will
remove
the
actual
issue.
So
it's
in
the
next
part.
We
can
use
the
version,
that's
already
running
in
production
in
our
production
namespace,
because
version
number
three
and
version
number
one.
It's
actually
the
same
version,
just
with
a
different
background.
There
is
no
latency
introduced.
There
is
no
nothing
else
introduced
the
only
thing
what
it
what
both
versions
can
do
is.
First,
we
have
a
feature
flag
implemented
with
unleash,
so
we
can
change
from
outside.
B
We
can
change
the
configuration
and
we
can
react
on
this-
that
captain
can
reach
out
again
to
unleash
to
the
feature
toggle
framework
and
turn
off
a
feature
flag
that
we
turn
on
in
this
tutorial.
We
do
it
a
little
bit
differently.
We
will
be
just
adding
a
couple
of
other
items
to
our
shopping
cart
that
will
incur
the
a
decrease
of
no
an
increase
of
the
response
time
and
we'll
just
initiate
a
scale
up.
B
B
A
B
It
says
the
response
time
is
way
too
high,
it's
more
than
one
second,
and
so
tests
were
running
for
8
minutes
and
38
seconds
response.
Time
is
failing.
We,
we
don't
have
the
error
rate
here,
but
we
I
did
this
a
couple
of
test
runs.
I
did
it
before,
and
the
error
rate
is
always
stable,
close
to
zero.
So
it's
not
about
the
errors.
It's
really
about
the
response
time.
We
can
also
see
it's
already
rolled
back
to
the
previous
version
and.
A
B
B
So
this
is
just
as
I
said,
we
can
have
different
ways
how
to
retrieve
our
service
level
indicators,
and
this
one
is
prepared
for
to
retrieve
the
the
right
response
times
for
the
for
the
self-healing
use
case.
So
this
just
is,
you
can
have
it
we're
just
overriding
this
actually
or
we're
adding
this
to
our
production
environment,
because
in
our
previous
runs
in
production,
we
never
did
the
quality
check.
B
B
B
B
B
B
In
this
case,
we
have
the
same
actions
for
different
types
of
problems.
The
one
is
just
called
response
time
degradation
that
would
be
actually
the
problem
type.
That's
coming
in
from
a
commercial
monitoring
solution
called
dynatrace.
We
would
for
this
tutorial.
We
could
use
the
same
file
it
will.
The
problem
type
would
be
called
response
time
degradation
in
promethoids.
B
The
problem
type
is
called
response
time
p90,
that's
just
how
we
set
it
up,
because
the
captain
integration
between
promethouse
and
and
captain
it's
using
the
slo
or
yeah
it's
using
the
the
name
of
the
slos
for
the
the
problem
type
and
it's
kind
of
inverting,
the
slo
and
whenever
the
slo
is
then
breached.
It
will
kick
off
their
loading
in
the
alert
manager,
and
the
action
here
is
to
scale
scale
up
by
a
value
one.
So
that's
what
we
should
see.
B
B
Exactly
so,
this
version
all
three
versions:
actually
they
have
some
faulty
item
in
it
and
we
can
just
add
we.
We
will
apply
a
load
generator
that
will
add
all
those
faulty
items
into
a
shopping,
cart
that
will
slow
it
down
quite
drastically,
and
then
we
should
be
able
to
see
that
in
that
the
response
time
is
degrading
and
captain
will
kick
off.
A
A
B
B
B
B
B
This
is
also
a
little
bit
the
part
where
we
need
kubernetes,
because
the
captain
itself
consists
of
a
couple
of
different
services,
so
it
will
forward
it
to
the
remediation
service
and
we
have
different,
as
you
see
in
the
remediation
yaml,
there
are
different
actions
that
you
can
define
and
one
action
is
scaling.
So
there
we
have
a
specific
component
that
can
remediate
scaling
issues
or
that
can
execute
the
scaling
action
yeah
exactly
here.
So
the
action
is
scaling
and,
as
we're
also
doing
deployment
with
helm,
we
will
also
do
the
scaling
with
helm.
B
We
will
rewrite
the
value
of
the
replica
set
in
the
hot
chart
and
then
use
helm
again
to
to
deploy
this,
and
we
will
also
see
it
in
the
in
the
git
repository
of
captain
that
this
value
will
be
changed,
so
we
will
scale
this
version
or
scale
the
the
replica
set.
We
also
have
other
integrations,
for
example,
for
for
the
feature
flex
that
I
mentioned
earlier.
B
B
A
B
Yeah
yeah,
so
there
are
different
tools
that
you
can
integrate.
Unleash
is
the
one
that's
yeah,
pretty
pretty
good
and
it's
working
great
for
for
for
the
feature
flex,
it's
really
a
great
framework.
It's
also
open
source
by
the
way
and
the
because
you
you
just
had
the
integrations
page
up
here.
One
of
the
last
integrations
that
we
did
was
together
with
litmus,
which
is
also
one
part
that
I
really
like
litmus.
B
Let's
say
like
this,
so
there
might
be
some
some
problems
in
production
and
we
can
already
simulate
these
problems
in
in
shifting
left
and
doing
this
in
in
previous
phases.
So
by
introducing
either
a
chaos
stage
in
captain
or
just
doing
it
in
a
pre-production
stage,
adding
the
litmus
service
you
can
execute.
B
We
we
just
had
in
the
captain
user
group
we
had
adrian,
who
is
an
at
in
building
exactly
this
use
case
and
evaluating
the
resiliency
by
either
having
no
chaos,
light,
chaos
or
heavy
chaos,
and
they
ex
there
requirement
to
their
application.
Is
that
no
chaos
and
light
chaos
have
to
basically
behave
the
same,
which
I
think
it's
pretty
interesting,
that
they
say
our
application.
It
has
to
be
resilient
in
a
way
that
introducing
light
chaos
to
application
should
not
change
anything
to
our
quality
gates.
B
A
Yeah,
I
think
litmus
chaos
is
one
of
those
things
that
they're
keeping
into
play
with
and
I
haven't
got
around
to
yet.
But
you
know
now
that
you've
described
the
concept
of
heavy
chaos.
I
feel
like
I'm
going
to
have
to
deploy
that
to
all
of
my
environments
now
to
see
how
things
to
see
how
it
sounds
weather
that
storm-
and
I
love
that
you
can
integrate
that
with
captain
as
well
to
kind
of
build
in
those
remediations
and
stuff
like
that.
So
it's
cool.
A
So
there's
quite
a
few
integrations
here
then
so
I
mean
that's
cool
the
slack
one.
The
service
now
we've
got
notifications,
local
courses
down
the
trace
as
a
whole,
tower
lots
of
stuff
for
people
to
experiment
and
what's
involved
in
writing
an
integration,
see,
I
think,
oh
I
actually.
I
want
to
build
like
maybe
discord,
notifications
or
twitter
what's
involved
in
writing.
One
of
those
integrations
or
captain.
B
We
usually
recommend
to
get
started
with
the
the
captain
service
template.
We
we
call
our
integrations
a
service,
also
it's
a
service
to
it's
a
captain
service
and
we
provide
a
service
template
in
go.
We
might
also
provide
it
with
other
programming
language,
but
since
captain
core
is
written
in
go,
we
also
provided
the
first
template
in
go.
B
B
So
there
are
a
couple
of
different
events
like
deployment
finished
event,
test
start
event,
test
finished
event,
configuration
changed
event,
remediation
start
event,
so
there
are
a
couple
of
events
and
whatever
events
you're
interested
in,
because
on
the
example
of
the
litmus
service
we
are
interested
in
test
start
events,
because
then
we
want
to
start
chaos
tests
and
we
will
send
a
test
finished
event.
So
the
captain
knows
chaos.
Tests
have
been
finished.
B
You
just
implement
your
logic
and,
depending
on
the
integration
you
might
want
to
send
an
event
back
to
captain
or
you
you
don't
want
to.
It
just
depends
for
a
notification
service.
You
usually
don't
send
an
event
back
to
captain
that
you
that
you
sent
the
notification.
It's
not
like.
Okay,
you,
you
did
it
great,
but
for
a
test
integration,
it's
important
that
you
inform
captain,
the
tests
have
been
triggered
and
tests
have
been
finished
so
and
we
provide
this
the
whole
template
here.
B
It
already
has
the
all
the
event
handlers,
which
are
just
it's
basically
just
a
stop
where
you
just
write
your
your
business
logic
and
most
or
the
the
first
part
where,
where
we
ask
the
captain
community
to
to
provide
their
integrations,
is
the
captain
sandbox.
This
is
where
we
start
developing
new
integrations.
We
can
already
see
we
can
see
the
monaco
service,
we
can
see
the
local
service.
I
just
initiated
some
discussions
in
our
captain's
lack.
B
A
Yeah,
I
think
now
that
I've
seen
that
alexa
notification
service
I've
just
had
an
idea
for,
like
my
next
friday
hackathon
project,
which
is
to
have
my
feeling
my
failing
quality
gates,
turn
the
room,
color
red,
I
think,
or
maybe
green,
on
a
pass.
So
I
know
where
my
deployments
have
broken
so
like
some
sort
of
philips
hue
integration
to
change
my
lights.
I
think
that
would
be
good
fun.
That.
A
A
A
B
So
it's
also
here
in
the
sequence
screen,
so
we
can
see
that
there
is
a
problem
opened.
We
can
see
everything
that
was
going
on,
so
it's
actually
a
couple
of
events
that
are
sent
through
captain
it's
first,
the
problem
open
event
coming
in
a
remediation
trigger
the
remediation
status,
changed
and
action
has
been
triggered.
Action
has
been
started,
so
it's
a
lot
of
things
again
where
you
can
subscribe
to.
You
can
add
your
services
to,
but
we
can
see
which
services
are
responsible
for
the
actual
action.
B
I
explained
earlier
that
the
action
itself,
the
scaling
action,
is
done
by
the
helm
service.
If
you
have
your
own
scaling
or
if
you
want
to,
I
don't
know,
increase
the
the
brightness
of
your
hue
lights
in
your
room
whenever
time
there
is
a
scale-
and
you
could
also
listen
to
this
scaling
events
in
your
service
and
it
says
action
started
action
finished
so
already.
We
know
that
it
already
did
the
scaling
and
in
kubernetes
we
already
saw
that
there
are
now
two
parts.
B
If
it's
not
yet
remediating
the
the
response
time
that
it
will
evaluate
again
the
captain
quality
gate
and
if
it
needs
another
scale
up
to
to
meet
again
the
quality
gate
of
captain,
it
will
do
another
scale
up.
So
it's
just
you,
you
can
start
small
like
let's,
let's
say
and
you
don't
have
to
scale
up
by
100,
but
maybe
just
by
five
percent
and
then,
if
it's
already
meeting
the
slos
again,
it's
fine.
If
not,
then
it
will.
B
Yeah-
and
we
should
also
see
that
the
alert
is
will
be,
will
be
closed
again.
So
first,
the
lord
is
pending,
they
will
be
firing
and
then
it
will
be
will
be
going
away
and
go
back
to
green,
but
it
takes
a
while
for
us
to
see
everything.
So
I
think
the
the
most
important
part
here
was
that
we
saw
it
how
the
the
remediation
is
actually
kicked
off
and
which
files
are
included.
Everything
is
again
based
on
the
definition
files.
B
The
declarative
definition
files
of
captain
based
on
the
shipyard
file
slo
file,
is
a
very
strong
concept
and
one
of
the
most
important
files
in
captain,
as
it
defines
the
quality
gates
sli
file,
defines
how
to
query
all
the
data
that's
needed
for
the
quality
gates
remediation.
The
file
defines
which
actions
are
kicked
off
whenever
there's
some
alert
coming
in
or
a
problem
coming
into.
Captain.
A
Excellent,
I
think
we've
covered
an
awful
lot
and
I
think
we've
seen
a
lot
of
really
valuable
use
cases
for
what
captain
can
offer,
for
you
know,
cooper,
merry's
deployments,
I
think
you
know
the
the
quality
kits
are
just
so
valuable
for
anyone
who
wants
to
ship
anything
through
multiple
stages
and
then
being
able
to
build
your
own
event-driven
remediation
loops.
I
think
it's
just
wildly
cool
as
well.
I
must
have
been
any
integration
that
I
want
to
build
access
to
all
of
those
events
emitted
by
any
other
plugin
within
the
captain
system.
A
Is
that
right?
So
I
just
say:
hey,
I
want
to
listen
for
this
and
I
want
to
start
automating
it
with
this
other
stuff.
On
top
of
it,
I
think
just
the
power
and
that
event-driven
kind
of
loop
opens
up
so
many
different
possibilities
for
the
way
that
we
deploy
our
applications
to
kubernetes,
so
very,
very
cool,
I'm
very
excited
by
that.
B
Is
there
anything
else,
yeah,
it's
really
exciting.
Sorry,
when
you
go,
we
are
yeah.
I
I
can
just
oh
sorry,
okay,
so
we
are
really
excited
also
to
share
soon
our
next
iteration
of
the
shipyard
file,
so
the
file
that
we
saw-
or
maybe,
if
you
could
scroll
up
here
on
this
screen
a
little
bit
on
the
first
part.
I
think
we
saw
the
shipyard
file
and
yes,
so
this
was
the
file
that
we
are
also
using
in
in
the
demo
or
in
the
tutorial.
B
If
you
want
to
walk
through
the
tutorial,
it's
tutorials.captain.sh,
but
we
are
we.
We
got
some
requests
from
the
captain
community
and
we
in
the
next
iteration
we
are.
We
are
we're
doing
an
yeah,
a
new
iteration
and
an
improved
version
of
the
shipyard
file,
and
we
already
have
the
captain's
0.8
alpha
out
there
and
I'm
pretty
sure
that
we
we
can
deliver
the
the
stable
and
final
release
of
0.8
pretty
soon
and
it
will
be
even
more
mature
and
there
will
be
more
use.
B
B
So
it's
a
we
are
in
exciting
times
with
this
project
and
if
you
can
think
of
any
integrations
that
you
want
to
see
or
you
want
to
start,
please
also
reach
out
to
us
on
slack.captain.sh,
because
we
are
happy
to
provide
you,
the
git
repository
in
the
captain
sandbox.
So
it's
kind
of
the
the
place
where
your
integration
is
also
visible
and
you
can
provide
it
to
the
captain
community.
A
Awesome
so
yeah
everyone
join
the
the
captain.
Slack
start:
writing
your
own
integrations.
I'm
going
to
start
my
q1
very
very
soon.
Is
there
a
weekly
is
the
slack
the
best
way
to
get
engaged
with
the
captain
community?
Do
you
have
weekly
calls
office
hours
and
that
people
can
also
get
help
with
if
they
do
want
to
start
writing
their
own
integrations.
B
Yes,
so
we
have
the
slack
where
we
are
where
the
captain
core
team
and
the
captain
community
is
is
online.
Every
day,
then
we
have.
The
captain
developer,
calls
every
thursday
on
5
p.m,
central
european
time.
So
the
next
one
is
tomorrow.
Then
we
have
also
the
captain
user
groups.
We
run
this
monthly
and
these
are
more
sharing
use
cases,
as
as
I
briefly
described,
we
had
last
time
we
had
adrian
from
from
from
utopia
sharing
his
story
around
litmus
testing
and
the
chaos
testing.
B
We
also
had
sumit
from
intuit
sharing
already
his
story
on
integrating
different
performance
tests
and
then
captain
evaluations,
so
we
have
different
formats,
but
for
like
fast
response
times
around
development,
I
think
best
is
to
join
the
captain.
Slack
and
also
joining
us
on.
The
captain.
Developer
calls
every
thursday.
A
Awesome
all
right:
well,
everyone
should
install
captain
improve
their
continuous
delivery,
take
advantage
of
quality
gates
and
remediation
and
build
your
own
integrations
join
the
slack
join
the
developer
calls
jurgen.
Thank
you.
That
was
really
great
to
see
that
from
start
to
finish,
I'm
so
glad
we
came
back
for
part
two
and.