►
From YouTube: The Unbreakable Delivery Pipeline with Rene Forstner from NTT DATA DACH - Keptn User Group
Description
We’ll talk about some concepts of SRE, Observability and Quality Gates and how they will make your delivery pipeline unbreakable without compromising code quality and increase the reliability of your applications while speeding up your deployment process. We’ll walk through the concepts of Service Level Indicators, Service Level Objects and Release Validation and how good observability mechanism can help automate deployment processes.
René works in NTT DATA DACH as a Technical Consultant, supporting various customers mainly with Application Performance Management, Observability and Integrate all those topics into useful processes. Rene is also a long term Keptn Community Member helping educate users on the power of event driven declarative orchestration.
The event is hosted by the Keptn Team. Use the #community-and-outreach Slack for any feedback and proposals, thank you!
Learn more: https://keptn.sh
Get started with tutorials: https://tutorials.keptn.sh
Join us in Slack: https://slack.keptn.sh
Star us on Github: https://github.com/keptn/keptn
Follow us on Twitter: https://twitter.com/keptnProject
Sign up to our newsletter: https://bit.ly/KeptnNews
A
Welcome
everyone
to
today's
captain
user
group,
the
unbreakable
delivery
pipeline.
My
guest
today
is
renee
forstner,
hi
renee.
How
are
you
hi?
I'm
fine.
Thank
you
very
much
renee.
Thank
you
so
much
for
taking
kind
of
the
opportunity
today
or
actually
I
kind
of
I
really
liked
the
way
you
said
it.
I
I
didn't
push
you
into
the
cold
water
because
you
said
the
water
doesn't
get
warmer
the
longer
you
wait.
A
I
really
like
that
kind
of
term.
It's
great
that
you
are
you.
You
know
using
this
as
an
opportunity
to
present
on
a
topic
that
you
will
also
be
presenting
in
a
couple
of
weeks
at
a
conference,
so
really
great
that
we
have
you
here
before
we
get
started.
I
just
want
to
highlight
one
more
thing
we
have
just
and
with
we
I
mean
the
captain
community
has
just
released
today,
captain
0.12.0
and
I'm
just
putting
in
the
link
into
the
jet.
A
A
A
If
there
is
a
a
very
important
question
that
just
comes
in,
I
may
just
interrupt
you
if
I
feel
it's
the
perfect
time.
Otherwise,
I
will
obviously
not
try
to
interrupt
your
flow,
and
with
this
I
hand
it
over
to
you
maybe
a
quick
round
of
introduction,
because
I
just
talked
for
two
minutes
like
renee.
Who
are
you
for
those
that
don't
know
you
yet.
B
Yeah
andy,
thank
you
very
much
for
introduction
and
also
for
the
invitations
for
having
me
today.
As
already
seeing
us
in
my
role
is
basically
a
technical
consultant
at
entity
data
and
what
I'm
doing
is
quite
simple
and
supporting
mostly
enterprise
customers
with
all
topics
around
monitoring
application,
performance
management
and
pretty
much
everything
which
somehow
relates
to
those
topics
and
therefore
also
captain,
of
course,
is
interesting
for
me,
because
I
joined
the
ace
training
that
andreas
is
training
already
two
years
ago.
B
Okay,
we
know
itil
is
is
somehow
used
for
enterprises.
They
need
to
stick
to
it
for
some
compliance
reasons
and
stuff
like
this,
and
why
not
bringing
in
captain
bringing
some
devops
mythologies
into
those
processes
to
make
them
somehow
speed
up
a
little
or
make
their
customers
keep
up
the
pace
with
some
some
really
cloud
native
companies,
and
I
think
that
we
really
have
some
some
kind
of
cool
use.
A
B
Thank
you
very
much.
There
is.
There
is
one
thing
you
have
already
mentioned
as
well,
and
this
is
an
entity
devops
and
hl
conference,
and
this
is
just
I
want
to
let
you
know
all
the
audience
which
is
here
or
which
will
watch
this
later
on
that
I
will
do
some
some
similar
presentation
on
this
devops
conference
and
I'm
happy
for
feedback
and
and
happy
for
letting
me
know
what
I
can
do
better
during
these
presentations
afterwards.
A
A
B
Cool,
thank
you
very
much
and
two
last
things
before
we
already
are
finally
getting
into
the
presentation.
The
first
thing
is,
I
really
want
to
say
thank
you
to,
of
course,
to
the
to
the
whole
captain
user
group
into
the
captain
project,
but
especially
to
andy
who
supported
me
the
whole
time
not
just
with
content
and
providing
also
some
slides,
but
also,
of
course,
with
his
valuable
time
and
his
knowledge.
I
just
want
to
say
thank
you
in
advance
already.
B
Telling
you
half
of
the
story
will
tell
today
you're
welcome,
and
the
second
thing
I
want
to
mention
is
also
some
just
some
information.
There
was
already
a
past
user
group
with
with
one
of
my
colleagues
from
poland
with
arkham.
It
was,
I
think,
in
the
middle
of
october,
where
there
was
this
captain
user
group.
B
So
we
are
so
you
see
that
it's
not
only
that
I'm
working
with
entity
data,
which
is
basically
the
german-speaking
region
and
also
one
of
our
sister
companies
intel
data
services,
which
is
dealing
with
international
projects,
he's
also
hooked
up
with
captain
and
doing
and
implementing
some
processes
and
some
cool
projects.
With
this
one.
A
B
I'm
just
did
some
some
kind
of
summer
in
the
beginning,
so
in
case
you're
wondering
if
you're
in
the
right
session
or,
if
you're
wondering,
if
you
would
like
to
to
hear
us,
the
next
40
or
40
minutes
or
something
like
this,
so
what
we
are
usually
approaches
getting
started
with
captain.
This
is
what
we
see
today,
how
we
can
get
started
with
captains
just
using
quality
gates
to
just
remove
everything
we
already
have
in
place
and
just
getting
started
with
the
quality
gates.
We
will
look
into
how
captain
integrates
into
enterprise
processes.
B
This
is
what
I've
mentioned
with
the
ideal
stuff
and,
of
course,
for
the
other
people
not
too
much
related
to
captain,
but
still
some
are
underway
in
this
user
group
is
getting
ideal
and
it's
m
in
general,
a
little
smarter
with
the
help
of
captain.
So
there
are
the
key
takeaways
we
will
have
during
this
session,
and
hopefully
there
is
something
for
each
and
everyone
who
is
watching
and
listening
to
us
cool.
So
now,
let's
get
started
finally
short
introduction
why
we
are
doing
this.
Why
we
need
to
do
this.
B
Of
course
we
need
to
think
about
new
processes
and
new
approaches
of
doing
or
dealing
with
our
evidence
work.
One
thing
is,
of
course,
we
need
to
deliver
faster.
So
if
you
take
a
look
again
into
all
the
lame
or
lame
rightful
processes,
I'm
getting
a
change
done
takes
a
lot
of
time
and
we
need
to
get
these
processes
speed
up
in
parallel.
While
we
need
to
get
faster.
Of
course,
we
need
to
deal
with
increased
complexity,
so
it's
not
getting
easier.
There
are
more
and
more
services,
there
are
more
lines
of
codes.
B
There
are
more
tools,
there
are
more
processes
we
need
to
consider
during
during
our
daily
ops.
So
this
is,
of
course,
one
of
the
one
of
the
biggest
issue
and
all
this
needs
still
to
meet
some
compliance
ether.
It's
our
legal
compliance
or
just
some
some
auditing
compliance
like
you
need
to
be,
or
stay
eso,
certified
and
stuff
like
this.
B
So
this
is
quite
normalised
omen
and
the
second
thing
we
are
looking
into
is
from
the
sre
and
where
we
take
care
about
the
door
of
our
operation.
We
just
take
care
about
that.
There's
some
stable
operations
that
are
reliable
and
do
not
break
things
that
much
and
if
you
break
things
we
would
like
to
restore
them
as
soon
and
as
fast
as
possible.
B
So
this
is
the
frameworks
which,
if
you
take
a
closer
look
into
in
the
next
slides,
we'll
have
a
lot
in
getting
itil
or
itsm
a
little
faster
than
it's.
Today
we
have
someone
there
is.
There
needs
to
be
a
word
holistic,
of
course,
in
each
slide
deck.
So
we
have
some
kind
of
holistic
approach
on
how
to
deal
with
the
complexity
and
how
to
deal
with
the
situation.
B
And
the
first
thing
is:
we
need
to
get
a
common
language
and
with
a
common
language
we
mean
that
we
need,
from
the
business
perspective,
from
the
user's
perspective
from
the
development
and
operations
perspective,
so
just
from
the
complete
service
chain.
We
need
to
talk
about
the
same
thing.
If
we
have
any
issues,
we
need
to
talk
about
the
same
issue.
If
we
want
to
change
something,
we
need
to
talk
about
the
same
thing
we
want
to
change.
B
B
The
second
thing
when
we
achieved
that
we
are
all
talking
about
the
same
thing,
is
automate
all
the
same
ultimate
all
the
things,
so
there
is
basically
one
one
sentence
I
really
like,
which
is
everything
which
needs
to
be
done
more
than
once
needs
to
be
automated,
so
everything
which
is
at
least
needs
to
be
done
twice.
We
should
think
about
a
way
on
how
to
automate
such
things
and
the
second.
B
The
first
topic
is
integrating
all
those
things
we
automated
and
we
talked
about
so
with
what
you're,
seeing,
of
course,
the
first
pillar.
What
you're
seeing
is
there
is
no
common
language,
we're
seeing
a
lot
of
manual
processes
and
we're
seeing
a
lot
of
silos,
so
not
getting
things
integrated,
having
a
lot
of
silos
a
lot
of
automated
sellers,
and
so
therefore
the
first
pillar
is
integrating
all
these
things.
Besides,
achieving
some
some
complete
service
flow.
B
If
you
integrate
all
the
stuff,
there
is
one
additional
benefit,
of
course,
and
this
is
that,
if
you're
working
in
enterprises,
you
will
see
a
lot
of
preferences
in
terms
of
people
want
to
work
with
with
tool
x.
I
said
the
other
ones
want
to
work
with
tool
abc
and,
if
you're,
integrating
all
them
and
having
all
the
informations
in
the
right
place.
Having
all
the
information
where
it
belongs
to
the
users
are
are
more
than
happy
to
stick
with
their
tools.
B
B
So,
let's
start
with
with
the
first
topic,
the
common
language-
it's
already
we're
here
within
the
the
slow
sub-header
sla
is
which
the
the
stuff
which
will
be
covered
within
this.
The
second
point-
and
this
is
what
we
have
learned
in
the
past-
is
one
of
the
most
crucial
things,
especially
again,
if
you're
an
enterprise
or
working
within
an
enterprise.
B
B
B
There
is
an
example
sli
here
like
the
response
time
of
the
service,
like
you
know,
you
have
a
service
and
you
you
have
an
sli
about
the
response.
Time
of
the
service,
for
example,
if
you
have
a
web
shop
or
an
online
shop
and
just
measure
the
look
in
time
of
the
service
so
just
to
have
the
service
level
indicator,
the
service
level
objects
will
give
you
some
kind
of
an
of
a
contract
towards
your
slice.
So
if
the
service
level
object,
we
just
think
what
do
we
want
to
achieve?
B
B
And
the
last
thing
is
the
service
level
agreement
sla,
which
just
defines
mostly
from
a
business
perspective.
What
happens
if
we
preach
in
israel?
What
happens
if
we
violate
like
pain,
penalties
or
having
some
some
other
kind
of
issues
and
the
common
mistake
we
are
seeing
here.
The
common
mystic
is
that
often
the
the
the
collaboration
starts
with
sla.
So
often
you
do
not
start
from
from
top
to
top
and
think
about.
B
Because
you
will
talk
about
the
same.
You
will
see
this
in
the
next
slides,
but
if
your
image
and
the
business
just
have
some
kind
of
slas
against
their
customers,
you
as
an
as
an
operations
guy
know
about
the
slo
and
as
a
developer,
you
know
about
the
sli,
which
is
measured
and
which
you
need
to
take
care
of.
So
this
is
something
if
you
are
able
to
implement
this.
B
There
is,
I
have
two
screenshots
in
terms
of
some
kind
of
a
best
practice
slow
dash,
but
the
one
is
that
there
is
a
little
dashboard
to
start
with.
It's
quite
simple:
you
have
one
row
for
their
ability.
For
example,
you
have
one
row
for
reliability
so
for
how
long
do
you
perform
and
how
good
are
you
performing
and
then
just
some
different
time
frames
like
the
last
hour
to
see
if
you
just
right
now
have
any
issues?
B
So
we
really
see
this
a
reliability
as
well
as
in
this
case,
and
we
really
see
how
our
business
processes
are
doing
and
they
could
break
this
down
to
some
some
additional
informations.
So
this
is
quite
a
final
kind
of
slo
dashboard
and
if
you're
going
to
the
quality
gate
topics
within
the
next
chapters,
you
can
see
why
this
is
so
useful.
B
The
next
thing
we
want
to
talk
about
is
automation,
automated,
so
one
one
thing
is
automated
observability.
The
second
thing
is
automated
quality
gates
already
mentioned
everything
which
must
be
done
more
than
once
should
be
automated.
I
really
like
to
stick
to
this
cradle,
not
just
because
I'm
I'm
very
lazy
in
doing
repetitive
tasks.
It's
also
some
some
kind
of
error,
problems
and
stuff
like
this,
and
what
do
we
look
into?
This
is
two
tools
which
which
helps
a
lot
here.
B
So
the
first
thing
is
dyna
trees,
it's
observability,
because
if
you
take
a
look
into
our
sli,
slow
and
sla
topic,
we
need
to
measure
our
slice
somehow,
and
this
is
where
we
need
a
scalable
solution,
where
we
need
some
solution
which
is
roxanna
liable
and
they
can
measure
all
our
slides.
We
have
in
place-
and
I
really
love-
I'm
not
raising
this
place
and
because
dynadress
is
something
which
really
works
good
at
scale.
B
I
know
this
is
an
agent-based
monitoring
solution,
so
it
doesn't
matter
if
you're
going
for
on-premise
solutions
or
if
you're,
already
some
on
some
calculative
solutions.
You
know
someone
gets
the
agent
running
on
your
components
and
with
this
one
agent,
it's
also
called
one
agent,
because
you
do
not
need
to
think
about
technologies
and
stuff
like
this.
B
Having
this
one
single
agent
roll
out
in
your
environment,
in
most
cases,
you're
already
good
to
go
to
see
some
data.
This
is
what
really
is
cool.
Is
that
dynadress?
If
just
having
the
agent
installed,
you
just
see
already
some
kind
of
topology
you
see.
Some
kind
of
this
is
number
two's
infographics
of
what
is
is
related
to
what
what
is
running
on
which
environment
and
already
see
if
everything
is
properly
set
up
on
on
the
top
level
for
the
business
view
and
the
application
side.
B
So
it's
really
cool,
because
it's
just
a
one
single
agent.
There
are
more
than
500
technologies
already
supported
by
this
agent,
or,
at
least
by
by
the
time,
address
implementation,
and
the
reason
why
we
are
going
for
this
is
most
efficient.
Is
it
because,
of
course,
it's
one
of
the
best
incas
tools,
but
again
we
come
from
an
enterprise
segment.
B
They
come
from,
something
which
is
strongly
related
to
itil,
which
is
strong
related
to
itsm
into
some
some
really
stair
processes,
and
this
is
also
where
dynadress
can
help
us,
because
dynadress
is
also
available
on
premise.
We
can
just
insulate
it
on
any
customer
base.
We
do
not
need
to
take
care
if
this
is
a
20
year
old
mainframe
we
have
on
the
other
end,
or
if
this
is
some
of
the
newest
cloud.
Native
development
usually
are
good
to
go
with
this
solution.
B
You
can
just
walk
through
each
and
every
transaction
and
take
a
look
on
code
level.
What
was
going
wrong?
What
was
going
good
and
you
will
satisfy
your
business
with
having
some
some
user
insights
on
how
your
users
are
doing
with
the
applications
your
monitor
and
how
the
application
itself
is
doing
against
your
users
and
your
customers,
and
this.
This
is
one
thing
just
that
the
possibilities
you
have.
B
The
second
thing
is
the
ad
scale
portion
while
dynadress
is,
is
going
more
and
more
into
the
first
approach
and
then
doing
more
and
more
api
first
you're,
quite
good
to
go
to
automate
the
rollout
automates.
The
implementation
of
the
energies
like
there
is.
It's
called
dynadress
monaco,
which
is
some
some
language
dynamics
developed.
This
is
an
open
source
project
which
is
available
for
for
each
and
everyone
which
doesn't
cost
anything
where
you
can
just
do
kind
of
decorative
configuration
of
dynamics
with
channel
files
and
getting
stuff
done
and
getting
configuration
done.
B
B
To
do
everything
is
called
and
the
second
tool
we
are
looking
in
or
the
second
we
want
to
present
today
is-
is
captain
I've
just
copied.
Therefore,
this
is
the
link,
the
the
short
description
about
caption
about
captain,
it's
a
control
plane
for
devops
automation,
field
native
applications
and
there
there
is
one
interesting
thing
or
multiple,
interesting
things.
Of
course
here,
because
this
is
the
in
the
past
there
was
captain-
is
an
event-based
event-based
control,
plane
for
devops
automation
of
job
native
applications.
B
I'm
still
missing
this
event,
based
because,
basically
this
is
what
it
is.
So
dyna
captain
reacts
on
events
that
pushes
events
and
help
you
on
getting
things
done
in
a
scalable
way.
So
all
captains
also
using
everything,
is
called
approach
and
there
are
more
or
less
three
main
use
cases
which
one
of
them
will
look
into
this
today.
One
use
case,
or
one
of
the
most
important
use
cases,
is
the
continuous
delivery.
So
from
deployment
to
test
to
very
data
tests
and
to
promote
artifacts,
you
can
all
do
with
the
control
plane.
B
Thank
you
latest
releases
or
just
doing
any
other
remediation
actions
for
instability
or
any
other
tools,
and
the
third
thing
this
is
what
we
take
a
deeper
look
today
is
deployment
validation
with
quality
gates,
so
you
can
just
bring
in
captain
wherever
you
want
to
validate
something
wherever
you
want
to
have
some
kind
of
quality
gates
in
place
and
have
them
automated
validated
and
you're
good
to
go
with
captain-
and
this
is
what
I
really
like
to
stress,
is
because
it's
mentioned
here.
It's
mentioned
officially,
for
that.
This
is
for
devops
automation.
B
This
is
for
cloud
native
applications.
Of
course,
this
is
true
and
of
course
this
is
the
intent
of
captain.
But
basically
you
do
not
stick
to
cloud
native
applications.
You
do
not
stick
to
defaults.
You
still
could
implement
captain
or
the
quality
gate
portion
of
captain.
If
you're
running
some
classically,
I
tilt
changes
if
you're
running
some
classical
processes
and
just
want
to
automate
some
portions
of
it.
So
all
through
cloud
native
is
is
100.
True.
B
Basically,
what
is
the
concept
of
a
quality
kit?
It's
quite
simple.
You
gather
some
matrix,
you
generate
a
scroll
like.
Is
this
metric?
What
an
expected
metric
it
should
be,
and
then
you
just
make
a
decision
either
if
you
need
to
roll
back
or,
if
you're
good,
to
go
and
and
let
this
change
into
production
or
just
create
a
new
release
out
of
it
and
stuff
like
this-
and
this
is
basically
all
for.
This
is
quite
a
simple
concept.
B
I'm
quite
sure
that
some
kind
of
two
things
are
already
implemented.
If
between
anyone,
even
which
is
automated,
even
if
there
is
a
pattern
or
not,
we
see
a
lot
like
just
having
an
excel
test
case
list
or
something
like
this
is
already
quality
gate,
and
what
we
want
to
achieve
with
captain
is
getting
things
automated
getting
this,
this
quality
gets
automated
and
what
you
want
to
achieve
is
from
getting
from
this.
B
I've
made
this
example
with
a
jenkins
pipeline,
but
basically
the
process
is
what's
interesting
here
from
build
a
new
software
stack
or
implement
a
new
change,
deploy
this
stuff
to
test
to
test
environment
and
staging
environment
and
stuff.
Like
this,
and
here
we
have
that
the
break,
we
have
the
manual
approval
where
we
just
needs
to
think
about
or
just
needs
to
validate
the
changes.
This
is
either
we
are
looking
at
exercise
or
we're.
B
Looking
at
dashboards
like
in
this
example,
we
need
to
do
this
manually
for
each
and
error
change
so
for
each
and
every
run
we
have.
We
need
to
take
a
look
into
dashboards
and
stuff
like
this
or
fill
out
some
excel
files
or
even
do
still
manual
testing,
and
this,
of
course
takes
a
lot
of
time,
so
we
either
lose
a
lot
of
time
or
we
lose
a
lot
of
quality,
because
the
the
test
engineers
and
the
validators
just
skip
some
tests
and
skip
some
analyzes
and
just
promote
the
stuff
to
production.
B
So
what
you
want
to
achieve
is
from
getting
this
30
to
60
minutes
delay
with
approving
stuff
manually
into
a
one
minute
delay
by
having
it
approved
with
captain.
This
is
basically
what,
in
the
can.
You
can
see
this
this
later
on,
as
well.
I'm
doing
this
here
with
the
jenkins
pipeline,
but
the
process
is
basically
what
was
interesting
for
us
and
instead
of
getting
the
manual
approval,
we
would
like
to
trigger
quality
kit.
We
would
like
say:
hey
captain.
We
are
done
with
our
tests.
We
would
like
to
get
the
quality
get
triggered.
B
B
B
In
how
does
this
loop
is
quality?
It's
work,
okay,
so
we
have
our
service
level
indicators
which
already
have
defined
in
the
past,
with
the
first
step
of
the
common
language,
where
we
have,
for
example,
agreed
on
a
response
time
for
95
of
our
calls.
We
have
agreed
on
a
failure
rate
for
the
complete
service.
B
We
may
have
agreed
on
some
dedicated
steps
like
a
login
step
for
the
response
time
and
also
test
step,
and
maybe
also
have
already
agreed
on
vulnerabilities
like
the
new
solutions,
more
or
less
vulnerabilities
than
the
last
one,
and
if
you
need
to
fix
them,
if
you
need
to
close
them,
so
basically
those
are
our
slices.
You
already
have
defined,
and
now
the
slows
kicks
in.
So
what
we
have
done
is
that
we
have
defined.
We
are
good
to
go.
B
B
90
percent
of
my
slos
needs
to
pass
to
get
it
green
and
75
to
get
it
passed
to
get
it
sorry
to
get
rid
of
ironing
but
still
be
well
lit,
and
if
we
take
a
look
at
our
first
build,
so
we
run
our
change
processes,
maybe
for
a
pipeline,
maybe
some
manual
stuff
and
just
see
that
our
first
build.
Our
first
change
is
100
valid
against
our
slo,
so
we
could
go
with
our
first
build
the
second
build.
If
you
take
a
look
into
this,
we
have
two
worms.
B
We
have
one
red
alert,
so
we
only
achieve
50
percent
of
our
overall
score,
so
this
build
will
be
blocked,
so
captain
will
not
give
us
an
approval
cap.
We
just
note
back
that
this
quality
gate
just
failed
due
to
the
following
reasons.
So
we
need
to
get
back
to
our
developers.
We
need
to
get
back
to
our
change
team.
We
implemented
the
change
and
just
say,
hey
guys,
you
need
to
build.
You
need
to
do
a
little
better.
You
need
to
do
a
little
betting,
the
overall
response
time.
B
You
need
to
do
a
little
better
within
the
login
service
and
you
just
got
done
a
new
vulnerability
within
your
solution.
Please
fix
it,
so
this
is
what
the
process
can
look
like,
and
this
is,
I
really
love
this
graphic
because,
although
it's
mentioned
here,
we've
built
one
built
to
be
free
built
for
it
doesn't
really
need
to
stick
to
defaults,
and
this
is
what
I've
mentioned
earlier.
It
doesn't
matter
how
your
change
does
look
like
you
just
somehow
need
to
get
kept
triggered,
and
you
just
need
to
somehow
get
your
slice
measured.
B
So
these
are
the
two
things
which
are
crucial
and
then
it
doesn't
matter
if
you're
running
on
the
main
frame,
if
you're
running
on
classic
id
or
if
you
really
are
cloud
native,
you
still
can
go
with
this
approach
and
be,
and
this
can
be
somehow
the
first
step
into
your
cloud
native
world.
Probably
you
can
just
build
your
baseline
if
you're
thinking
about
migrating
to
the
cloud,
if
you're
thinking
about
refactoring
stuff,
you
can
use
this
quite
good
as
a
baseline,
saying,
okay,
my
build
one.
This
is
my
ses
environment.
B
B
If
you
take
a
look
under
the
hood
and
because
it's
mentioned
how
quality
gates
work
as
dashboard
or
as
code,
if
you
just
look
into
one
single
line
of
our
slice,
this
is
something
I've
already
mentioned
in
the
beginning.
Everything
is
code,
of
course,
also
kept
giving
us
the
possibility
to
do
this.
As
code
is
and
getting
your
slice
defined
for
address
slice
we
could
go
for
for
the
metric
selector
within
the
building
matrix.
B
You
could
also
go
for
prometheus
matrix
for
having
the
sli,
so
you
could
even
build
your
own
sli
provider
if
you're
having
any
other
tooling
or
any
other
solutions
in
place.
But
basically
this
is
what
it
looks
like
for
the
developer.
Well,
we
see
it
for
the
management
as
dashboard.
We
can
see
for
the
developer.
B
It's
just
some
jumbo
files
getting
your
stuff
defined.
This
is
again
taking
a
look
into
the
first
chapter,
the
common
language,
getting
a
matrix,
getting
your
your
slicer
measurements
out
of
the
observability
solution
and-
and
the
second
thing,
of
course,
the
slo,
which
is
basically
the
color.
Do
we
get
the
green
to
write
it
in
a
warning?
So
in
orange
we
get
a
red
tile
is
done
if
there
is
a
low
definition.
You
just
define
and
I'm
aware
that
the
the
definition
doesn't
comply
with
the
screenshot
here,
but
nevertheless
very
just
define.
B
When
is
an
slo
achieved
when
is
in
this
low
pass
and
when
you
will
get
the
wiring
or
a
critical
issue.
There
are
two
interesting
things
I
want
to
mention.
Of
course
you
have
the
static
validation
like
the
100
milliseconds.
You
can
see
above,
but
there
is
also
a
relative
validation
where
we
can
compare
to
previous
builds.
B
We
can
just
compare
to
the
to
the
to
the
past
and
say:
okay
when
you
build,
I
want
to
beat
at
the
maximum
10
percent
slower
than
the
new
one,
or
it
can
be
just
two
vulnerabilities
more
than
with
the
the
last
build
and
stuff
like
this.
So
this
is
pretty
cool.
I'm
having
this
in
context
as
well,
so
not
just
stick
to
some
static
stuff.
You
also
can
do
some
some
relative
comparison
with
your
last
informations
and
your
last
bills.
B
B
B
The
integrations
are
mostly
smooth
and
quite
simple,
but
the
team
I'm
working
with
is
is
focus
strong
in
itsm
and
to
really
know
the
pain
without
the
same
tooling,
and
to
really
know
how
hard
it
is
to
really
make
it
useful
in
the
good
itsm
integration.
So
what
we
want
to
achieve
with
this
integration
hub
is
that
we
somehow
make
it
easier
for
our
customers
that
they
do
not
need
to
think
about
their
itsm
solution
and
their
itsm
interface.
They
do
not
need
to
think
about
what
happens.
B
If
I
replace
my
actism
solution,
I
am
still
compatible
with
with
all
the
other
interfaces
I
have,
so
we
just
integrate
that,
or
we
just
developed
this
integration
up
as
some
kind
of
layer
in
between
your
it's
embroid
and
your
devops
world,
or
you
use
your
icd
world
just
name
it,
and
this
tool
already
has
a
lot
of
features
and
the
game
captain
is
just
something
which
you
just
added
on
the
on
the
later
stage,
and
what
I
want
to
show
you
is.
The
last
point
is
getting
some
some
example.
Workflow
of
those
integrations
again.
B
B
We
have
some
captain,
we
have
diner
trace
for
absorbability,
but
we
also
may
have
prometheus
in
place
and
for
for
doing
some
monitoring,
and
now
we
somehow
want
to
get
the
dogs
connected
and
what
we're
usually
starting
with
is
with
the
cmdb
synchronization
we
offer.
This
sounds
a
little
irrational,
especially
if
you're
working
a
lot
with
devops
or
only
with
devops,
but
within
itsm
right
till
cmtp
is
basically
the
base
of
everything
and
without
having
a
cmtp,
you
won't
have
a
good,
its
m
ticket
or
a
good,
its
m
change
or
even
sla.
B
So
this
is
the
first
thing
we
do
when
we
integrate
is
some
are
getting
a
cmdp
synchronization,
knowing
what
your
monitor,
knowing
if
this
is
already
somehow
in
your
cmtp,
if
this
is
some
already
known
by
your
itil
processes
and
if
not
just
create
the
corresponding
cis,
just
extended
give
some
information
out
of
dynamics.
If
this
is
already
available,
just
getting
the
first
stage,
the
most
fast,
the
most
important
stage,
and
then
we
have
in
our
example,
is
as
we're
dealing
with
with
changes
a
lot
we
have
in
this
example.
B
They
have
a
new
change,
and
this
is
also
something
which
we
see
a
lot.
Although
there
is
the
development
team
which
is
working
with
with
the
ict
and
having
weapons
in
place
and
stuff,
like
this
they're,
often
getting
triggered
by
a
change
when
official
change,
they
need
to
implement
the
changes
required
again
for
the
cmtp
updates.
The
change
may
is
required
for
charging,
which
is
done
out
of
of
that
tsm
solution.
So
we
see
a
lot
of
reasons
for
for
having
this
change
in
place.
B
So
this
is,
if
you
think
about
that,
is
some
some
kind
of
event
based
for
us.
The
itsm
is
is
giving
that
the
trigger
is
giving
the
event
for
doing
something.
In
this
case,
it's
the
new
change
event
which
we
see
and
then
we
basically
have
some
two
kinds
of
integrations
or
two
kinds
of
possibilities.
Right
now,
the
first
one
is
there
is
no
the
ict
in
place
of
just
jenkins
as
a
symbol.
B
Of
course,
this
could
be
any
ict,
not
any,
but
we
have
integrated
a
lot
of
them,
but
the
case
that
you
are
not
already
having
some
some
pipeline
tooling
in
place
and
captain,
and
we
trigger
the
evaluation
out
of
the
integration
of
directly
so
having
a
cmtp
synchronization,
knowing
on
which
cis
we
will
do
the
change
and
knowing
that
we
will
do
a
change.
We
can
kick
off
the
evaluation
based
of
the
information
out
of
the
itam
solution.
So,
like
hey
guys,
we
have
a
change.
B
The
service,
the
business
service
which
is
affecting
is
our
online
shop
and
the
change
itself
is
on
the
service.
Ci
of
our
cart
microservice,
for
example,
of
our
just
of
our
current
service
and
with
those
information
we
know
on
that
dynadress
and
which
slice
you
need
to
to
measure.
We
need,
we
already
know
which
slos
we
need
to
achieve
and
stuff
like
this.
B
Captain
captain
itself
will
start
evaluating
against
dinovius
against
prometheus
and
will
evaluate
slos
and
if
they
have
reached
them
and
if
everything
is
is
proper
and
if
the
change
was
successful,
we
got
the
proof
of
captain,
then
the
e4
can
of
course
inform
our
pipeline
about
it
can
bring
our
problem
to
the
next
step,
or
we
can
just
inform
our
integration.
How
to
tell
the
itsm
solution.
Hey
guys,
it
seems
that
the
change
was
successful.
We
just
did
our
automatic
evaluation.
B
Everything
is
fine
and
everything
is
up
and
running
again
and
if
you
spin
this
a
little
further,
if
you're,
having
defined
your
slice
and
slows,
you
can
dynadress,
but
you
need
to
measure
I'm
sorry.
You
need
to
measure
your
slas
within
the
itsm
tool.
You
think
that
the
same
solution
we
can
do
this
as
well,
so
maybe
there
is
an
sla
telling
you
that,
although
you're
doing
a
change,
you're
not
allowed
or
the
changes
is
counting
against
your
error
budget,
for
example.
B
Of
course,
this
is
some
kind
of
possibilities,
so
you
can
do
the
measurement
of
this
sla
out
of
the
common
language
if
they
find
the
integration
that
will
help
you
getting
this
stuff
and
this
information
back
into
that
the
same
tooling
again.
So
this
is
really
some
cool
stuff,
and
this
is
what
we
want
to
show
you
today
that
you
do
not
need
to
stick
to
cloud
native.
B
B
Again,
everything
is
code,
so
everything
which
needs
to
be
done
more
than
once
should
be
automated
and
if
possible,
it
should
be
done
as
code
to
have
it
clearly
written
down,
and
the
last
thing
we
looked
into
is
integrate
all
those
things
integrate
all
the
tools
you're
having
already
in
place.
Even
is
it
with
captain
it's
a
event-based
framework,
usually
developed
for
devops
and
cloud
native
applications,
or
is
it
maybe,
with
the
help
of
our
integration
hub?
B
B
A
Thank
you
renee.
Thank
you
so
much,
and
can
you
do
me
a
favor?
Can
you
go
back
to
the
second
to
last
slide
this
one
here
yeah
exactly
yeah,
because
I
think
this
is
a
really
great
overview
of
you
know
what
problem
we
really
need
to
solve.
First,
we
need
to
figure
out
how
we
can
talk
the
same
language.
I
know
you,
you
explained
slos,
but
it's
actually
not.
I
mean
they
also
said
it's
not
easy,
because
you
need
to
define
slos
that
span
all
the
stakeholders.
A
You
need
to
talk
with
the
business
to
understand
what
their
objectives
are
and
then
you
need
to
break
it
down
into
metrics
that
actually
the
architects,
the
developers,
the
performance
engineers,
can
actually
influence
and
contribute
because
I,
as
a
developer,
I
might
not
be
able
to
impact
conversion
rates,
because
if
the
shop
that
I'm
building
is
super
fast,
but
the
products
we're
selling
and
the
marketing
doesn't
do
a
good
job,
there's
nothing.
I
can
do
so
it's.
A
B
Of
course,
I
can't
basically,
this
is
a
quite
a
good
and
quite
a
hard
question
to
answer
from
my
point
of
view,
because
there
is
first
of
all,
there's
no
easy
answer
from
my
end.
It's
always
the
answer.
It
depends
and
we
see
some
customers
do.
We
have
a
staging
environment
with
almost
the
same
sizing
as
the
production
environment
and
using
just
some
some
well-known
tools
like
like
load
runner
and
tools
like
this
to
to
produce
some
load.
B
We
have
the
staging
environment
where
we
have
some
produce
some
some
artificial
load
and
to
our
quality
kits,
but
we
also
do
our
quality
kits
in
production.
So
this
means,
if
we
roll
out
the
production
and
we
still
do
our
quality
gates.
We
still
validate
our
code
and
we
still
validate
how
we
perform
and
if
we
find
any
issues
and
if
we
find
out
that
since
the
last
change
or
since
the
last
new
release,
we
have
some
issues,
we
can
again
trigger
captain
to
perform
a
role
back
sequence,
for
example,.
A
Yeah,
I
think
my
answer,
johannes,
it's
a
very
tough
question
that
you
bring
here,
because
it
really
depends
on
the
application,
just
some
high
level,
things
that
you
may
have
heard
already.
If
your
application
is
built
for
it
and
architectured
for
it.
The
best
way
is
to
test
in
production
using
concepts
like
canary
deployments
or
feature
flaking,
where
you
can
basically
open
up
your
traffic
to
the
real
world
or,
let's
say
so,
to
a
portion
of
the
real
world
and
then
use
observability
to
figure
out.
Does
the
new
code
change
change
the
behavior?
A
Is
it
faster
or
slower
right?
I
understand
this
is
not
possible
for
every
app
if
it's
especially
not
built
and
architecture,
for
that
another
concept
that
we
use
at
dyna
trees.
Internally,
we
have
a
continuous
performance
environment.
That
means
that's
kind
of
like
a
it's
an
environment
that
is
constantly
under
low
24
7,
with
also
realistic
sizing
of
the
environment
and
in
that
environment
we
deploy
every
new
build
into
that
environment,
while
it
is
still
under
load
to
also
test
things
like.
How
does
the
system
behave
while
a
deployment?
A
A
robot
is
happening
right
now
and
then
we
can
compare
before
and
after
to
see
what
is
changing
now.
This
might
also
not
be
possible
for
everyone,
so
either
you
have
to
change
like
as
renee
said,
or
you
can
build
up
these
environments.
You,
you
invest
a
lot
of
time
in
load
testing
scripts
to
try
to
come
to
realistic
lows.
That's
in
that's
an
option.
A
The
last
thing
that
I
have
seen
in
my
life
and
I've
been
doing
performance
engineering
for
almost
20
years
now
is
that
most
performance
problems
can
be
detected
even
without
a
large-scale
performance
test,
because
most
problems
are
related
to
the
classical
problem
patterns.
We
have
out
there.
The
m
plus
one
query
problem
where
you're
making
too
many
calls
to
the
database
fetching
too
much
data,
and
while
this
would
be
perfect
to
capture
all
this
and
see
all
this
in
large
large
environments,
you
can
see
this
also
in
smaller
environments
in
smaller
test
settings.
A
If
you
compare
the
behavior
of
your
build
of
your
builds
from
one
build
to
the
other,
like
renee,
you
showed
it
earlier
number
of
database
calls
number
of
calls
to
back
in
service
if
these
behaviors
change
or
memory
behavior.
If
that
change,
if
logging
behavior
change,
if
io
behavior
changes,
then
you
know
something
is
weird
and
often
you
need
to
take
care
of
this.
B
I'm
not
thinking
that
you're
talking
about
navigation
planes
or
something
like
this,
don't
have
anything
here,
and
so
when
we
got
to
the
to
the
integration
hub.
Basically,
this
this
came
out
of
an
idea
of
integrating
most
bmc
itsm,
tooling
bmc,
true
side
with
dynadress,
because
dynajs,
of
course,
has
already
out
of
the
box
integration
for
servicenow,
which
is
way
better
than
the
out
of
the
box
integration
for
bmc,
and
we
started
by
this
bmc
to
dynadress
integration
in
the
in
the
early
beginnings.
And
what
we
have
here
in
place
is
the
classic
scene.
B
The
business
conversations
are
mentioned.
We
have
the
essec
incident
integration,
where
we
can
just
trigger
incidents
out
of
dynamis
alerts
into
our
bmc
solution,
and
you
have
to
change
interface,
so
not
only
for
triggering
capital,
but
also
just
getting
the
change
event
into
dynadress,
because
this
integration
of
mainly
focus
on
having
the
information
very
needed.
So
you
might
have
some
business
cards
working
without
the
same
solution.
B
You
might
have
some
some
operational,
also
some
developers
and
which
are
working
strongly
with
dynamics,
and
we
want
the
right
thing
to
switch
between
tools
the
whole
day
and
searching
information
there
and
such
information
here.
So
therefore,
this
disintegration
was
developed
and
for
the
future
plans.
It's
quite
hard
to
answer
this.
To
be
honest,
because
we
are
basically
not
working
on
new
features
right
now,
but
we're
working
on
feature
enhancements
like
that
at
the
incident
integration,
for
example,
it's
already
working,
of
course,
but
we
still
want
to
get
disimproved.
B
Which
is
basically
what
potential
already
mentioned:
we
want
to
have
single,
ci
single
source
of
truth,
either
on
the
left
or
on
the
right
side,
just
in
these
informations
and
not
have
duplicates
and
not
have
some
some
kind
of
dummy
sea
ice
on
either
side
and
get
this,
and
this
is
what
what
they
really
want
to
achieve
and
what
we're
really
working
to
get
this
out
of
the
box,
because
we
see
a
lot
of
integration
solution
also
between
dynavas
and
bmc.
There
are
solutions.
There's
an
out
of
the
box
integrations.
B
There
is
with
cityops
already
some
some
player
on
the
market,
and
I
basically
have
a
clear
goal.
I
want
to
be
the
best
in
class.
I
want
to
have
the
customer
just
to
click
two
buttons.
One
of
them
is
enter
the
dynamics
url
into
the
dynadris
token,
and
the
second
thing
is
into
the
bmc
credentials
and
the
rest
is
non-automatic
customers.
So
this
is
my
intent
of
the
solution.
A
Dude,
hey
renee.
First
of
all,
thank
you
so
much
for
doing
this.
Second,
all
the
best
for
your
presentation
in
two
weeks
at
the
entity
event,
if
anybody
has
feedback
for
renee
remember
this
is
it's
always
tough
for
speakers
that
really
they
prepare
a
new
presentation
and
then
speak
in
front
of
an
audience
the
first
time,
especially
when
they
assume
it's
still
virtual.
A
So
that's
why
being
virtual
is
very
hard
and
because
you
typically
don't
get
much
feedback
to
improve.
Therefore,
whoever
is
still
on
the
call.
If,
when
they
do
me
a
favor,
can
you
go
to
the
last
slide
with
your
email
address,
because
rob
would
like
to
give
you
some
feedback
and
then
because,
if
he
can
then
follow
up
with
you
exactly
yeah,
so
very
much
appreciated.
All
speakers
are
really.
A
We
need
the
feedback
and
it's
getting
harder
if
you're
just
doing
it
virtually,
even
though
it's
easier
to
just
easy
to
just
send
an
email.
With
this,
I
want
to
close
the
captain
user
group.
I
encourage
everyone
that
was
on
the
call
today
and
that
is
also
active
in
the
captain
community
to
reach
out
to
us.