►
From YouTube: Introduction to Keptn (Part I) | Rawkode Live
Description
In this episode, we take a look at on-boarding and deploying our first Keptn managed service to our Kubernetes clusters, using Prometheus to provide safety for continuous delivery through progressive delivery.
This episode is part of the Guide to Keptn series.
-- Introduction to Keptn (Part I) - This Video
-- Introduction to Keptn (Part II) - https://youtu.be/pMkjE_uvJoo
🍿 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:15 - Introductions
02:22 - What is Keptn?
21:50 - Installing Istio
25:45 - Installing Keptn
32:00 - Setting up our Keptn repository
43:20 - Onboarding our first service
51:00 - Deploying our first service
1:12:00 - Adding Prometheus
1:16:40 - Progressive delivery
👥 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
rock
code
live
I'm
your
host
rock
hood
before
we
get
started.
I
just
want
to
say
thank
you
to
my
employer,
equinix
medal.
They
provide
the
time
and
the
resources
for
me
to
invest
in
producing
this
show
and
making
sure
we
all
have
great
cloud
native
content
to
learn
together.
A
If
you
want
to
check
out
economics
metal,
there
is
a
code
raw
code
dash
live
which
you
can
use
at
metal.equinox.com
check.
It
out
have
some
fun
today
we're
going
to
take
a
look
at
the
captain
project
and
I
have
a
great
guest,
jurgen,
ezel
starfire,
who
is
an
engineer
at
dinatris
and
a
maintainer
of
the
captain
project,
hello
jurgen?
How
are
you.
A
B
B
B
It
was
not
called
captain
by
then,
but
we
found
that
we
have
a
lot
of
best
practices
that
we
are
using
when
it
comes
to
cloud
native
technologies
when
it
comes
to
delivery,
when
it
comes
to
quality
of
software
that
we
are
already
using,
and
we
try
to
basically
provide
everything
also
to
to
other
organizations
and
also
to
our
customers-
and
this
was
the
basic
idea-
let's
start
an
open
source
project
and
let's
make
everything
that
we
already
know.
Let's
make
it
available
for
others,
and
let's
make
this
yeah.
A
B
Cool
okay,
so
let
me
just
introduce
briefly
the
captain
project
which
use
cases
it
solves
or
like
targets
and
which
problem
it
solves.
If
you
want
to
take
a
look
there,
it's
captain.sh,
we
in
austria
or
in
german-speaking
countries,
we
say
captain
like
the
captain
of
a
ship.
That
was
the
main
idea
behind
it:
the
the
captain
ships
applications.
B
B
These
are
dispense,
our
use
cases
and
everything
is
built
on
the
githubs
approach,
where
you
just
bring
your
configuration
files
and
captain
will
manage
these
configurations
files
and
will
also
connect
to
your
tools.
So
david
already
mentioned,
it's
a
control
plane
the
cloud
native
control
plane
for
continuous
delivery
and
automated
operations,
and
it's
basically
solving
the
problem
of
application.
Life
cycle
orchestration
management.
So
if
you
have
health
charts
and
if
you
use
helm
for
deployment,
you
can
do
this
with
captain
as
well.
B
So
captain
can
use
your
helm,
charts
and
deploy
your
microservices
for
you.
You
can
also
connect
it
to
argo.
You
can
connect
it
to
jenkins.
We
have
other
integrations
for
monitoring
tools
like
promethos,
where
you
can
use
this
data
for
your
quality
checks.
You
can
connect
it
to
jmeter
for
load
generation,
performance
testing.
You
can
connect
it
to
litmus
chaos
for
chaos
engineering,
so
you
can
connect
it
to
a
lot
of
different
tools.
B
Everything
is
event
based
and
with
this
we're
very
open
to
to
to
broaden
this
ecosystem
and
to
open
up
for
tool
integrations,
and
captain
really
brings
together
the
different
tools
that
you
already
have
in
your
tool
belt.
Let's
say
and
manages
continuous
or
progressive
delivery
and
automated
operations
for
you.
So
how
is
why
did
we
actually
start?
B
There
is
no
pipeline
code
anymore,
everything
is
event
based
and
you
just
connect
your
different
tools
and
you
have
very
very
small
configuration
files
that
are
for
a
very
specific
purpose
and
with
this
it's
very
easy
to
change
them.
Update
and
maintain
them,
and
one
part
is
also
a
lot
of
organizations
to
spend
a
lot
of
time
in
remediating
the
issues
they
might
already
have
some
playbooks
in
place
like
say,
ansible,
playbooks
or
some.
B
It
can
be
shell
scripts
that
just
remediate
an
issue,
but
anyway
they
have
to
be
executed,
and
here
we
also
bridge
this
gap.
By
from,
let's
say,
prometheus
alert,
we
can
trigger
a
ansible,
playbook
or
or
execute
shell
scripts
or
python
scripts
that
already
remediate
or
try
to
remediate
the
issues.
So
we
are
with
this
event-based
methodology.
Let's
say
we
we
can.
B
Case
yeah
thanks.
The
first
use
case
where
I
think
captain
already
brings
some
value
is
when
you
start
to
manage
your
applications
with
captain,
because
captain
can
already
configure
your
monitoring.
Let's
say
your
prometheus:
create
the
scrape
jobs,
create
the
learning
rules
in
the
alert
manager
create
dashboards
in
grafana.
We
have
not
even
yet
deployed
the
application,
but
we,
when
we
onboard
the
application,
that's
also
how
we
call
it
it's
a
captain
onboarding
it's.
B
We
have
a
lot
of
these
terms,
but
when
you
onboard
application-
and
you
were
using
captaincli
that
you
can
already
use
it
to
configure
your
monitoring
solutions,
set
up
alerts,
create
dashboards,
set
up,
scrape
jobs,
these
kind
of
things
and
as
said,
we
have
not
even
yet
started
to
to
deploy
the
applications
yeah.
I
think
we'll
see
this
later
on.
So
I'll
just
skip
this
one
and
the
second
part
where
it's
really,
we
are
bringing
we're,
bringing
a
really
big
benefit.
B
B
Time
can
be
based
on
the
error
rate,
cpu
consumption,
whatever
everything
that's
queryable
or
that's
a
metric,
let's
say-
and
you
can
create
this
form,
for
example,
from
prometheus,
you
can
define
some
service
level
objectives
and
captain
will
sub
will
set
up
a
multi-stage
delivery
pipeline
for
you
and
between
each
stage.
Captain
makes
sure
that
it
evaluates
the
quality
of
your
microservice,
based
on
the
service
level,
objective
that
you
have
defined
and
you
just
defined
it
in
a
yaml
file
and
the
deployment
and
the
triggering
of
the
tests
and
then
the
evaluation.
B
So,
for
example,
here
we
have
the
shipyard
file,
the
slo
file,
the
helm
chart
for
deployment,
and
we
can
see
that
the
shipyard
file,
actually
that's
the
complete
shipyard
file
for
a
multi-stage
pipeline.
We
have
def
staging
production
with
the
quality
gate.
That's
basically
the
whole
quality
gate,
that's
slo
file
and
you
will
get
this
automated
quality
evaluations
for
each
deployment
that
you're
triggering
with
captain
and
the
data
is
then
gathered
in
this
example
for
from
promethos
and
the
tests
have
been
executed
by
jmeter.
B
For
example,
and
in
the
yeah,
this
is
how
it
works
a
little
bit
more
detail.
We
have
these
slo
files
and
sli
files.
These
are
you
can
think
of
this
as
a
library
of
indicators
and
how
you
can
fetch
this
data
with
a
prom
ql
query:
where
you
can
you
define
your
prom
ql,
and
this
is
then
executed
when
captain
evaluates
the
quality
gate
and
you
can
just
reuse,
let's
say
the
error
rate
here.
B
We
just
reused
error
rate
in
the
objective
file
and
we
specify
the
error
it
has
to
stay
lower
or
equal
than
one
percent
and
the
time
frame
for
the
evaluation,
that's
actually
calculated
by
captain,
since
captain
can
also
trigger
the
tests
and
captain
will
trigger
the
tests.
Let's
say
gmeter
tests
or
neoload
tests
or
blaze
meter
or
whatever
you're
using
and
once
the
tests
are
finished.
Captain
will
be
informed,
the
tests
are
finished
and
it
can
evaluate
for
this
exact
time
frame
of
the
tests.
B
B
And
for
the
third
major
use
case
of
captain,
this
is
where
we
automate
part
of
your
operations.
We
call
it
by
closed
loop,
remediation
and
with
closed
loop
remediation.
What
we
really
mean
is
that
we
are
constantly
evaluating
if
the
remediation
is
actually
if
it
was
successful.
So
we've
seen
that
organizations,
and
also
this
is
where,
where
we
started
also
a
couple
of
years
once
there
is
a
problem
or
an
alert
coming
in
this
can
also
be
sent
to
captain
as
a
cloud
event,
a
captain
can
execute
remediation
actions
trigger
other
tools.
B
So,
for
example,
we
have,
we
have
one
one
demo,
application
where
we
send
a
an
alert
via
the
prometheus
alert
manager
and
in
the
remediation
file.
We
define
two
different
remediation
remediations
for
one
specific
problem,
and
the
problem
in
this
case
is
a
response.
Time
degradation,
that's
the
name
of
the
problem.
This
will
map
to
the
alert
of
promethos,
so
these
two
they
basically
have
to
be,
they
will
match
and
we
will
then
have
a
number
of
of
actions.
B
So
in
this
case
two
actions,
the
first
one
will
be
executed.
It's
a
scaling
scaling
is,
is
a
built-in
functionality
of
captain,
so
it
can
basically
change
the
values
of
the
helm.
Chart
the
the
replica
set
values
of
the
helm
chart
will
increase
it
in
this
case
by
plus
one
or
you
can
say
by
plus
ten
percent
or
whatever
is
might
be.
The
right
action
will
then
re-evaluate
the
slo
file
will
do
this
evaluation
of
the
quality
gate.
If
it's
remediated
everything's
fine,
if
not,
it
will
go
to
the
next
action.
B
This
is
in
this
case.
It's
the
talking
of
a
feature
flag,
so
we
in
this
case
we
actually
want
to
disable
the
a
campaign
of
a
specific
campaign
id.
We
can
think
of
this
like
a
promotional
campaign
that
has
been
initiated.
Maybe
that's
generating
a
lot
of
problems
for
our
response
time.
Maybe
it's
it
has
to
has
to
do
too
much.
I
don't
know
database
calls,
for
example,
so
this
can
be
also
triggered.
We
don't
define
the
tooling
in
these
files.
The
tooling
will
be
just
listening
for
these
events.
B
So
if
you
want
to
move
from
one
feature
flagging
framework
to
another,
you
can
still
use
the
same
remediation
files,
because
what
you
will
do
is
you
will
just
change
the
the
part
which
listens
for
for
events
from
captain
and
in
this
case
might
be
resolved
or
not.
We
can
then
escalate
it.
We
can
send
all
this
everything.
That's
going
on
all
these
cloud
events
also
to
to
slack,
for
example,
or
just
sending
it
to
slack
when
it
escalates
and
we
could
not
resolve
it.
B
Yeah,
that's
the
that's
the
main
or
the
major
three
use
cases
and,
as
said
in
the
beginning,
captain
is
built
as
an
event-based
control
plane
that
lives
in
your
kubernetes
cluster
and
you
can
send
cloud
events
to
this
control.
Plane
and
controlling
can
also
send
cloud
events,
so
it
re
receives
and
sends
cloud
events,
and
this
is
how
the
the
tool
integrations
are
actually
done.
B
We
already
have
a
couple
of
tool
integrations
and
we
see
more
and
more
or
we
see
this
growing
as
more
and
more
organizations
are
contributing.
For
example,
we
receive
the
contribution
for
a
slack
bot
where
you
can
control
continuous
delivery.
Workflows
with
a
slack
bot,
so
you
get
the
whole
evaluation
of
the
quality
gate
directly
into
slack
and
you
can
just
accept
or
recheck
if,
if
this
build
should
move
on
to,
let's
say
from
your
deaf
environment
to
pre-prod
or
even
from
pre-brought
abroad,
so
that's
pretty
cool.
B
B
C
A
B
A
All
right
nice
so
on
yours
slide.
In
fact,
let
me
just
pull
that
back
up.
Let
me
can
you
go
back?
Was
it
one
side
to
the
side?
Maybe
this
one
okay.
So
if
I'm
trying
to
think-
and
you
know
we'll
get
hands
on
in
just
a
moment
and
I'm
sure
all
my
questions
will
be
answered
there,
but
I'll
throw
them
out
anyway,
it's
like
captain
runs
as
a
control
plane
to
monitor
pretty
much
everything
after
I
get
merged
into
my
main
branch
to
my
application
running
in
production.
A
B
So
today
we
will
we
we
have
to
use
captain
0.7.3,
that's
the
latest
version
and
we're
working
on
0.8
and
with
dot
8.
It
will
be
possible
to
have
to
manage
different
clusters
in
different,
even
in
different
clouds.
So
then
it
doesn't
really
matter
where
the
cluster
lives,
but
right
now
the
control
plane
can
manage
one
cluster
and
we
are
doing
the
separation
between
the
the
control,
plane
and
execution
plane,
and
then
it
will
be
easier.
A
All
right:
sweet,
okay,
let's
get
started
then.
So,
if
I
pull
up
my
screen
there
we
go.
We
have
the
captain
website.
People
can
check
that
out
at
captain.sh
and
there's
documentation,
tutorials,
etc.
The
tutorials,
I
believe,
is
what
we're
going
to
get
started
with
today.
So
these
are
at
least
just
guides
that
anyone
can
follow
along
at
their
own
time,
click
start,
and
then
you
just
guide
it
through
step
by
step.
Right,
so
are
we
doing
the
captain
phil
that
sounds
exciting
on
prometheus
one
right?
That's
the
one!
B
Yeah,
that
sounds
good
and
the
other
ones.
They
are
basically
for
different
use
cases.
They
show
you,
for
example,
captain
in
the
box
we'll
use
micro
kubernetes.
We
also
have
the
guide
for
the
captain
installation
k3s.
If
you
want
to
do
that,
to
connect
it
to
argo
cd,
so
we
decided
to
to
go
for
tutorials.
We
also
have
a
documentation,
but
tutorials
are
more
guiding
you
how
to
to
follow
the
the
the
concept
of
captain
and
how
to
use
them
to
to
the
best.
B
A
B
That
will
will
explain
how
to
install
it.
I
will
explain
how
to
do
delivery
with
captain
quality
gates
with
captain
and
automated
operations,
or,
let's
call
it
self-healing
with
captain
and
we'll
bring
also
all
the
the
tools
that
you
will
need.
So
in
this
case
I
will
ask
you
to
install
istio,
because
that's
what
we
are
using
for
the
route
generation
and
the
traffic
shifting
between
the
blue
green
versions.
B
A
A
B
Actually,
when,
when
you're
using
captain,
you
won't
see
a
lot
of
istio
because
we
will
be
the
captain
is
generating
the
the
virtual
services
and
all
the
traffic
routes
that
you
will
need
for
for
seo
the
ingress
these
kind
of
things.
So
you
we
won't
see
a
lot
of
sdo.
It's
just
used
behind
the
scenes,
but
it's.
B
We
only
so
if
we
are
not
to
use
if
we
are
not
doing
continuous
delivery
with
captain.
If
we
are
using,
let's
say,
argo
cd
for
continuous
delivery,
and
we
are
just
using
captain
for
the
quality
parts
and
the
automated
remediation
part,
then
we
won't
need
istio
it's
when
we
are
going
for
the
full
installation
of
captain
and
we
want
to
do
continuous
delivery.
We
need
istio.
We
were
thinking
about
also
moving
to
the
service
mesh
interface
then
also
supporting,
link
id
and
other
service
meshes,
but
it's
just.
A
A
B
B
B
A
I'm
just
going
to
keep
clicking
buttons
when
things
are
presented.
If
I
do
anything
wrong,
just
feel
free
to
yell
at
me,
but
so
this
is
gonna,
oh,
so
it's
installing
captive.
So
I
could
have
done
this
to
the
helm
chart
as
well.
I'm
assuming
the
cli
is
just
a
wrapper
and
that
provides
some
values
for
the
use
cases
that
are
selected
is
that
roughly
right.
B
Yes,
yes
exactly,
we
had
it
differently
that
we
had
a
really
like
a
job
that
was
really
executing
step
by
step,
the
capital
installation,
but
we
we
thought
it's
best
to
move
to
helm
charts,
since
it
also
provides
possibility
to
install
it
via
a
helm
chart
without
the
installer.
That's
what
we
also
see.
Sometimes
it's
not
allowed
to
install
any
software
with
an
installer
script,
but
just
with
helm
charts
so
that
organizations
have
full
control
and
can
take
a
look.
What
is
actually
installed
in
this
case.
B
It's
basically
applying
the
helm
chart
and
we
will
see
a
couple
of
parts
spinning
up
in
the
captain
namespace.
So
we
install
everything
in
one
namespace
and
that's
the
captain
namespace
we.
If
you
want
we
can.
We
can
try
cubectlcat
pods
minus
end
captain.
We
will
see
the
what
is
actually
creating
here.
Yeah
we'll
see,
that's
basically
the
the
core
of
captain,
a
couple
of
different
services
that
talk
to
each
other.
A
B
B
A
B
You
can
yeah
it's
actually,
this
one
is
just
downloading
and
the
next
one
is
then
we
will
just
run
in
the
next
comment,
so
we
will
can
t.
We
can
also
take
a
look
here.
It's
what
it's
doing
is
it
will
create
the
ingress
and
it
will
create
also
a
gateway,
and
it
will
restart
our
restart
one
service
off
of
captain
that
it
can
fetch
this
configuration
all.
C
C
B
Okay,
so
we
already
see
where
your
kubernetes
cluster
lives,
so
we
can
take
a
look
at
the
api
endpoint
and
there
is
also
the
the
bridge
that
will
be
exposed
here.
I
will
just
warn
you
so
whenever
we
are
doing
the
we
yeah,
that's
the
api
of
captain,
it
can
be
controlled
via
the
the
cli
or
via
the
api
and
yeah.
You
can
imagine
that
when
citrix
built
integration
with
the
slack
bot,
they
were
more
using
the
api.
B
Today
we
will
be
more
using
the
cli
since
it's
easier
instead
of
writing
all
these
cloud
events
and
then
sending
them
to
the
api,
okay
and
yeah.
So
with
this
we
already
installed
captain
we
have
access
to
the
captain
api.
So
we
know
it's
up
and
running
and
we
could
also
already
take
a
look
at
the
captain's
bridge,
but
it
will
be
empty
anyway,
so
we
can
go
ahead
and
create
our
first
project
on
board,
offered
services
and
then
take
a
look
at
the
bridge.
A
B
B
So
we
can
also
take
a
look
at
all
the
different
projects
and
all
the
on
everything
that
has
been
created
by
captain,
or
we
can
just
assume
that
everything's
fine
and
we
just
trust
that
the
captain
repository
that
is
managed
by
captain
in
its
in
its
in
the
cluster
is
we
will
be
fine,
so
we
can
go
with
the
git
upstream
or
we
can
also
link
it
afterwards.
So
right
now
we
can
also
go
with
the
installation
without
the
kit
upstream,
and
we
can
do
the
link
up
the
git
upstream
afterwards,
if
you
want.
B
C
B
B
B
B
B
A
A
B
So
what
captain
will
do
is
here
it
will
start
to
create
the
project
and
it
will
create
different
stages,
and
these
stages
will
be
managed
by
branch,
so
it
is
going
to
create
the
project,
a
sock
shop.
That
also
means
the
folder
in
the
git
repository
creating
the
branches
in
the
git
repository,
and
it
should
already
be
synced
to
your
git
upstream.
So
it's
always
doing
this
that
it
will
sync
it
to
a
git
upstream.
B
So
if
you
reload
it
here,
we
can
already
see
the
shipyard
file
and
you
will
also
see
three
different
branches
for
depth:
staging
and
production.
So
with
this
we
have
already
created
a
let's
say:
the
environment,
of
a
multi-stage
pipeline
dev
staging
production,
and
if
we
can
take
a
look
in
the
shipyard
file,
we
will
see
how
this
is
configured.
B
So
in
our
dev
stage,
we
do
have
a
deployment
strategy
which
is
direct,
so
no
blue,
green
deployments
for
for
our
dev
stage,
which
is
deployed
directly
into
the
dev
stage,
and
we
execute
some
functional
tests.
That
is
the
instruction.
How
this
stage
should
be
should
be
set
up
and
is
set
up
by
captain
for
staging.
B
We
have
a
deployment
strategy
which
is
a
blue
green
on
the
service
level
and
the
test
strategies
performance
tests,
so
the
test
integrations,
they
get
the
let's
say:
instructions
to
execute
performance
tests
and
an
approval
strategy
is
set
to
automatic
for
for
everything.
That
means
either
or
it
doesn't
really
matter.
If
the
quality
gate
gives
us
a
warning
or
a
full
pass,
we
promote
it
automatically
into
this
stage
for
production.
The
approval
strategy
is
a
little
bit
different
if
it's
a
full
pass,
we
deployed
automatically
into
production.
B
If
we
get
a
warning,
we
would
have
to
click
on
or
approve
it
manually,
either
by
clicking
in
the
captain's
bridge
or
doing
this
with
the
slack
bot
or
with
an
api
call.
Just
approving
this.
You
can
have
an
integration
with
other
tools
as
well,
and
we
also
have
a
remediation
strategy
for
production.
So
that
means,
if
there's
any
issue,
any
alert
sent
from.
B
B
The
captain
directly
does
not
right
now
expose
its
own
metrics,
how
the
of
the
performance
of
captain?
If,
if
this
is
the
questions,
captain
can
collect
different
metrics
from
sli
providers
and
which
metrics
like
a
response
time
or
a
total
amount
of
calls
or
whatever
you
you
can.
Think
of
these
are
just
defined
in
the
sli
file.
A
A
B
Exactly
we
just
defined
that
there
will.
There
is
a
project
sock
shop,
but
we
have
not
onboarded
the
microservices,
yet
we
can
think
of
like
we
have
to
find
the
the
whole
application
that
we
have
a
container
for
this
application
and
a
logical
container.
Let's
say,
and
now
we
will
on
board
services,
so
we
could
onboard
a
front-end
database,
a
back-end,
and
what
we
will
do
is
the
demo.
B
B
B
A
A
B
Exactly
and
in
the
tutorial,
we
have
two
services
that
we
want
to
onboard
the
first
one
is
the
cart:
it's
actually
the
application
of
the
shopping
cart
and
in
the
in
step.
Two.
What
we
also
do
directly
here
is
that
we
add
test
instructions
for
our
different
stages,
so
for
dev
we
will
test,
we
will
add
test
instructions
for
chimida,
which
is
just
a
functional
test,
basically
checking
if
the
api
is
available
of
the
car's
microservice
and
for
the
performance
test,
it
runs
a
couple
of
thousand
requests
against
the
service.
B
B
And
the
cool
thing
here
that
you
just
have
to
define
your
helm
chart
once
and
then
you
basically
pass
it
on
to
captain
and
from
this
point
you
don't
have
to
touch
the
helm
chart.
You
can
do
most
of
the
things
with
cloud
events
or
with
the
captain
cli,
and
you
don't
have
to
to
maintain
it.
They
they
will
be
managed
in
the
captain,
git
repository
and
depending
on
the
stage.
So
what
we've
seen
is
for
the
staging
and
the
production
environment.
B
We
have
defined
the
blue
green
deployment,
so
there
will
be
different,
manifests
kubernetes
manifests
created
for
these
different
stages
because
for
blue
green
we
need
virtual
services
for
istio
for
direct
deployments.
We
don't
need
this.
We
can
go
with
the
standard,
kubernetes
services,
so
this
is
just
how
it
how
it's
done.
B
A
A
B
B
And
for
this
we
can
also
see
it
here
as
the
last
parameter
in
the
in
this
line
that
we
are
overriding
here,
the
deployment
strategy.
So
we
have
defined
the
deployment
strategy
on
the
level
of
the
project
we
defined
for
it's
in
depth.
It's
direct
in
staging
it's
blue,
green
and
in
production.
It's
also
blue
green
for
the
database.
We
don't
do
blue-green
deployments
in
this
case,
so
we
just
go
for
a
direct
deployment
for
the
database.
B
Devices,
yes,
so
it's!
If
you
have
your
set
right
now,
captain
is
doing
deployments
on
the
same
cluster,
where
the
captain
control
plane
is
also
installed.
So
I
would
not
go
right
now
for
edge
devices
here,
but
with
the
next
version
of
captain,
it's
totally
possible
to
do
deployments
also
to
other
clusters
or
to
to
edge
devices.
That's
that's
totally
possible.
Yeah.
A
Okay,
I
mean-
I
guess
you
could
have
like,
depending
on
the
edge
setup,
but
if
those
ads
edge
devices
are
all
part
of
kubernetes
cluster
had
a
control
plane
centrally
managed,
I
mean
captain
could
also
just
run
there
and
still
do
deployment
to
those
nodes,
even
though
they're
distributed.
I
would
imagine-
and
you
also
mentioned
the
captain-
runs
on
kcs
as
the
start
of
the
stream,
which
I
guess
may
be
a
good
fit
for
those
edge
scenarios
as
well.
C
A
B
Exactly
so,
it's
everything
that
we
have
done
until
this
point
is
basically
a
one-time
setup.
So
we
have
created
the
project.
We've
onboarded,
our
services-
we've
not
yet
deployed
them,
but
they
already
know
which
tests
they
have
to
execute.
Once
we
deploy
them,
they
know
if
they
should
be
deployed
in
a
blue-green
fashion
or
if
remediation
should
be
executed
for
them.
So
we
have
already
provided
all
these
instructions
and
in
the
next
part
we
now
deploy
the
cart's
database
and
the
card's
microservice.
B
A
B
A
B
That's
basically
what
what
you
will
be
doing
with
the
api.
The
api
will
just
respond
200
if
the
the
cloud
event
is
okay,
this
one
is
always
open
up
the
the
websocket.
You
can
also
omit
the
websocket.
It's
I
think
it's
dash
dash
no
websocket
or
suppress
web
socket.
If
you
go
to
the
captain
help,
then
you
you
will
find
it.
B
C
B
A
A
B
Exactly
and
but
what
you
always
get
is
the
captain
context
id
and
with
this
captain
context
id,
you
can
always
query
the
events
that
belong
to
this
captain
context.
So
in
this
case,
captor
will
start
the
deployment
it
will
now
do
the
deployment
in
the
kubernetes
cluster.
It
will
trigger
the
tests,
it
will
do
the
evaluation
after
the
tests
have
been
finished
and
it
will
decide,
if
should
if
it
should
be
promoted
to
the
next
stage
or
if
we
or
if
it
should
stop.
B
So
everything
is
done
now,
starting
from
here
and
in
the
captain's
bridge,
you
can
follow
the
the
sequence
of
events,
and
it
will
just
this
time.
Application
is,
I
think,
is
a
spring
boot
application.
It's
not
tweaked,
let's
say
in
any
way,
so
it
will
just
take
a
while
to
to
be
deployed
here.
We
should
already
see
actually
the
to
cardstb.
B
A
I
think
I
know
the
answer
to
this,
so
you
can
feel
free
to
correct
me
if
I'm
wrong,
but
I
don't
think
it
does.
I
think
it's
just
querying
the
ip
addresses
from
the
services
inside
the
clustered
and
when
we
installed
sdo
it
deployed
the
sdl
gateway,
which
then
requested
a
load
balancer
from
the
provider
so
that
that
was
all
set
up
with
sdo.
There
was
no
ingredients
set
up.
As
far
as
I
know
with
that
command.
Is
that
right.
A
Yeah,
okay,
it
was
cool
and
the
configure
bridge,
I
think,
was
just
getting
us
a
url
that
we
can
use
exactly
and
if
you're
not
familiar
with
the
nip
io,
it's
just
a
free
service
where
you
can
put
any
ip
address
in
their
format
like
you
can
see
here.
Let
me
zoom
in
on
that
a
little
bit
really
cool
when
you
don't
want
to
have
to
deal
with
dns
records
at
all
and
and
it
just
maps
back
to
the
ip
address,
which
is
part
of
the
actual
domain
name,
a
really
cool
service.
A
B
C
A
C
B
B
Because
that
will
be
synced
anyway,
so
we
should
be
able
to
see
this,
but
it
will
give
us
a
hard
time
because
the
helm
chart
okay
here
here
comes
the
the
thing
the
helm
chart
is
now
you
have
it
in
depth
in
staging
and
in
production.
So
we
wouldn't
change
it
three
times,
because
captain
is
taking
this
help
chart
and
putting
it
for
each
stage
replicating
this
helm
chart.
So
you
can
have
it
basically
managed
by
each
stage.
C
B
B
B
B
A
C
B
B
A
B
B
Yeah,
but
is
there
any
chance
that
we
can
like
bump
the
size
of
the
cluster
a
little
bit,
because
it
will
do
the
same
in
staging
and
in
production,
but
in
staging
and
production
we
will
do
a
blue
green
deployment.
So
we
have
two
versions
of
carts
running,
so
we
might
run
out
of
space
also
in
staging
and
production
because,
like
we
are
adding
five
more
containers
to
the
show.
A
A
B
And
I
think
that
gives
me
that
the
chance
to
to
rethink
about
our
demo
application,
since
it's
a
little
bit
too
big
for
a
very,
very
small
shopping
cart,
and
it
takes
just
too
much
resources.
It's
yeah!
It's
just
that
we're
going
for
a
database
plus
a
small
small
ui
and
a
little
bit
of
yeah,
it's
just
a
small
micro
service.
Maybe
we
should
go
with
two
small
micro
services
that
talk
to
each
other
and
are
very,
very
small,
maybe
just
pinging
each
other,
and
then
we
can
also
showcase
the
capabilities.
A
A
B
B
Maybe
in
this
context
I
can
add
that
upgrading
captain
is
usually
done
with
the
captain
cli,
so
we
release
a
new
captain
version
every
four
to
six
weeks
approximately
and
there
you
can
usually
it's
just
a
captain
upgrade,
and
it
will
just
upgrade
your
captain
installation
and
move
all
the
services
to
its
latest
version.
If
there
are
new
versions
of
other
depending
services
released,
then
you
would
just
have
to
take
care
of
this
yourself.
A
A
B
Yes,
yeah
there
are
a
couple
of
things
going
on,
the
helm,
chart
will
be
generated
and
the
help
chart
will
be
applied
and
the
cli
will
wait
for
the
helm
chart
applied
to
for
the
helm
upgrade.
Actually,
I
think
it's
a
command
to
be
finished,
so
in
this
case
it
takes
a
while,
since
just
the
start
of
the
container
takes
a
couple
of
seconds.
So
normally
it's
this
command.
If
you
have,
I
have
a
very
small
go
application
that
I'm
using
sometimes
it's
called
the
potato
head.
B
It's
a
cncf
demo
project
and
with
the
potato
heads
this
command
finishes
within,
let's
say
five
seconds,
because
it's
very
small.
It's
started
like
the
startup
is
really
fast.
With
the
shopping
cart,
the
startup
is
a
little
bit
longer
and
and
slower
so
also,
this
command
just
waits
for
the
first
successful
deployment
in
the
first
stage.
So
it
won't
wait
until
it's
deployed
into
production,
but
it
will
just
give
you
the
feedback
if
it
could
be
deployed
in
the
first
stage,
so
it
finished
upgrading
the
chart.
A
All
right,
so
that
what
it
turns
out
then,
is
my
wild
idea
but
suppress
the
websocket.
We
actually
managed
to
time
that
rate
that
I
did
on
the
request.
It
failed.
So
go
me
thanks
all
right,
let's
go
back
to
our
tutorial,
so
we
have
done
both
of
those
and
we
should
be
able
to
verify
all
this
now.
So,
let's
try
that
one
more
time
there
we
go.
That
looks.
B
A
B
B
There
will
be
two
containers
because
we
will
also
have
the
steelside
car,
but
for
dev
we
decided
not
to
go
for
a
blue
green
deployment,
so
there
is
no
need
to
inject
the
istio
sidecar,
because
we
we
don't
need
this
traffic
shifting
between
blue
and
green
versions,
and
we're
only
going
for
this
in
staging
and
in
production.
We,
if
we
take
a
look
in
the
captain's
bridge,
there
should
already
be
the
link
to
the
service
available.
So
we
can
also
take
a
look
at
the
ui
of
this
very
beautiful
shopping,
cart,
actually,
yeah.
A
B
Do
we
want
to
do
that?
We
we
can
also
skip
this
part
as
we,
I
think,
what's
really
important
to
where
we
was
sorry,
I
think,
did
I
just
lose
you
for
a
second
okay,
so
I
think
what
what
will
be
interesting
to
take
a
look
at
is
how
we
can
connect
captain
to
prometheus
and
also
run
a
quality
gate
evaluation
with
data
from
prometheus.
Maybe
I
think
we
still
have
a
couple
of
more
minutes
left
in
the
stream
or
david.
A
A
B
Yeah
it
it
also
says
here,
so
what
it
does
is,
it
will
set
up
promethos
and
it
will
also
configure
prometheus
in
a
way
that
it
will
generate
the
scrape
chops
for
cards
in
depth,
staging
production
that
we
can
use
the
data
afterwards
and
if
we
would
have
set
up
already
the
slo
files,
the
qualitygate
files,
that
it
would
already
set
up
the
alert
manager
rules.
So
right
now
we
have
not
added
the
slo
file,
so
there
is
no
alerting
yet
since
we
have
not
defined
the
quality
gate
yet.
C
A
B
Yeah
we
can
go
for
the
next
and
here
sometimes
I
need
a
little
bit
of
explanation,
because
it's
the
prometheus
service,
that's
the
one
responsible
for
configuring
promethos.
If
you
don't
want
to
configure
prometheus
with
captain,
then
you
just
need
the
prometheus
sli
service
service
level
indicators.
In
our
case,
we
want
to
do
both.
So
we
have
the
prometheus
service
and
the
prometheus
sli
service,
so
this
service.
B
We
also
need
it's
a
service
that
we
also
deploy
into
our
captain
namespace
and
it's
just
responsible
for
querying
promethos
and
delivering
the
data
from
prometheus
to
captain
and
with
that
we
already
set
up
premier
voice
and
the
integration,
and
now
we
need
the
quality
gate
and
the
quality
gate
is
our
slo
file
it's
written
here
and
we
can
just
use
it
as
it
is,
and
it
will
check
basically
for
the
let's
say:
I
think
it's
for
the
response
time
we're
just
checking
for
the
response.
Time
of
phone
service.
A
C
A
B
Not
yet
there,
maybe
we
can
take
a
look
in
the
bridge.
Normally
the
bridge
gives
us.
If
we
go
to
on
the
left
side.
If
we
go
to
services,
then
we
can
take
a
look
directly
on
the
service
on
the
corrects
and
if
we
click
on
the
last
configuration
changed,
we
can
see
we.
The
configuration
changes
is
usually
the
part.
B
Oh,
it's
trying
to
already
fetch
the
slice.
Actually,
it's
trying
to
fetch
the
slis
and,
at
the
same
time
we
just
deployed
pro
methods.
So
I
think
there
is
a
kind
of
a
race
condition
here,
because
this
part
would
be
skipped
if
prometheus
is
not
installed.
So
normally
you
install
you
can
do
it
without
monitoring
and
then
it
will
just
just
be
skipped
display
this
time
we
just
we
deployed
pro
ethos,
but
we
have
not
added
already
the
the
other
parts.
B
A
B
Yes,
so
it's
working
in
this
way
that,
with
this
command,
we
are
deploying
cards
in
the
dev
namespace.
Then
captain
will
trigger
the
tests.
We
have
added
that
jmeter
file.
This
will
be
triggered
afterwards.
There
will
be
an
evaluation
based
on
the
slo
file.
We
have
not
added
the
slo
file
for
our
dev
environment.
We
only
added
it
for
staging,
so
in
dev
it
will
just
skip
the
quality
evaluation
for
staging
it
will
deploy.
It
will
trigger
the
tests.
B
We
have
added
the
load
gmx
file,
so
we
will
add
some
performance
tests
or
like
execute
a
couple
of
thousand
requests
against
this
shopping
cart,
and
then
it
will
do
the
evaluation.
We
have
defined
the
slo
file
and
we
have
defined
the
prometer
sli
provider.
So
this
will
actually
query
pro
methods
for
the
data
of
the
testing
time
and
then
come
back
with
the
data
provide
this
to
captain
captain
will
do
the
evaluation
based
on
the
slo
file
and
then
come
up
with
a
total
score.
B
That
is
actually
everything
that's
going
on
in
the
background,
when
you
just
send
this
one
command
captain-
and
I
think
at
the
beginning,
I
mentioned
that
captain
x
is
this
control
plane
and
the
orchestrator
of
these
tools.
So
it
connects
a
chain
meter
pro
methods
later
on
it
can
connect,
unleash
or
end
the
tower
to
trigger
remediation
actions.
So
there's
a
lot
of
things
that
are
sent
that
will
receive
events
or
send
events.
B
In
this
case,
there
is
not
a
lot
of
evaluation
because
we
don't
have
the
slo
file,
but
if
we
add
an
slo
file
to
to
our
def
state
def
environment,
then
we
will
see
it
actually
right.
Now,
it's
quite
fast.
The
gatekeeper
already
decided
that,
since
we
got
the
let's
say
if
there
is
no
slo
file,
capture
will
treat
it
as
as
a
let's
say,
a
past
evaluation,
so
it
moved
on
decided
to
move,
promote
it
to
the
next
stage
for
staging.
B
B
A
All
right,
nice,
I
like
it,
so
that's
just
going
to
take
another
minute.
Why
don't
we
tackle
another
quick
question,
so
the
question
is:
is
the
captain
cli
using
its
own
service,
account
and
tokens
when
talking
to
the
control
plane,
I'm
assuming
it
might
be
just
just
using
my
cube
context,
I'm
not
sure
what.
B
Yeah
we
we
are
using
our
own
service
account
in
the
beginning.
We
were
just
using
the
default
service
account,
but
that's
this
was,
I
think,
changed
with
two
versions
ago,
three
versions
ago,
we
changed
and
now
we're
using
the
captain
service
account.
So
you
have
a
little
bit
more
flexibility
and
control.
What
captain
is
actually
allowed
to
do.
B
C
A
A
A
So
I'm
going
to
trigger
this
new
event
based
on
those
changes
inside
of
the
repository
so
yeah,
let's
see
what
happens,
I'm
curious.
So
would
you
say
the
bridge
is
the
best
way
to
follow
along
a
progressive
rule
out
of
this
application.
Would
you
use
the
cli,
I
mean:
what's
you
what's
your
preference
as
someone
that
uses
this
dnd.
B
I
think
the
the
bridge
gives
most
details
because
if,
for
example,
if
we
can
take
a
look
in,
let's
say
in
the
bridge
on,
let's
go
for
a
previous
run,
maybe
where
we
can
see
a
little
bit
more
and
let's
probably
go
for
some
okay.
Maybe
we
don't
see
a
lot
of
data,
maybe
go
for
an
event
of
yeah
anyway,
careful
go
for
any
event.
B
On
the
very
right
hand,
side
there
is
this
computer
icon
or
laptop
icon,
and
here
it
gives
you
the
full
cloud
event
that
was
sent
to
captain,
and
if
you
have
a
quality
evaluation
or
a
sli
retrieval,
then
these
cloud
events
they
get
a
lot
of
information.
So
usually
you
have
all
this
information
you
have.
Also.
If
there
is
an
error
message,
you
should
be
able
to
see
it
there
if
the
sli
provider
sends
it.
B
But
if
there,
for
example,
if
there
are
any
tests
that
are
failing
or
if
there
are
some
service
level
indicators
fetching,
then
we
should
be
able
to
see
this.
We
should
see
all
this
data
here,
probably
if
we
close
this
window
and
go
to
the
test
finished
in
our
def,
maybe
in
the
previous
run
at
320
there
is
a
test
finished
event
on
the
in
the
dev
stage.
So
it's
a
little
bit
on
the
top,
and
maybe
we
can
see
here
yeah.
B
B
A
B
That's
good,
so
one
is
coming
up
and
the
other
one
is
being
terminated
since
we
we
don't
need
it
anymore.
That
also
means
that
now
the
tests
we
have
not
made
it
yet
to
production,
because
the
quality
gate
in
staging
never
was
not
successful
yet
so,
in
this
case,
we
could
not.
We
cannot
ship
anything
to
production
as
long
as
it's
not
validated
in
staging.
A
B
So
what
we'll
see
is
the
deployment
finished
and
after
the
deployment
is
finished
right
now
the
jmeter
tests
are
being
executed.
There
is
one
improvement
coming
in
the
bridge
that
we
will
indicate
also
that
now
tests
are
being
executed.
It's
a
little
bit
missing
here
this
information
because
we
just
see
the
deployment
is
finished
and
it
needs
some
background
in
the
captain
that
we
know.
Okay,
every
time
the
deployment
is
finished,
captain
will
trigger
the
tests.
This
information,
unfortunately,
is
missing
in
the
bridge
yeah.
B
A
No,
this
is
this
is
look
at
this,
it's
starting
to
click
with
me
now
I
can
see
and
I'm
starting
to
understand
this
ui
kind
of
through
me
at
first,
but
you
know
what
we
can
see
is
the
this
conflict
changed
event
here
and
then
we're
actually
it
just.
I
don't
know
how
I
missed
it,
but
you
know
we
have
our
first
event
here
and
then
this
is
okay
for
development
environment.
We're
going
to
do
a
deploy,
we're
going
to
run
our
tests.
You
know,
we've
got
our
sli
stuff
going
on
here.
A
It
does
some
evaluation
and
you
can
actually
see
it
move
on
to
staging
like.
I
can
actually
start
to
see
how
this
slows
together.
Now
it's
starting
to
make
much
more
sense
to
me.
In
fact,
there
we
go.
There's
our
production.
Now,
events
kicking
off,
so
I've
had
the
light
bulb
moment.
I
now
understand:
what's
going
on.
B
Okay,
so
we
could
see
yeah
and
the
evaluation.
What
what
did
say
could
we
did?
We
get
a
good
score
in
the
evaluation?
That's
pretty
pretty
good,
so
we
got
basically
a
pass
with
90,
which
is
no
actually
without
a
hundred
percent.
So
what
what
we've
done
here
is,
or
what
captain
has
done
is
it
was
triggering
the
tests.
The
tests
have
been
finished.
B
It
was
reaching
out
to
prometheus
and
to
to
query
the
data
for
the
exact
testing
time
frame,
and
now
we
can
see
that
the
response
time
is
is
meeting
our
requirements.
So
that's
that's
pretty
cool
and
now
we're
moving
on
to
production
in
production.
It's
doing
the
same,
the
same
game
with
deploying
trying
to
execute
tests.
Actually
in
production
we
have
not
defined
any
tests.
Usually
it's
our
end
users
doing
testing,
let's
call
it
for
us
in
production,
but
yeah.
B
A
B
In
this
case,
yeah
we
are
finished.
We
it
would
have
been
possible
to
just
bring
carts
on
the
on
the
browser
and
and
take
a
look
when
there
is
the
traffic
switch
actually
from
one
version
to
the
other.
We
are
doing
the
blue
green
deployments
with
with
istio,
so
that
means
we
are
deploying
the
new
version.
Once
it's
ready,
we
are
moving
the
traffic
to
this
new
version
and
we're.
B
If
we're
going
back,
then
we
are
first
moving
the
traffic
to
the
previous
version
and
removing
this
so
there's
no
down
time
or
anything,
that's
actually
what
we
already
know
from
kubernetes,
but
it's
also
in
this.
This
way
we're
using.
We
are
basically
implementing
a
little
bit
by
ourselves,
but
we
made
sure
that
there
is
no
downtime
from
switching
from
one
version
to
the
other.
B
B
So
what
we've
seen
right
now
is
a
blue
green
deployment,
the
multi-stage
deployment
with
captain
with
helm,
with
using
cloud
events
with
having
istio
with
having
prometheus.
I
think
we
have
installed
a
lot
and
had
a
lot
of
technology,
although
the
parts
that
once
set
up
it's
basically
just
the
captain,
cli
that
you
need,
with
the
captain,
send
event
a
new
artifact
to
trigger
a
new
deployment
or
configure
your
monitoring
to
to
set
this
all
up
asset.
B
It
just
takes
a
while
for
the
the
second
version
to
run
all
its
tests,
but
we
have
also
added
the
chimita
tests,
I'm
happy
to
to
stay
and
then
move
through
all
the
other
parts
of
the
tutorial,
but
yeah.
If
you
want
to
wrap
up
here,
that's
also
totally
fine,
and
maybe
we
can
do
a
follow
up
and
taking
a
look,
maybe
on
the
auto
remediation
parts
of
captain
later
on,
because
this
is
basically
once
we
have
things
up
and
running
in
production.
A
I
have
no
idea
so,
let's
decide
what
we
want
to
do.
What
I
want.
What
I
want
to
be
careful
with
is
I
I
don't
want
to
rush
anything
that
we
show
so
that
people
don't
get
a
good
understanding
of
it,
but
at
the
same
time,
I'm
happy
to
make
sure
that
we,
you
know
we
finish
off
what
we
started
now,
so
we
can
definitely
schedule
something
else
and
we
can
cover
more
of
the
captain
features
you're
saying
if
we
apply
the
slow
one.
A
What
that's
going
to
do
is
show
us
that
the
tests
fail
in
the
staging
phase,
which
will
block
the
deployment
of
production.
So
why
don't
we
trigger
that
now
we'll
see?
If
anyone
has
any
questions-
and
we
can
do
a
little
bit
of
a
summary
where
we
wait
for
that
to
happen,
and
then
we
can
schedule
a
follow-up
and
we
can
dive
even
deeper
into
anything
that
we
haven't
covered
in
particular,.
B
B
A
Version,
so
that's
what
typically
happened
and
my
ci
system
said:
hey,
we
have
a
new
artifact.
We
just
built
this
new
release.
We
tagged
it
with
zero.
Eleven
two
we
send
the
event
to
captain
what's
happening
here.
Is
that
because
captain
is
an
event-driven
system,
it's
a
text
has
changed.
So,
let's
yep
there
we
go,
we
mean
we
can
see
here
and
that's
now,
gonna
start
to
prepare
the
deployment
to
our
development
environment
and
I
just
want
to
make
sure
we
tile
this
together.
A
A
I
just
want
to
make
sure
we
we
cover
this
again.
So
we
have
our
development
environment,
which
has
a
deployment
strategy
of
direct
and
a
test
strategy
of
functional.
So
what
that
means
is
the
deployment
strategy
will
always
deploy
whenever
there's
a
new
artifact
and
the
testing
strategy
means
it's
going
to
run
the
functional
tests
and
if
they
pass
it
won't
roll
back.
The
deployment
is
my
understanding
of
that
correct.
B
A
B
In
this
case,
no,
so
if
you
do
a
direct
deployment,
it
won't
roll
back
anything
what
it
will
do
is
it
will
block
it
from
from
move
on
to
the
next
stages.
Obviously,
so,
if
the
functional
tests
fade
or
if
some
quality
gate
may
be
responding
on
the
or
checking
the
response
time
or
the
throughput
or
the
number
of
outgoing
service
calls
or
whatever,
if
there
is
a
quality
gate
that
fails,
it
will
block
it
to
move
to
the
next
stage
with
a
direct
deployment
it
will
run.
A
All
right,
okay,
so
guys
that
makes
much
more
sense.
Then
we
have
our
staging
environment,
and
this
time
we
have
an
approval
strategy
of
both
automatic
on
a
path
and
automatic
on
a
warning.
So
regardless
it's
going
to
do
its
best
as
long
as
the
test
path
is
going
to
promote
that
to
the
next
stage
and
our
testing
strategy
here
isn't
functional,
but
performance
now
are
these
test
strategies.
Is
this
related
to
the
gmx
configurations
that
we
applied
earlier.
B
Yes,
it's
it's
related
also
to
the
chain
meter
service.
So
it's
basically
an
indicator
which
kind
of
tests
to
execute
the
cheap
meter
service.
They
also
have
a
configuration
file,
but
it's
not
needed.
There
is
no
additional
configuration
file
needed,
so
we
only
added
the
jmx
file,
which
are
basically
already
the
test
instructions.
A
B
Canary
is
not
yet
supported.
Everything
is
prepared
in
the
background,
so
with
istio.
It
will
be
very
easy
to
shift
the
traffic
not
only
from
100
to
00
but
doing
like
100,
then
80
20,
70,
30,
50
50,
whatever
you
want
to
do,
it's
not
yet
implemented,
but
this
is
something
that's
also
coming
in
the
next
stages.
B
A
So
one
of
the
things
we
did
at
the
start,
which
was
really
subtle,
but
I
think
is
also
important-
is
that
I'm
not
going
to
I
better
find
the
commander,
but
when
we
on
board
dates,
did
we
did
we
overrate
the
deployment
strategy
on
one
of
these
yeah?
We
did
here
right,
yeah,
yeah,
so
for
individual
services.
I
can
actually
say
you
know
I
I
don't
want
a
blue
green
deployment
of
this,
like
I
guess
the
database
is
a
really
good
example
and
probably
why
it's
included
in
the
tutorial.
A
B
B
There
is
no
in
the
metadata
file.
You
won't
really
see
it.
We
are
planning
to
also
include
this
when
you're
doing
a
captain
get
services
or
captain
get
projects
in
the
cli
that
we're
also
including
everything-
that's
that's
really
running
in
the
cluster
that
we
provide
all
this
information
directly
with
the
cli
or
with
the
api
with
by
the
api.
You
can
already
query
all
the
events
that
are
stored
and
running
through
captain
and
also
stored
in
captain
with
the
cli.
B
A
C
B
Exactly
so,
we
know
it's
already
deployed
the
red
version
and
we
know
that
there
are
the
tests
running.
As
said,
I
would
assume
they
still
take
a
couple
of
minutes,
so
normally
it's
around
five
to
ten
minutes,
normally
like
eight
minutes.
So
in
a
couple
of
minutes,
we
should
see
if
the
tests
have
been
finished
successfully.
So
that's
also
one
of
the
of
the
the
nice
parts
of
this
integration
that
the
cheat
meter
service
is
also
indicating
if
the
tests
have
been
finished
successfully.
B
So
if
the
jmeter
file
or
neoload
sorry,
if
the
gmeter
tests
or
the
near
load
tests
or
whatever
test
integration
you're
using
if
this
is
failing,
then
captain
will
get
this
information
and
will
also
mark
the
quality
gate
evaluation
as
failed,
since
it
could
not
even
execute
the
tests.
If
the
tests
have
been
executed
successfully,
then
capital
will
go
ahead
and
evaluate
the
quality
gate
and
our
quality
gate
is
very,
very
small.
We
only
have
the
response
time
in
the
95th
percentile.
B
You
can
add
more
and
more
sl
sli's,
so
we
have
seen
quality
gates
with
like
50
slis
that
are
combined
together
and
the
total
score
is
generated
and
they
range
from
number
of
outgoing
service
calls
to
memory.
Consumption,
cpu,
saturation
response
time,
throughput
all
these
different
metrics
they
are
used,
and
you
just
define
them
once
in
the
slo
file
and
in
the
slo
file
we've
that
we've
seen
also
earlier,
it
doesn't
say
which
service
belongs
to.
B
So,
if
you
have
an
slo
file,
that
is
like
your
standard
configuration
of
your
quality
objectives,
then
you
can
reuse
it
for
all
of
your
microservices
and
reusing.
Is
is
easy
in
this
way.
Since
you,
you
can
define
absolute
thresholds,
but
you
can
also
define
relative
ones,
and
I
always
like
to
have
a
combination
of
both
that
I
say:
okay,
it's.
The
error
rate
has
to
stay
lower
than
five
percent,
but
it's
also
not
allowed
to
increase
more
than
25
to
the
previous
bills.
A
B
But
so
I
can
combine
a
relative
and
absolute
value
same
for
for
all
the
other
metrics,
and
in
this
way
I
think
it's
it's
very
easy
to
reuse
it
also
for
other
services,
since
they
don't
have
actual
the
name
of
the
micro
service
or
the
the
stage
in
the
slo
file
itself.
It's
just
how
you
added
them
to
to
captain,
via
the
cli
or
by
the
api.
B
Yeah
exactly
the
next
event
should
be
this
sli
retrieval
so
and
sli
retrieval,
as
we
know
from
prometho,
is
it's
it's
very
fast?
Usually
you
get
this
data
close
to
real
time
from
prometheus,
so
other
solutions.
They
take
a
little
bit
more
time
to
digest
and
to
to
operate
on
this
data.
But
if
we
ask
prometheus
for
for
data,
we
get
it,
we
retrieve
it
pretty
fast,
and
then
we
should
see
the
slide.
B
Retrieval
sli,
which
we've
done,
and
the
evaluation
of
the
quality
gate
pretty
soon,
and
we
should
also
see
then
the
action
that
is
that
is
taken
by
captain
upon
this
quality
gate
evolution.
So
if
captain
allows
you
to
promote
it
to
the
next
stage
or
if
it
will
be
rolled
back
to
the
previous
version-
and
we
remember
that
the
previous
version
was
the
green
version,
so
we
will
see
what
happens.
A
A
B
A
Yes,
there's
there's
just
so
much
going
on
there,
but
I
think
the
flexibility
and
the
way
that
we
can
encode
essentially,
which
is
you-
know,
sre
playbooks,
to
a
certain
degree
of
how
we
want
our
applications
to
handle
failures,
how
we
want
to
be
able
to
test
them
across
environments
and
and
have
captain
orchestrate.
All
of
that,
for
us
is
a
really
really
cool
thing.
Call
me
pretty
much
impressed
with
what
we've
seen
here
today
and
based
on
what
we
have
in
this
tutorial.
A
You
know,
let
me
pull
that
back
up
again,
my
stupid
tap
thing.
We
still
got
40
minutes
worth
of
other
things.
We
could
be
looking
at
as
part
of
the
field
tour.
So
maybe,
if
you
could
just
take
you
know
a
minute
or
five,
maybe
we
should
just
reschedule
something
to
not
do
that
yeah.
Let's
do
that.
I
think
we've
covered
so
much
today.
Is
there
any
final
thoughts
you
want
to
leave
us
with
and
we'll
come
back
to
this
another
day.
B
I
think
it
was
a
very
amazing
journey
that
we
actually
we
did
a
little
bit
of
debugging
already,
and
we
took
a
look
at
the
the
devops,
sorry,
the
the
git
ups,
the
github's
approach
of
captain.
I
think
that
was
very
fascinating
to
also
also
for
me
to
see
this.
How
fast
we
we've
done
this
changes
of
the
small
hiccups
in
the
helm,
charts
and
yeah.
B
A
B
B
Sorry,
I
I
would
be
happy
to
to
join
you
again
and
to
take
a
look
at
the
auto
remediation
part
of
captain.
Once
we
have
everything
up
and
running,
so
we
can
just
do
one
deployment,
send
it
all
the
way
through
production
and
then
play
a
little
bit
with
the
auto
remediation
parts
where
captain
is
triggering
animal
playbooks
or
feature
flagging
frameworks,
and
these
kind
of
things
so
to
also
see
once
it's
in
production,
how
how
captain
can
help.
A
Yeah
definitely
we
will
start
out
after
after
this,
but
I
think
what
we've
shown
today
is
just
the
progressive
delivery.
Stuff
is
really
cool.
I
hope
people
get
an
opportunity
to
play
with
us
and
we'll
come
back
with
more
episodes
and
and
and
we'll
take
a
look
at
all
those
other
features
as
well.
So
thank
you
again
for
joining
me
today.
It
was
really
fun
to
kind
of
walk
through
this
and
see
how
it
all
clicks
together
and
how
it
works.
The
really
cool
software
and
thanks
for
your
efforts,
keep
it
up.