►
From YouTube: Progressive Delivery with Keptn
Description
In this talk Brad McCoy (CNCF/CDF Ambassador, Head of Cloud Engineering at Moula) and Adam Gardner (Automation Architect at Dynatrace) will talk about how to use Keptn to perform progressive delivery and how Keptn can help us in CI/CD pipelines.
Meeting link: https://community.cncf.io/events/details/cncf-keptn-community-presents-progressive-delivery-with-keptn/
This talk is a recap of the Cloud Native Guatemala Meetup in Spanish: https://community.cncf.io/events/details/cncf-cloud-nativegt-presents-progressive-delivery-con-keptn/
B
C
B
B
B
A
B
D
B
B
Hi
all
welcome
to
the
captain
user
group.
We
have
a
first
ever
user
group
meeting
in
the
epoch
and
immediate
amazon
thanks
a
lot
for
bread
to
brett,
mccoy
and
dumb
garter
to
for
joining
us.
Today
we
have
a
presentation
about
progressive
delivery
with
captain
and
during
this
presentation
you
will
learn
a
lot.
How
captain
is
used
on
the
field
and
after
that
please
stay
on
the
call.
We
will
have
an
opportunity
to
discuss
anything
about
the
progressive
delivery
with
captain
or
captain
in
general.
B
So
once
the
official
part
of
the
presentation
is
over,
we
will
have
a
discussion
and
everyone
can
get
the
voice
permissions
so
that
we
can
have
a
live
discussion
with
everyone
for
connade.
During
the
presentation
please
use
cornea,
so
I
will
be
monitoring
quinny
in
the
chat
and
also
we
have
youtube
live
today.
So
I
will
be
attracting
questions
there.
This
is
our
first
attempt
with
youtube
live
so
just
in
case
apologies
if
something
goes
wrong,
but
yeah
thanks
a
lot
for
watching
us
today
too.
So
what.
D
A
Yeah
adam
garner,
I'm
one
of
the
captain
contributors.
I
guess
I've
run
a
fair
few.
Captain
services
get
involved
starting
to
get
involved
in
the
core
micro
services
as
well,
which
is
interesting
but
yeah.
It's
it's
a
it's
a
good
project.
I
I
enjoy
it
and
the
the
thing
I
like
most
about
it
obviously
is:
is
the
community
everyone's
very,
very
friendly
and
open
to
help?
A
D
Yeah
and
my
name's
brad
I
I
guess
I
unofficially
work
with
adam.
You
know
working
on
open
source,
it's
pretty
lucky
that
you
know
we
both
have
the
same
interest
and
passion,
so
we
thought
I
find
myself
talking
to
adam,
sometimes
more
than
other
people
at
my
work,
so
we've
been
working
a
lot
with
other
cd
captain
and
portelius
as
well
so
sort
of
how
I
came
about
captain
was
we
had
a
use
case.
D
Well,
I
want
to
have
this
in
my
company
as
well,
but
we
had
a
use
case
where
there's
a
cd
foundation
project
called
ortillius
and
they
were
looking
for
a
github
solution
and
they
needed
other
tools
and
capabilities
to
help
them
achieve
that
goal.
So,
essentially,
what
we
wanted
is
we.
We
wanted
a
get-off
solution
that
you
know
you
can
deploy
using
the
getups
paradigm
and
things
that
we
started
to
see
is
that
we
need
a
little
bit
more.
So
we
wanted
to
do
more.
D
B
A
But
I
may
as
well
describe
what
he's
going
to
describe
so,
on
the
one
hand,
we've
got
argo
and
argo.
Obviously,
we've
got
a
github
repo
with
our
code
in
it
we've
got
oracle.
Looking
at
that
continuously.
Basically,
so
any
changes
you
may
can
get
are
built
and
reflected
in
argo
and
then
argo's
going
to
deploy,
do
the
deployment
and
then
we're
gonna.
Actually,
once
the
deployment
is
done,
you
get
other
there's
brad,
so
he
can.
He
can
talk
through
it.
Now
there
we
go.
B
B
D
So
here
the
first
step
of
our
journey
was
to
learn
agrocity,
this
I'll
talk
about
this
more,
but
it
was
a
good
journey
in
learning
because
we
wanted
to
use
an
automated
approach
to
this
as
well.
So
what
I
have
is
a
devops
cluster,
so
I
use
so.
I
can
get
this
running
in
a
click
of
a
button,
so
I'm
using
terraform
to
provision
my
this
particular
one
runs
in
azure
for
ulteriors,
but
we
can
run
it
in
gcp
or
aws
as
well.
D
D
The
secret,
because
you
can
encrypt
it
with
the
cluster
and
then
after
that
we
found
that
you
know
that
was
a
bit
imperative
as
well,
because
you
still
had
to
run
a
cli
command.
I
think,
last
month,
though
they
just
changed
it
to
integrate
with
helm.
So
I
have
to
check
that
out.
But
at
the
moment
I'm
now
using
external
secrets,
which
is
sort
of
the
same.
But
I
can
leave
some
of
my
secrets
in
the
keyboard,
the
terraform
spins
up
and
then
I
can
reference
that
in
my
as
a
external.
C
D
D
So
the
cool
thing
about
argo
is
that
once
you
install
argo,
you
can
actually
argo
can
take
care
of
itself,
so
it
can
actually
change
itself
in
motherboard
itself,
which
is
really
cool,
so
the
things
in
this
case
I'm
using
as
your
front
door
to
as
a
entry
point
into
this
particular
cluster.
The
main
reason
is
because,
if
I
want
to
change
the
dns
records,
I
have
to
ask
the
linux
foundation,
so
that
can
be
annoying.
D
D
D
C
D
It
so
essentially
do
you
want
to
talk
a
little
bit
about
the
components
that
will
drop
me
to
I'm
happy
yeah.
So
the
thing
we
have
the
concept
of
the
bridge
so
essentially
that's
the
the
ui
where
you
can
run,
which
we'll
show
you
later
on
and
the
we
have
approval
service
lighthouse
service.
You
know
these
are
standing
with
the
standard
health
chart
and
then
you
can
you
can
the
cool
thing
is
that
there's
a
great
community
with
add-ons?
D
C
D
Jr
servers,
I
think,
trivia
there's
more
coming
every
day
and
you
can
see
here
that
we
actually
have
the
autelia
service
which
we're
working
on
at
the
moment.
So
that's
written
in
golang
and
that's
essentially,
it's
use
this
template,
but
it's
like
a
fork
of
the
template
and
then
we
can
update
the
logic
in
the
going
to
accept
card
events
to
to
talk
to
captain.
D
So
you
can
also
use
things
like
the
the
workbook
service
and
I
think
there's
one
generic
script
service
or
I
don't
know,
what's
called
accountability.
But
essentially,
if
you
don't
want
to
build
your
own
service,
then
you
can
use
easier
ways
to
to
talk
to
other
services.
So
yeah.
This
is
yeah.
As
we
said,
this
is
lighthouse
service.
D
D
So
one
thing
when
I
first
started
was
that
I
I
wanted
all
of
this
to
be-
and
I
wanted
all
of
this
to
be
shown
here
as
an
app
and
because
I
wanted
to
get
up
so
I
didn't
want
to.
I
was
doing
a
tube
ctl
apply
for
my
ingress,
so
I
then
did
a
pull
request
to
get
them
to
add
the
english
to
the
kitchen
chart,
and
then
I
found
that
I
actually
wanted
more
more
add-ons
as
well.
So
that
brought
me
to
a
part
in
my
research
where
I
started
using
customized
home.
D
D
D
What
I
do
is
in
the
customization
on
the
base.
I
can
say
I
want
this
version
of
captain.
You
know
run
this
home
chart
from
here
and
then
all
my
values
that
I
want
to
override.
I
can
put
here
so
you
can
see
here
that
I'm
running
my
ingress,
so
that
will
essentially
be
able
to
connect
to
the
virgin
api
and
then
also
the
course
thing
is
as
well
that
you
can
have
other
home
charts
as
well,
so
you're
sort
of
packaging
it
into
the
same
app.
D
So
that's
a
if
you
have
any
questions
on
that.
Please
let
me
know
it's
quite
a
lot
to
take
on
to
start
with,
so
so
that's
sort
of
my
journey
and
how
I'm
installing
captain.
So
it's
you
know,
budding
click
from
splitting
up
everything
in
the
cloud,
the
queen's
cluster
captain
and
then
at
the
moment
I'm
I'm
sort
of-
I
guess,
watching
thomas
as
he
makes
the
get
ops
operator
as
well.
So
once
the
cid
is
ready
for
that.
D
I
will
simply
put
that
in
here,
as
well
as
a
dependency,
and
then
that
will
install
the
get
ups
operator
and
then
I
can
start
adding
my
shipyard
file.
So
adam
can
explain
the
shipyard
a
little
bit
better,
but
what
the
shipyard
is
is
it's
it's
a
way
of
defining
our
workflow
and
the
captain.
So
it
is
the
concept
of
stages,
sequences
and
tasks
so
yeah
in
this
particular
instance.
What
we're
looking
at
now
is.
This
is
what
I
want
to
try
for
my
use
case
at
the
moment.
D
What
I've
got
working
as
well
is
something
called
argon
notifications,
so
I'm
gonna.
What
argo
notifications
do
is
that
when
I
do
a
pr
to
the
main
branch,
that's
going
to
start
triggering
my
workflow,
so
actually
argo
will
poll
get
and
that
will
say
okay.
This
has
changed
like
let's
say
I
just
a
simple
thing
like
I,
I
have
a
new
docker
image.
You
know
with
my
code,
so
this
docker
image
will
then
I'll,
say.
Okay,
I
want
to
go
test
this
in
a
test
environment.
D
D
You
know
redeploying
this
code,
the
new
version,
then
it's
going
to
send
back
a
notification
and
that
notification
is
going
to
be
a
cloud
event
captain
to
trigger
a
sequence.
So
you
can
see
here
that,
let's
see
like
the
event
test
delivery
finished,
but
so
what
I
can
do
is
actually
trigger
that
and
then
and
then
what
I
want
to
do
is
is
a
tool
that
I'm
looking
at
at
the
moment
called
tesco
and
what
that
does
is
that's
it's
essentially
a
you
know.
You
can
run
your
postman
api
collection,
etc.
D
D
D
Essentially,
orterius
is
going
to
catalog
that
metadata
and
then
and
then
it's
going
to
say
yes
well,
we've
done
true
testing,
it's
automated
testing
in
the
quality.
So
that's
going
to
say:
okay,
that's
good
for
the
next
environment
and
then
it
will
proceed.
It
will
do
the
commit
and
then
r
will
pick
it
up
and
then
it
will
go
to
the
next
sequence
as
well.
D
So
that's
essentially
what
we're
working
on
at
the
moment.
The
reason
I'm
using
the
argo
notification
service,
I
could
use
other
rollouts,
but
we're
also
thinking
that
a
service
mesh
would
do
that
capability
as
well.
So
we
we're
installing
link
of
the
at
the
moment
to
to
get
those
different
deployment
strategies.
D
So
I
guess
at
the
moment
we're
testing
a
lot
of
different
things,
and
this
is
the
fun
part
of
researching
as
you
can.
You
know
you
can
plug
tools.
You
know
plug
and
play
where
you
want.
So
at
the
moment,
I'm
going
to
try
with
anything
for
a
service
mesh
for
my
deployment
strategy
and
then
I
can
try
I'll
go
rolex
as
well.
There's
actually
a
tutorial
on
captain
algorithms
as
well
on
the
captain.sh
website.
I
believe
so
quite
a
lot
going
on
there
did
you
want
to
comment
on
any
of
that.
D
A
Yeah,
so
you
can
see
there,
we've
got
the
configuration
service,
which
is
one
of
the
core
captain
micro
services,
there's
the
helm
service,
the
jamie
disservice,
and
so
on
and
as
brad
says,
you
can
write
your
own
services.
So
if
there
is
a
tool
out
there
that
you
like
you,
can
bring
that
tool.
That's
that's
one
of
the
core
things
about
captain
is
that
it's
not
opinionated
in
what
tooling
it
uses.
A
So
how
this
works
is,
if
you
could
flick
to
the
shipyard,
glad
sure,
so
you
define
your
shipyard
and
that's
basically
your
blueprint
of
what
your
world
looks
like
to
captain
and
now
what
actually
happens
behind
the
scenes
is
that
cloud
events
are
generated
for
this
automatically
for
you
behind
the
scenes.
So,
for
example,
you
as
a
human
or
another
tool
in
this
case
we're
taking
argo
and
argo
is
doing
its
thing
and
notifying
captain,
and
what
argo
will
do
is
actually
trigger
the
sequence
there.
A
So
you
can
see
online
nine,
there's
the
delivery
sequence
in
the
test
stage
and
then
so
that's
the
cloud
event
that
we
fire
in
to
tell
captain
to
start
it's
its
workflow
captain.
Then
goes
away
and
says:
okay,
I
need
to
trigger
the
delivery
sequence.
What
do
I
do?
Well,
I
need
to
trigger
the
deployment
task
on
line
11..
A
So
after
you've
triggered
the
sequence
captain
is
going
to
manage
and
orchestrate
the
rest
for
you
now
brad
is
going
to
have
to
have
a
tool
listening
for
that
deployment
triggered
cloud
event
that
captain
is
going
to
generate
and
send
out
so
that
tool
that's
up
to
brad.
He
can
bring
whatever
tool
he
wants.
As
soon
as
that
tool
finishes,
it's
going
to
signal
back
to
captain
to
say
I've
done
the
deployment,
it's
finished
and
here's
some
results
and
then
captain
says
okay.
A
I
know
the
deployment
is
now
finished,
because
this
tool
has
told
me
now:
I'm
gonna,
you
know,
and
the
process
repeats
the
captain
generates
that
release
event
that
cloud
event
and
some
other
tool
listens
for
that
event
and
so
on
and
so
forth.
So
that's
what
I
wanted
to
try
and
map
together
is
the
idea
of
the
captain
services
and
the
shipyard
and
how
they
kind
of
fit
together
and
notice.
We're
not
actually
mentioning
tooling
in
here.
We're
not
saying.
Do
a
deployment
with
tool
x
and
that's
deliberate
because
those
services
are
hot
swappable.
A
So
if
you
don't
like
you're
the
the
tool
that
you
use
for
deployment,
if
a
new
tool
comes
along
tomorrow,
you
can
just
switch
out
that
captain
service
and
everything
else
about
your
environment
stays
the
same.
So
we
can
as
we're
experimenting
with
this
brad,
and
I
can
really
just
swap
tools
and
see
which
one
is
the
best
fit
for
his
workflow
and
you
can
have
different
tools
responding
in
different
environments,
so
we
could
have
test
cube
responding
in
the
test
environment.
We
could
have
j
meter
responding
in
the
uat
environment.
D
That's
a
good
point
because,
like
for
example
in
uat,
you
might
have
more
sort
of
like
for
like
production
data,
so
it
would
make
more
sense
to
run
january
just
in
uit,
and
it
doesn't
necessarily
need
to
be
test
because
test
is
more
traditionally,
you
know
sort
of
older
than
the
uat
environment,
so
yeah
and
and
because
we're
very
much
in
the
research
phase,
it
is
a
great
yeah.
It
is
good
that
we
can
swap
tools
out,
as
we
see
what's
the
best
way
to
do
this.
D
A
A
E
D
D
A
A
So
basically,
he
here
he's
saying:
whenever
the
delivery
sequence
finishes
in
the
test
stage,
I'm
going
to
start
the
delivery
sequence
in
the
uat
stage,
so
he's
chained
those
two
together.
So
it
starts
to
look
a
little
bit
like
a
pipeline,
but
remember
we're
not
actually
building
tooling
integrations
in
in
this
part,
so
my
first
thought
there
would
be
as
soon
as
we
finish
the
prod
delivery.
A
D
C
D
I
recently
watched
andy
and
I
think
his
name
was
daniel
from
cosplaying,
that
one
of
their
talks
on
using
captain
and
cosplaying
is
possibly
you
know
the
concept
of
a
remediation
task
with
if
azure
was
down,
then
to
you
know
using
crossplay
which
people
don't
know.
What
crossbar
is
it's
essentially,
infrastructure
is
code
declared
and
including
these
manifest
files
that
that's
using
get
ups
as
well.
So
I
I
want
to
start
experimenting
with
cross
playing
as
well.
I'm
doing
remediation
for
that.
D
To-
let's
say
I
don't
know
some
service
from
israel
goes
down,
then
we
can
then
trigger
remediation
to
go
spin
everything
up
and
go
to
aws,
or
my
next
task
as
well
is
because
this
is
the
devops
cluster.
I
want
to
use
cluster
api
so
for
my
environments,
I
want
to
be
able
to
use.
You
know,
get
ups
to
be
able
to
spin
up
my
other
clusters,
my
environment
clusters
as
well.
So
there's
lots.
B
D
B
D
A
That
so
this
is,
this
is
basically
the
ui
that
you
get,
and
I
remember
all
of
all
of
the
output
is
driven
by
cloud
events.
Now
you
get
the
raw
cloud
events.
Obviously
there
is
an
api
behind
all
of
this
that
you
can
interrogate
to
retrieve
the
cloud
events,
but
of
course
they
are
also
available
in
the
ui,
but
the
ui
makes
it
nice
and
easy
so
the
way
the
quality
gate
works.
A
You
obviously
give
it
your
service
level
indicators
which
are
effectively
the
metrics
that
you
want
to
look
at
so
in
this
case
we're
looking
at
authentication.
You
know
the
load
time
of
the
home
page
on
the
store
booking
page
in
this
case,
and
then
you
give
it
some
thresholds
or
your
service
level
objectives.
So
you
can
see
here
that
I'm
saying
okay,
if
my
authentication
endpoint
is
less
than
10
milliseconds
responds
in
less
than
10
seconds
and
it's
within
20
of
a
previous
set
of
tests.
A
Then
it's
a
pass
criteria.
If
it
is
not
a
past
crisis
here,
and
then
it
may
be
a
warning
criteria
and
this
one
is
less
than
20
milliseconds
and
then
obviously,
if
it's
anything
above
the
warning
criteria,
then
it's
a
fail
for
that
individual
metric.
So
every
single
metric
gets
its
own
score
and
then
those
those
scores
are
summed
together
to
give
you
this
score
here,
which
is
the
overall
result
of
the
quality
game.
So
in
this
case
all
of
my
metrics
were
green.
A
They
all
passed
so
my
quality
gate
as
a
whole
passes.
So
if
you
think
about
brad's
workflow
he's
got,
argo
he's
got
the
quality
gate
at
the
end.
This
is
the
kind
of
output
he
would
get
and
then
he
would
get
a
decision
back
from
captain
to
say
is
that
artifact?
Is
that
thing
that
we've
just
deployed
you
know
not
only
to
the
liveness
and
the
readiness
probes
and
the
pod
spins
up,
but
actually
is
the
performance
of
this
acceptable?
Can
users
make
a
booking?
A
Metrics
can
be
anything
they
can
be
business
relevant,
they
can
be
security.
Vulnerabilities
to
captain
captain
doesn't
really
care.
It's
it's
a
metric
that
you
are
interested
in,
so
you
get
a
result
and
you
can
then
we
can
use
that
result
to
decide
what
we
do.
So
if
we
could
use
that
to
automatically
migrate
or
progress,
the
the
artifact
into
the
following
stage
or
we
can
just
use
it
as
a
notification,
just
send
a
message
into
slack
to
say:
I've
run
a
quality
gate
in
uat
and
it's
it
passed.
A
D
C
D
Things
like
things
we
care
about.
Luckily
time
mean
time
to
restore
it'll,
be
really
cool
to
capture
all
of
that
stuff
as
well,
and
then
show
that
in
grifana
your
devops
metrics
and
then
you
can
see
how
you're
improving,
where
you
know,
and
just
really
how
successful
that
is.
So
that
would
be
a
cool
one
to
to
look
at
down
the
line
as
we,
you
know,
mature
the
solution
as
well.
A
No
I've
stopped
sharing,
but
hopefully
you
can
remember
the
screen.
Basically,
you
get
the
so
you're
going
to
have
a
metric
back
end
behind
this
you're
going
to
have
dynatrace
or
prometheus
or
datadog
or
splunk
or
whatever,
wherever
you're
pulling
your
metrics
from
and
obviously
you've
you've
got
the
metric,
and
you
know
how
you
define
those
because
it's
defined
as
code
in
an
sli
yaml
file,
so
you
can
easily
jump
into
whatever
tool,
you're
using
and
say.
Aha,
this,
my
authentication
endpoint
was
was
too
high,
for
example,.
A
A
E
Hey
folks,
can
I
quickly
add
something
to
this.
This
is
andy
because
we
had
a
similar
discussion
yesterday
in
our
user
group
meeting
with
rifason
software,
where
they
have
shown
the
automated
validation
of
their
online
banking
software
and
what
we
we
had
the
same
discussion
and
what
we
proposed,
and
I
already
gave
that
feedback
to
the
the
captain
team,
especially
johannes,
that
an
extension
to
make
this
possible
the
drill
down
from
the
heat
map
to
the
to
a
dashboard
would
be
that
the
sli
provider
should
not
only
return
the
actual
value
of
each
metric.
E
That
is
queried,
but
also
a
link
to
let's
say
if
this
is
a
metric
coming
from
prometheus,
then
you
know
it
could
return
a
link
to
a
grafana
dashboard.
If
the
metric
comes
from
dynatrace
and
the
metric
comes
from
a
pure
path
from
our
distributed
trace,
it
could
also
return
a
link
to
the
puppet
dashboard
directly
for
that
distributed
trace.
So
the
the
idea
was
that
to
discuss
an
extension
to
the
sli
provider
that
it
not
only
returns
a
value
but
also
a
link
to
then
do
the
troubleshooting
or
the
you
know,
deep
dive.
D
D
E
E
The
other
thing
we
need
to
do-
and
I
think
this
is
all
of
our
duty-
is
to
make
sure
that
people
understand
what's
the
role
of
captain
in
combination
with
all
the
other
tools,
because
we
all
know
that
there
are
so
many
tools
that
are
trying
to
do
similar
things,
so
we
need
to
really
come
out
with
some
best
practices
on
you
know.
What's
the
role
in
your
case
of
argo
cd,
what's
the
role
of
captain?
What's
the
role
of
tekton?
E
What's
the
role
of
jenkins,
I
think
this
is
still
something
where
people
are
maybe
also
a
little
bit.
You
know
confused,
and
I
think
this
is
why
it's
great
that
people,
like
you,
you're,
actually
showing
best
practices
on
on
how
to
combine
these
tools
and
then
really
use
the
individual
tools
for
strengths.
For
me,
the
strength
of
captain
and
that's
what
I
hear
a
lot-
is
the
automated
analysis,
based
on
the
slos,
the
the
data
driven
aspect
of
orchestration,
the
loosely
coupling
of
all
of
your
tools
to
really
automate
and
orchestrate
your
sequences.
E
I
think
these
are
the
real
strengths
yeah.
No,
but
what
you're
doing
here
is
is
is
great
right.
I
mean,
I
think,
that's
the
right
way
forward.
Also,
I'm
not
sure
if
you
have
followed
all
of
the
comments
in
the
chat
when
you
were
showing
your
your
customized
templates.
Christian
was
also
highlighting
that
you
know,
then
don't
forget
about
the
new
helm,
chart
repo,
that's
important.
I
think
you're
still
pulling
it
from
from
google
from
the
google
artifact
store,
so
check
that
out
as
well.
Okay,.
E
D
That's
a
very
good
question
and
that's
actually
the
phrase
that
we're
in
at
the
moment.
So
we
are
testing
with
with
other
rollouts
and
and
also
comparing
it
to
see
like
what
I'm
confused
about
at
the
moment-
and
you
know
researching
to
understand,
is
that
is
argo.
Rollouts
the
same
as
like
the
service
mesh.
You
know
to
give
that
that
deployment
strategy
capability.
So
I
don't
really
have
the
answer
to
that.
D
E
Yeah,
thank
you
for
that
and
I
also
just
posted
two
links
in
the
chat
as
well.
So
there's
one
with
my
initial
tutorial
on
argo,
rollouts
and
then
another
one
from
a
captain
user
group
from
one
of
our
users,
that
is
using
argo
rollouts
and
to
that
theoretical
discussion.
I
think
it
is
not
a
theoretical
it's
a
practical
thing
right,
because
in
the
end,
I
exactly
think
that
captain
is
perfect
for
that,
because
you
can
use
argo
rollouts
to
deploy
a
new
canary
or
whatever
you
want
yeah.
E
Let's
call
it
a
canary
you
deploy
it.
You
then
run
tests
against
a
new
canary
and
then
based
on
that
really
decide
whether
you
want
to
roll
it
out
to
a
larger
user
base
or
also
blue
green
is
another
again
perfect
you're
using
a
blue
green
deployment.
You
then
run
tests
against
the
new
deployment
that
is
not
yet
exposed
to
the
outside
world
then
use
the
slos,
the
automatic,
slow
validation
to
then
figure
out.
E
Do
we
meet
all
of
our
criteria
and
if
so,
then
we
make
the
switch
and
our
end
users
can
also
access
that
app.
So
I
think
this
is
perfect
and
I
believe
and
dimitri
if
I
understood
your
question
correctly,
this
should
all
be
part
of
of
the
rollout
process
right.
This
is
part
of
the
release.
Process
is
really
validating
until
end
users
can
safely
use
it.
That
means
the
for
me,
a
perfect
captain
sequence,
not
only
switches
between
blue
and
green,
so
deploys
tests,
then
switches
if
everything
good
but
then
keeps
validating.
E
So
things
that
I
have
seen
is
that
people
are
after
the
actual
deployment.
After
the
switch
to
the
live
version,
then,
let's
say
after
10
minutes,
30
minutes
an
hour.
Do
additional
slo
validations
to
make
sure
that
the
live
system
is
also
running,
and
obviously
this
approach
depends
on
the
maturity
of
your
observability
platform.
If
you,
if
you're
basing
it
on,
let's
say
pure
metrics,
then
I
think
using
captains
as
a
low
validation
is
great
after
10
minutes
after
20
after
30
after
an
hour
to
constantly
validate,
are
we
still
within
our
thresholds?
E
C
So
you
executed
the
validation
on
a
blue
version,
but
it's
not
yet
been
exposed
to
the
customer
and
it's
red,
but
it's
red
not
because
of
the
of
the
delivery,
but
because
of
environmental
settings
so
how
to
distill
that,
from
from
real
real
failures
versus
unreal
failures,
so,
for
instance,
currently,
we
are
experimenting
with,
in
that
case,
to
execute
the
same
sli
on
a
on
a
current
version
on
the
green
version
and
to
to
disable
to
skip
fail.
The
kpis
slice.
E
C
B
C
C
E
E
E
A
I'm
still
on
me
one
other
thing
I
wanted
to
quickly
mention.
Of
course
you
can
define
slis,
but
you
don't
have
to
necessarily
give
them
criteria,
so
they
can
be
reported
in
this
report
effectively,
but
you're
just
getting
the
values,
so
you
don't
want
them
to
affect
the
output
or
the
parts
of
fail
if
you
just
want
them
alongside
in
the
report,
that
could
be
one
other.
B
B
B
Presentation
permissions
for
everyone.
So
if
you
want
to
comment
and
just
share
your
feedback
about
the
session
about
your
use
cases
for
captain,
please
go
ahead,
and
so
you
need
to
just
accept
the
invitation.
If
you
want
to
speak
or
just
comment
in
the
chat,
I
will
wait.
Yeah
thanks
a
lot
to
brett
and
adam
for
joining
and
sharing
the
experiences
and
case
because
using
kaplan
with
argo
cd
for
progressive
delivery
is
one
of
the
hot
arrays
we
actually
have
tutorials
for
that
on
tutorials.captain.sage.
D
D
B
Thank
you,
yeah.
All
of
us
are
looking
forward
to
see
how
this
story
evolves
because
yeah
for
me
it
was
always
seemed
quite
strange
that
cabin
is
basically
a
github's
management
tool,
but
you
don't
able
to
efficiently
manage
capturing
like
githubs.
Well,
you
could
do
it
before,
but
it
would
require
some
tricks,
but
now
this
iterators,
I
think
it
becomes
available
right
away
plus,
since
you
will
have
full
access
to
crds
to
specifications,
you
basically
can
integrate
the
capital
management
to
any
management
flow
you
have
so
it
sounds
really
exciting.
D
B
We
are
working
on
that
well
for
real,
so
we
actually
started
working
on
contributing
guidelines,
extending
them
removing
some
obstacles
because,
for
example,
maybe
it's
my
personal
opinion,
but
I
hated
dco
and
I'm
really
looking
forward
to
getting
rid
of
it
somehow
and
other
boundary
other
obstacles.
We
also
need
to
improve
them,
so
I
heard
that,
for
example,
adam
recently
created
a
pc
for
captain
and
docker
and
docker.
B
So
I
think
that
it
would
be
also
one
of
opportunities
for
more
contributors
and
well
newcomer
friendly
issues.
That's
for
sure
we
started
creating
some
around
documentation,
but
we
also
need
to
work
on
captain
and
currently
there
are.
There
are
infinite
opportunities
to
contribute
on
the
services
side
because
we
have
web
service.
We
have
job
executor
service,
which
are
basically
generic
automation
frameworks.
You
can
just
take
one
of
these
services
and
quickly
create
your
integration,
write
some
documentation
based
on
them.
B
B
A
Absolutely
brad
and
I
are
both
in
australia,
so
I'm
taking
a
lot
of.
Obviously
everyone
on
here
is
in
the
same
region,
so
feel
free
to
reach
out
on
the
captain,
slack
we'll
yeah,
we'll
help
and
yeah.
Definitely
if
there
are
tools
that
you
like,
and
that
aren't
kind
of
supported
by
a
captain
at
the
moment
feel
free
to
reach
out
to
me
I'll
guide
you
through
the
best
way.
There
are
a
couple
of
options
to
contribute
so
yeah
happy
to
help.