►
From YouTube: Sponsored Lightning Talk: Automating Decisions to Achieve Speed and Stability... - Gopinath Rebela
Description
Sponsored Lightning Talk: Automating Decisions to Achieve Speed and Stability with Continuous Delivery - Gopinath Rebela, OpsMx Inc.
Speakers: Gopinath Rebala
As organizations increasingly adopt continuous delivery as a paradigm for delivering features at high velocity, there are significant challenges in the transition from existing software processes to true continuous delivery. We find organizations at various stages of maturity in achieving continuous delivery. There is significant friction in decision making for stability and security that include manual steps. In this talk about the challenges faced by organizations in terms of visibility into delivery data, automating the decision making process and discuss best practices adopted by organizations delivering thousands of changes a day.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
Welcome
thank
you
for
joining
us
today.
At
the
citycon
lighting
talk
today,
we're
going
to
talk
about
automating
decisions
to
achieve
speed
and
stability
and
continuous
delivery.
My
name
is
gopinath
rebala,
I'm
cto
of
opsomix.
We
specialize
in
simplifying
continuous
delivery
solutions
for
enterprises,
we're
based
on
spinnaker
platform.
As
you
know,
spinnaker
is
a
continuous
delivery.
Multi-Cloud
platform
today
we'll
talk
about
what
is
the
state
of
the
continuous
delivery
and
the
challenges
in
the
risk
assessment.
Essentially,
if
you
want
to
make
a
decision,
you
have
to
assess
the
risk
where
what
are
the
challenges?
A
This
also
gives
a
better
devops
visibility
for
dev
and
ops
with
tools
like
spinnaker,
but,
as
you
know,
the
difference
between
continuous
deployment,
as
generally
defined,
is
that
the
changes
are
deployed.
All
the
way
into
the
production
versus
the
changes
are
ready
to
be
deployed
at
any
time
to
production.
It's
a
continuous
delivery,
so
today
is
culturally
of
more
towards
the
continuous
delivery
than
continuous
deployment,
but
most
organizations
and
and
we'll
look
at
what
are
the
decision
points
in
continuous
delivery?
A
If
you
look
at
any
of
these
pipelines,
the
decisions
are
being
made
at
different
stages
by
different
actors.
Essentially,
what
they
are
doing
is
doing
a
risk
assessment
of
moving
this
code
from
one
stage
to
the
another.
The
developers
are
making
a
decision
on
moving
to
integration,
environment,
quality
people
are
making
a
decision
moving
from
integration
to
staging,
and
you
know,
operations
and
product
owners
are
making
a
decision
moving
from
staging
to
production
and
operations.
A
So
at
each
of
these
stages,
the
actors
are
looking
at
the
data
that's
available
to
them,
either
from
static
code
analysis
or
jira
tickets,
or
in
estimating
the
risk
of
bugs
that
are
found
in
the
system
or
with
the
existing
bugs,
and
maybe
even
doing
a
security
analysis
with
the
pen
testing
and
using
those
results
to
identify
whether
to
go
forward
or
not.
It's
usually
the
case,
there's
zero
issues,
so
that
is
where
the
risk
assessment
is
coming
in
now.
What
are
the
challenges
in
automating?
A
This
process
there's
a
lot
of
human
context
that
is
going
in
today
to
make
these
decisions
so
to
just
give
a
complexity
of
the
issue.
A
couple
of
years
ago,
red
point
came
up
with
the
test
landscape,
as
you
can
see,
based
on
the
number
of
logos
and
the
busyness
of
this
slide,
there's
way
too
many
tools
generating
data
in
way
too
many
formats
and
the
context.
A
A
If
you
like
to
contribute,
please
check
out
the
cdf
sig
events
for
this,
so
the
basic
idea
is
to
have
a
interchange
format
in
between,
and
the
data
that
is
being
generated
by
any
of
these
tools
is
converted
to
intermediate
form
data
and
the
tools
that
consume
that
make
these
decisions
in
automated
way
consume
the
data
in
interchangeable
format.
This
is
one
part
of
the
problem,
at
least
it
solves
the
problem
of
having
the
data
available.
It's
not
context.
The
second
problem
is
the
context
of
the
data.
A
If
you
look
at
security
analysis,
for
example,
let's
take
a
simple
example
of
okay
http,
this
library,
that's
used
in
multiple
services
and
there
may
be
a
vulnerability
based
on
some
header
data,
that's
being
sent
in
now.
If
that
service
is
exposed
to
the
outside
world,
the
risk
is
a
lot
higher
than
if
the
service
is
not
exposed
outside
world
and
the
communication
is
only
between
verified
services
within
that
application.
A
So
that's
the
application.
Context-Based
risk
analysis
that
application
may
already
be
running
in
the
production
and
the
new
vulnerability
is
discovered.
Now
you
have
to
make
a
risk
decision
on
whether
to
shut
down
this
application
until
you
patch
it
or
let
it
continue
all
the
new
changes
that
are
coming
in
with
that
vulnerability
can
be
promoted
to
production
or
not.
So
this
is
the
essentially
the
context-based
decision.
This
operators
and
architects
are
making
and
that's
the
kind
of
thing
we
have
to
incorporate,
also
into
automated
decision
making.
A
The
other
way
to
do
it,
of
course,
is
this
machine
learning
based
systems
where
you
can
teach
the
system,
the
architecture
of
your
application
and
with
the
user
feedback
it
overlays
the
user
feedback
on
the
architecture
of
your
application,
application
specific
risk
assessment
can
be
made.
One
of
the
examples
here
is
at
this
time
of
the
service
deployment.
You
have
the
logs
that
are
being
generated
which
can
have
errors
or
warnings
in
them.
A
The
error,
something
like
a
file
not
found
could
be,
is
see
severe
error
in
some
conditions,
but
not
a
really
high
issue
high
risk
issue
in
some
other
conditions,
so
that
kind
of
a
context
can
be
taught
to
the
system.
When
you
do
the
log
analysis
you
compare
with
the
currently
running
in
the
production,
you
get
the
current
context.
If
the
errors
exist,
then
the
risk
is
low.
A
Some
are
a
lot
more
complex
than
the
others,
but
can
be
applied.
This
is
another
example
with
spinnaker
has
a
component
called
cayeta,
which
also
does
the
automated
analysis
based
on
the
metrics
of
the
deployed
application.
So,
as
you
do
a
canary
analysis,
the
new
version,
the
performance
metrics,
can
be
compared
with
the
existing
production
version.
It
gives
you
differences
like
let's
say
your
threshold
is
100
milliseconds
and
your
production
currently
is
doing
30
milliseconds
and
the
newly
deployed
canary
version
is
doing
50,
milliseconds
or
60
milliseconds.
A
Then
we
know
that
is
acceptable,
but
it's
not
what
you
would
expect
with
the
small
changes
that
we
are
pushing.
So
that's
when
the
human
gets
involved,
and
it
may
be
that
there
are
certain
significant
changes
that
were
made.
That
would
cause
that
issue,
but
in
normal
conditions,
where
the
system
will
be
able
to
say
it's
acceptable
or
not
and
send
it
most
of
the
time
it
passes
through,
and
the
human
intervention
is
only
a
partial
amount
of
time
which
does
the
automated
decisioning
a
lot
better
and
faster
for
your
delivery.