►
Description
Why Saying "CI/CD" is not Enough - Sriram Narayanan, ThoughtWorks
Speakers: Sriram Narayanan
"CI/CD" is becoming mainstream. Various departments are beginning to recognise that silos are harmful and are trying to collaborate. They bring in consultants who guide them on being Agile, set up Scrum teams, advice on CI/CD tools, help set up processes. Depending upon the sense of urgency, this becomes org-wide either from day one or from lessons learned from a pilot project. The measures of success aren't quite well understood and are interpreted and customised to whatever the implementation team feel they can manage to meet within their constraints. Worse, most teams as well as organisation management lack the exposure to know what questions to ask in order to identify gaps and opportunities for improvement. This talk explains why one sees delivery delays, defects in production, integration hell, security bottlenecks, etc having "CI/CD", and the corrective measures.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
A
What
does
it
take
to
make
continuous
integration
happen
and
what
the
country,
the
the
journey
to
continuous
delivery,
looks
like,
and
what
is
it
that
you
can
do
the
general
state
of
progress?
You
know
we
have
the
cdcon
and
everyone's
happy.
We
are
talking
about
deploying
to
kubernetes
there's
micro
services.
A
People
are
starting
to
take
logging
monitoring
and
alerting
very
seriously
right.
We
are
starting
to
look
at
an
api
first
approach
for
creating
tools
for
evaluating
and
purchasing
tools
and,
of
course,
there's
a
lot
of
movement
of
decomposing
monoliths
into
microservices.
There
are
a
lot
of
good
things
like
this
happening
right.
Despite
all
of
this,
despite
adopting
the
so-called
ci
cd,
you
know,
after
setting
up
all
the
right,
continuous
integration,
there
are
still
issues
like
this
security
verification
still
take
time.
There
are
still
configuration
errors,
despite
continuous
deployment.
A
A
This
is
not
to
put
down
any
client.
This
is
actually
a
reality
that
our
clients
face.
They
come
they
they
get
in
all
the
right
consultants.
They
have
set
up
all
the
made
all
the
right
investments
set
up
all
the
right
practices
they
feel,
and
then
they
come
and
tell
us
all
right.
I've
set
up
all
of
these
things,
and
now
you
know,
can
you
help?
Take
me,
get
me
to
the
so-called
next
level.
So
these
are
actual
questions.
A
These
are
situations
where
clients
have
invested,
sometimes
even
a
few
millions
of
dollars
in
you
know,
age,
agl
courses,
scrum
certification,
and
you
know
a
continuous
integration,
setup
and
automated
deployment.
They
do
all
of
those
things,
they
say
they
have
their
ci
and
their
cd
right,
and
yet
they
come
to
us
with
all
these
sorts
of
phrases.
Right
and
they're,
just
actually
surprised
when
at
some
of
the
things
that
we
suggest
to
them
right
and
then
we
have
a
totally
different
class
of
customers,
and
you
know
people
I
meet
in
the
world.
A
People
who
say
hey
all
of
this
sounds
good,
but
you
know
it's
not
for
us.
Why?
Because
of
a
lot
of
the
marketing
messages
or
whatever
impressions
that
they
have?
They
believe
that
a
lot
of
benefits
are
not
for
them.
They
would
rather
just
continue
to
suffer
because
you
know
india
minds
they.
They
believe
they
are
not
ready
for
a
lot
of
these
things
yet
right
or
they
believe
that
hey,
maybe
I've
outsourced.
A
lot
of
my
worry
to
someone
else,
and
whatever
is
left,
is
how
life
is
going
to
be
now.
A
Here
are
some
difficult
questions
that
I
ask
people
right
and
I
do
go
to
clients
and
I
say:
look
we
can
make
continuous
delivery
happen
for
you,
and
you
know
I
give
them
my
usual
pitch.
I
tell
them
some
of
the
benefits.
There
have
been
conversations
where
I've
been
interrupted
and
people
have
told
me.
Let
me
give
you
a
showcase
of
what
we've
already
finished
paying
for
and
we
already
have
it
and
I
look
at
it
sure
they've
got
all
the
right
right.
A
A
They
start
to
wonder
about
as
part
of
our
discussions.
They
start
to
wonder
about.
If
they
have
made
a
code
commit,
do
they
know,
has
it
actually
fixed
their
defect
and
second,
has
it
undone
some
functionality
from
the
past
or
was
some
bug
that
was
fixed
in
the
past?
This
is:
has
that
reappeared
right,
because
many
people
do
not
understand
the
word
regression.
A
A
Does
your
deployment
always
go
through
without
a
hitch
and
as
part
of
your
deployment?
Are
you
also
taking
care
of
configuration
right?
So
when
I
ask
these
sorts
of
questions-
and
I
would
request
you
the
audience
to
kindly
take
note-
these
are
very
interesting
questions
to
ask
this.
These
are
the
questions
to
ask
yourself
about
how
good
is
your
you
know?
Has
your
initiative
been
right,
so
what's
actually
going
on
over
here?
A
How
is
it
that,
despite
people
with
you
know
putting
in
various
amounts
of
money
and
dedicated
dedicating
sincere
time
and
effort,
how
is
it
that
they're
still
facing
issues
right
now?
One
thing
I
I
think,
is
the
term
ci
cd
itself
right,
there's
nothing
wrong
with
continuous
integration,
there's
nothing
wrong
with
continuous
delivery
itself,
but
the
problem
is
with
how
you
know
it
has
been
contracted
and
things
are
lumped
together
and
then
that
d
is
mixed
up
between
deployment
and
delivery
and
and
sometimes
when
continuous
devops.
A
God
knows
what
not
right.
So
here
are
here's
an
actual
screenshot
of
a
conversation
with
jazz,
humble
the
author
of
the
continuous
delivery
book,
an
ex-colleague
of
mine
and
tom
sulson,
who
asked
him
this
question
a
colleague
of
mine
right
now
right
and
you
can
see
his
disappointment-
and
this
has
been
acknowledged
by
many
people,
including
the
cd
foundation,
that
there
is
a
problem
with
using
the
phrase
cicd.
A
Why
exactly?
Is
it
a
problem,
and
what
are
we
going
to
do
about
it?
Let's
see
right
here
are
some
possible
causes
for
misunderstanding,
ci
cd,
so
I
I
I
would
say
it's
a
bunch
of
these,
and
these
are.
This
is
what
I
have
seen
in
my
travels
and
in
my
conversations
with
clients
that
this
is
what
happens,
people
start
mixing
up.
You
know
various
terms
together
and,
unfortunately,
misinterpretations
and
misunderstandings
they
get
in
the
way
of
you
know
actually
manifesting
a
benefit,
and
you
know
really
making
good
use
of
it
right.
A
So
that's
a
bit
sad!
Isn't
it
now?
Let's
just
think
about
it,
a
bit
right,
let
us
think
about
it.
A
bit
there
is
martin
fowler's
favorite,
you
know
famous
article
on
continuous
integration.
There
are
books
on
the
topic.
There
are
many
other
things
and
all
tooling
vendors
also
will
happily
tell
you
about
continuous
integration.
A
Just
thinking
about
it,
continuous
integration
is
when
developers
integrate
code
with
each
other
yeah
frequently
and
that
after
clearing
certain
gatekeeping
checks,
it
does
not.
Continuous
integration
does
not
imply
that
you
therefore
have
to
do
an
automated
deployment
to
a
production
environment
not
yet
ced
for
those
who
call
it
continuous
deployment.
A
Well,
actually,
what
they
actually
mean
is
they
have
gone
and
funded
an
automated
deployment
initiative,
but
just
because
you
have
continuous
because
you
have
automated
deployment,
does
not
automatically
therefore
necessitate
or
you
know,
imply
or
require
that
hey
we
funded
in.
You
know
automated
deployment
initiatives
and
it
has
worked
and
therefore
the
moment
we
get
to
build,
we
just
have
to
go,
live,
there's
no
choice,
because
you
know
we
want
to
be
part
of
the
buzz
in
the
market
by
saying
ci
cd.
No,
no,
no
there's
a
problem
over
here.
A
No!
No!
We
need
to
go
live
all
the
time
right.
So
there
is
always
this
unfortunate
tension
and
you
know
which
need
not
be
there
right.
So
that
is
why
I
have
to
sit
and
explain.
Get
everyone
into
the
same.
You
know
level
of
understanding.
Often
it's
a
lot.
A
lot
of
this
is
social
work.
We
have
to
help
people
understand
that,
ideally,
what
it
means
is
every
commit.
A
We
should
be
able
to
consider
it
as
a
release
candidate.
Practically
speaking,
you
know
you
will
all
not
get
there
very
immediately,
so
we
should
work
towards
making
sure
that
our
code
is
in
a
deployable
and
functionally
correct.
State
and
environment
owners
should
be
able
to
deploy
on
demand
or
upon
readiness.
A
So
this
is
where
an
environment
owner
can
say
all
right.
I
see
that
this
build
is
good.
I
see
that
it
has
been
tested,
and
you
know
various
people's
gatekeeping
checks
have
certified
it.
Let
us
review
together
looks
good,
let's
click
a
button
and
go
live
in
a
different
thread
model
in
our
in
a
different
domain.
Someone
might
say:
hey.
We
trust
our
test,
suite
enough
that,
let's
just
automate
it
that's
where
that
continuous
automated
deployment
is
valid
right.
A
That's
in
these
are
your
famous
cases
of
netflix
and
this
and
that
and
what
have
you
where
people
believe
that,
oh,
if
netflix
can
do
it
and
they're
betting
and
making
billions
on
it?
Why
can't
we
well,
you
should
be
able
to
only
after
you
know,
you
have
provided
the
certain
the
right
kind
of
gatekeeping
checks.
A
So
how
is
it?
What
is
it
that
high
performers
do?
We
will
look
at
it?
How
do
they
fare
right?
This?
The
screenshot
on
the
left,
is
from
the
state
of
devops
report
of
2016..
Please
have
a
look
at
it.
I
I
would
urge
that
you
locate
and
download
it
and
it's
a
wonderful
document.
You
know
the
dora
metrics
has
come
out
of
it
and
many
people
have
lived
off
this.
So
have
a
look
at
that
column,
please,
the
high
id
performance
right,
the
high
it
performers.
A
A
That
is
from
the
time
that
any
sort
of
an
incident
occurs.
How
quickly
can
you
can
you
come
back?
Sometimes
this
is
not
just
a
bug
fix.
It
might
be
nothing
to
do
with
bug
fixes.
It
would
involve
a
lot
of
infrastructure
and
environment
automation
and
also
configuration
right
and
then,
of
course,
the
interesting
thing
change
failure
rate.
This
is
where
a
lot
of
people
stumble
right.
Sure
you
made
in
that
commit-
and
you
know
you-
you
got
all
the
right
executive
clearances
and
you
from
from
commit
to
deploy.
A
You
made
it
under
an
r,
but
do
you
know
that
that
change
that
you
push
into
project
production?
Has
it
caused
a
regression
or
has
it
caused
some
damage
right,
high
performers?
They
have
these
kind
of
ratings,
some
of
the
best
they
work
at
zero
percent
of
change
failure
rates.
What
is
it
that
hive
performers
do?
The
agility
is
not
just
it's
not
just
in
ceremony,
it
is
actually
in
delivery
right
and
the
things
on
the
right
are
the
things
that
they
do
yeah
they
they
are
in
a
position.
A
They
make
sure
that
they
are
able
to
push
changes
with
a
higher
degree
of
confidence.
They
have
the
confidence
to
change
scope
when
they
discover
something
in
production
or
from
user
feedback.
You
have
the
confidence
to
change
scope
yeah.
What
are
the
practices
that
a
lot
of
us
follow?
Those
of
us
who
are
able
to
regularly
who
get
into
that
high
performance
grade.
These
are
the
general
spread
of
practices
that
we
follow.
Actually,
honestly,
there's
a
lot
more,
but
at
the
very
minimum
we
should
be
able
to
have
these.
A
Now
these
the
ci
cd
initiatives,
they
unfortunately
focus
only
on
the
top
right,
too
continuous
integration
and
automated
deployments
people
end
up
underestimating
the
importance
of
environments
of
demand
of
service,
virtualization
and
locking
and
monitoring
people.
Also
completely
forget.
Often,
you
know
that
there's
a
lot
of
automated
testing
and
you
have
to
involve
various
stakeholders
like
qa
and
security
people.
Just
forget
things
like
this
right
now.
What
then,
should
be
the
goal
of
continuous
integration?
A
This
is
my
attempt-
and
this
is
what
I
you
know,
go
and
share
with
clients.
Essentially
I
say
let
us
at
least
start
with
these
four
things
on
the
side.
Let's
make
sure
that
your
code
is
actually
there
in
continuous
in
a
source
code
server
for
many
of
our
clients.
It's
actually
that's
not
even
there
right.
A
They
just
take
a
bundle
from
someone
you
know
from
their
vendors,
they
compile
it
package
it
and
they
just
push
it
out
and
they
say:
oh
wow,
we've
got
it,
but
what
we
have
to
point
out
to
these
customers
is
not
yet
kindly
take
ownership
of
the
code
as
well
right.
So
we
tell
customers
to
take
ownership
of
the
code.
Take
ownership
of
the
ability
to
generate
deployable.
Artifacts,
don't
just
depend
on
your
vendor
to
do
it
right.
You
should
be
able
to
do
it
yourself.
A
Also,
if
nothing,
it
should
happen
on
infrastructure
that
you
own
yeah
the
deployment
and
configuration
of
the
full.
I
t
stack.
This
is
also
it
depends.
There
are.
There
are
places
where
they
put
out
a
tender
or
they
give
out.
You
know
specialized
jobs
to
specialist,
saying
come
set
up
my
environment
on
amazon,
and
then
they
declare
that
they
are
on
the
cloud.
A
But
what
if
something
needs
to
be
changed,
then
they
scramble
to
vendors
again
right,
you
as
a
you
as
an
organization,
should
have
the
full
control
and
the
ability
to
deploy
and
redeploy
an
environment
yeah,
and
what
does
it
mean
to
have
the
verification
of
deployable
artifacts?
That's
where
tests
come
in
we'll
look
at
that.
A
A
It
is
something
that
you
arrive
at
and
what
really
should
happen
is
you
should
have
the
confidence
to
merge
very
frequently
from
your
various
branches
into
the
master
branch
very
frequently
throughout
the
day,
if
you
can
do
that,
and
the
confidence
comes
from
tests,
if
you
can
do
that,
you
realize
at
the
point
of
time
that
you
don't
really
need
too
many
branches.
You
can
just
start
committing
to
trunk,
because
the
ci
is
going
to
run
tests
for
you.
What
would
these
tests
be?
A
These
would
be
tests
something
along
these
lines
right,
so
this
is
a
pipeline
by
the
way,
this
is
a
very
abstract
representation
of
a
pipeline,
but
this
is
what
it
means
to
partly
what
it
means
to
have
a
pipeline.
You
should
have
faster
to
slower
running
tests,
but
the
the
good
bit
is.
You
will
have
an
increasing
amount
of
confidence
right
from
from
left
to
right
from
code
quality,
test
test,
all
the
way
to
security
and
other
functional
tests
and
whatnot.
A
A
This
is
what
the
stock
is
actually
about,
that
once
you've
sorted
out
your
continuous
integration,
where
your
people
are
able
to
integrate
it
now,
it
is
now
important
that
to
reduce
all
those
other
problems
that
people
have
right,
why
is
it
that
it
works
on
a
dev
machine
and
not
in
fraud?
Why
is
it
that,
despite
having
all
the
automation,
we
still
have
defects
in
cloud?
A
You
then,
after
having
continuous
integration
and
the
right
kind
of
testing,
you
now
come
into
these
five
areas,
having
uniform
environments
consistent
deployments
and
configuration
the
automated
verification
of
the
builds
and
also
ensuring
that
you
have
the
fastest
part
to
production.
Please
take
note
fastest
part
does
not
necessarily
mean
zero
manual
intervention,
it
depends
upon.
Your
business
depends
upon
the
threat
model.
Manual
gates
are
sometimes
necessary.
A
Example,
for
example,
where
a
system
owner
needs
to
be
able
to
see
hey
what
have
my
developers
created
and
what
is
it
that
you
know
I
am
allowing
into
the
environment
right,
so
manual
gates
sometimes
are
necessary.
It's
just
that
they
don't
have
to
be
once
in
a
month
or
once
in
a
quarter
or
something
you
can
happily
do
them
five
times
a
day.
Why
would
you
then,
do
it
five
times
a
day,
because
when
you
keep
deploying
very
much
smaller
batch
sizes,
the
amount
of
change
that
you
have
to
view
is
very,
very
small.
A
This
is
very
important
trying
to
make
sure
that
the
patch
sizes
are
small.
Yeah,
so
what
then
is
an
environment
when
we
say
that
you
should
have
uniform
environments?
This
is
interesting,
and
this
is
something
that
I
have
to
explain
sometimes
to
clients,
because
you
know
they
are
not.
Everyone
is
automation,
savvy
right.
So
this
is
something
I
have
to
explain
to
clients
that
hey,
don't
worry
with
the
right
kind
of
infrastructure.
As
code
approach,
you
will
realize
that
your
environment
is
actually
backed
by
scripts.
A
It's
backed
by
logging
and
monitoring
being
outside
the
system.
There
are
third-party
systems
which
you
can't
pay
for
and
host.
You
can
replicate
them
using
a
virtualized
service
and,
of
course,
the
entire
database.
You
can,
you
know,
backup
and
recreate
wire
scripts
also,
so
that
means
you
should
be
in
a
position
to
using
scripts,
come
up
with
an
environment
on
demand,
put
it
to
use
and
then
decommission
it.
A
So
don't
get
don't
get
locked
in
and
don't
get
tied
up
to
an
environment
go
ahead
and
validate
that
those
scripts
repeatedly-
and
you
know,
regularly-
can
recreate
the
environment
for
you.
So
this
once
you
have
approaches
like
this,
you
will
be
able
to
spin
up
more
environments
and
shut
them
down
when
you
don't
need
them,
yeah
that
doesn't
have
to
be
a
single
point
of
failure
or
contention
anymore
this
it.
This
is
what
it
would
actually
lead
you
to.
A
A
Now,
once
you
understand
that
what
then
happens
in
you
know,
what,
then,
does
it
take
to
make
continuous
delivery
happen?
Let's
look
at
the
four
key
metrics
on
the
right
hand,
side.
These
are
the
dora
metrics
right,
but
you
know
these
are
from
that
same
state
of
devops
report
plus,
if
you
look
at
the
dora
metrics,
please
look
it
up
jazz
and
the
others
have
done
a
good
job
around
it.
So
here
are
the
actions
from
left
to
right
which
lead
to
it.
A
This
is
actually
a
slide
that
I
put
together
to
you
know,
help
a
client
understand
that
what
does
it
mean
for
them
to
get
us
in
for
infrastructure
score,
and
where
are
we
required
to
draw
the
line
because
their
devs
have
to
write
the
tests?
So
we
have
to
create
something
like
this
to
help
them
understand
that
for
that
continuous
integration
to
happen,
sure
we
can
stand
up
the
source
code
and
the
ci
platform,
and
all
of
it
sure
we
can
use
amazon's,
api
and
vmware
api
and
set
up
on-prem
and
cloud
infrastructure.
A
Sure
we
can
write
automated,
build
and
deployment
and
configuration.
But
someone
has
to
write
the
tests,
because
it's
only
when
the
tests
are
written,
that
they
would
be
in
a
position
to
have
certified
builds.
This
was
the
big
interesting
aha
moment
for
them.
They
are
not
quite
realized
that
the
certified
bills
are
what
are
important
and
when
you
get
certified,
builds
only
from
tests
where
the
test
comes
from.
A
They
are
run
as
part
of
the
ci
continuous
integration
process,
which
is
facilitated
by
the
continuous
integration
platform
which
uses
a
you
know,
inputs
from
the
code
server.
But
the
code
server
has
to
have
source
code
tests,
build
scripts
and
deployment
scripts.
So
this
is
a
diagram
I
put
together
for
them,
and
you
know
we
were
able
to
work
out
with
various
departments
and
various
project
teams.
What
are
the
conversations
that
we
should
have?
A
What
are
the
lead
times
that
are
going
to
come
up,
and
you
know
what
are
the
kind
of
responsibilities
people
would
have
to
take
up?
For
example,
please
look
at
this
interesting
thing
here:
logging,
monitoring
and
alerting
that's
something
that
we
have
to
tell
people
that
devops
is,
you
know,
is
not
just
a
buzzword
when
it.
If
you
say
that
you
know
development
and
operations
coming
together,
we
need
to
help
you
devs
understand
what
are
the
things
that
usually
go
wrong
in
fraud
and
in
what
way
can
you
support
it?
A
So
that's
where
devs
understood
that
you
know
log
messages
should
be
more
meaningful.
Let
them
not
block
you
know
info
level
stuff
and
only
log
exceptions.
How
could
they
start
working
with
ops
to
understand
what
kind
of
metrics
to
expose
and
surface
those?
So
when
people
start
to
see
things
like
this
right,
they
realize
that
all
right,
this
is
a
journey.
This
is
not
just
a
contract
given
out
to
spin
up
a
few
environments,
and
you
know
declare
that
ci
cd
for
this
year
has
been
achieved.
A
We
will
pick
up
devops
next
year
and
agile
the
year
after
that,
yeah
or
or
maybe
you
just
wait
and
say:
oh
git,
ops
is
the
new
buzz.
Let
me
go
for
it
so,
instead
of
all
of
that
people,
it
takes
them
time
and
often
it
takes
them.
You
know
some
harsh
lessons
in
life
having
wasted
money
in
initiatives
declaring
ci
cd,
it
takes
them
all
of
that
pain
to
realize
that,
indeed
there
is
you
know,
all
of
this
is
needed,
and
every
client
I
have
met.
A
They
end
up
having
their
own
war
stories
around
each
of
these
blocks
yeah.
So
this
is
when
I
then
talk
to
them
about
pipelines.
Also,
this
is
what
a
real
world
pipeline
graph
looks
like
it's,
not
just
those
toy
things
that
you
know
you
will
see
in
any
vendor's
presentation
or
whatever
there's
a
lot
of
politics.
That
happens.
A
You
know
in
multi-vendor
setups,
where
multiple
vendors
or
teams
have
to
work
together,
consume
each
other's
components
and
they
all
go
to
an
environment,
and
then
you
know
it
works
in
their
own
individual
environments,
but
they
are
not
able
to
work
with
each
other.
Why
is
that?
That
is
because
their
interdependencies
are
not
worked
out
very
well
right.
So
this
is
what
we
teach
clients
that
please
pipelines
are
not
just
you.
A
Don't
just
buy
the
next
best
tool
out
there
and
you
know
whatever
and
then
just
go
run
it
they
are
going
to
have
to
be
backed
by
a
tool
that
is
capable
of
actually
modeling
a
pipeline.
Second
you're
gonna
have
to
back
them
by
tests,
for
example.
In
this
case,
this
is
a
scenario
where
component
a
and
b-
and
you
know
they
are
separate
components,
never
mind.
You
know,
debates
about
mono,
repo,
multi-repo
or
whatever,
never
mind
that
what
really
matters
is
beyond
that
it
does
matter.
But
what
matters
more
than
that
is.
A
Are
we
able
to
test
the
two
together
in
this
scenario,
where
service
one
uses
a
and
b
and
makes
use
of
it?
Are
we
able
to
test
the
two
before
we
send
that
service
along
to
a
functional
testing
environment?
Now
imagine
this
scenario
where
service
two
makes
a
call
on
service
one
right
and
the
first
opportunity
to
test
that
would
be
in
the
functional
testing
environment,
isn't
it
so?
This
is
where
we
tell
people
that
look,
it
doesn't
have
to
be.
You
don't
have
to
that.
Doesn't
have
to
be
the
first
time
that
you
test.
A
A
I
know
I'm
doing
all
the
fastest
things
right
now,
but
these
are
the
public
api
contracts
that
I've
agreed
to
fulfill.
If
I
break
it,
I
don't
want
my
bill
to
go
ahead
right,
so
this
is
what
it
actually
means
to
shift
left.
So
this
is
a
diagram
that
my
colleague
jinji.
You
know
she
created
for
me
when
I
described
this
to
her
the
whiteboard.
A
So
this
is
what
it
means
for
you
know.
Various
services
to
work
together.
This
is
how
shift
left
looks
like
in
the
continuous
integration
world.
It
is
not
important
enough
that
you
just
buy
a
jira
or
a
bamboo
or
a
jenkins
or
a
circle.
Ci
license
and
get
done.
You're
gonna
have
to
model
things
this
way
so
that
you
can
truly
shift
less
and
discover
issues
sooner
than
later.
A
Okay.
That
then
gets
us
to
the
cd
right.
When
I
I
point
out
to
clients-
and
I
say
kindly
don't
just
call
it
continuous
deployment-
wait,
call
it
automated
deployment
and
decide
that
do
you
want
to
deploy
on
demand
or
continuously
with
automation,
right
where,
if
the
test
pass,
then
you
just
go
live.
So
this
is
what
I
need
to
help
them
understand
the
difference
between
automated
deployment
and
continuous
deployment
right.
So
it
becomes
a
very
big
shock,
I'll
be
putting
out
these
slides
and
I'm
sure
the
the
event
organizers
will
make
them
available.
A
But
this
is
how
I
help
them
distinguish,
and
I
say
kindly
stop
saying
continuous
deployment.
Call
it
automated
deployment
and
let's
focus
on
continuous
theory,
which
is
a
whole
lot
of
other
things
right.
So
just
so,
you
know
just
to
recap:
continuous
delivery
is
ideally
where
every
commit
can
confidently
be
considered
a
release
candidate
and
practically
where
the
code
is
in
a
deployable
and
functionally
correct
state
and
the
environment
owner
decides
how
the
deployment
should
happen
right.
So
in
closing
comments
once
again,
just
to
recap:
please
set
the
right
expectations.
A
For
yourself,
continuous
value
is
more
than
just
ci
and
automated
deployment.
It
is
the
right
kind
of
test.
You
know,
collaboration
pipeline
composition,
you
know
and
many
other
such
things.
It
does
not
mean
that
you
know
you
cannot
do
ci.
It
does
not
mean
you
cannot
do
cd.
If
you
don't
go
to
kubernetes
and
microservices
on
the
cloud,
you
can
do
this
on
completely
monolith,
apps
and
environments.
You
know
there's
no
such
it
does
not
automatically
mandate
that
you
have
to
go
to
microservices,
there's
no
such
thing.
A
What
you
have
to
focus
on
instead
are
uniform
environments,
consistent
deployment,
consistent
configuration
and
the
right
kind
of
build
and
tests.
Yes,
okay.
Thank
you
very
much
folks.
This
has
been
a
short
talk,
I'll
be
hanging
around,
and
these
are.
This
is
how
you
can
reach
me
kindly
do
reach
me.
I'm
working
on
a
book
called
the
journey
to
continuous
delivery
and
I'm
starting
to
release
parts
of
it
out
over
there
for
people
bye.
For
now.
Thank.
A
I
hope
you
enjoyed
the
talk,
and
this
is
a
topic,
that's
very
dear
to
my
heart
and
I
help
collect.
I
help
clients
with
this
topic.
Quite
all
the
time
and
day
in
and
day
out,
I
have
to
face
these
questions
and
you
know
help
them
achieve
some
reality
checks
and
that's
how
things
go
on
for
them
yeah
and
there's
a
lot
of
resetting
of
expectations
and
whatnot
and
yeah.
It
can
be
a
bit
painful,
but
I
think
all
that
all
and
all
it's
really
worth
it.
A
A
Meanwhile,
in
the
chat
window,
I
also
share
the
link
to
my
talk
or
to
my
slides
on
the
segregation
of
duties.
I
actually
went
and
became
an
auditor.
You
know
to
understand
how
security
auditors
and
and
reviewers
work,
so
that
taught
me
a
lot
about
the
kind
of
how
people
agree
upon
the
intent,
but
the
implementation
goes
nuts,
and
you
know
you
have
very
painful
experiences,
so
I
put
together
that
that
set
of
slidex-
and
I
I
often
give
talks
on
the
topic,
so
I've
given
them
away
at
the
website.
A
A
How
do
you
manage
legacy
security
teams
who
stop
ci
cd
actually
depend
that's
what
I
was
just
saying
that
I
first
talked
to
them,
and
actually
I
make
everyone
agree
that
you
need
to
have
controls.
You
need
to
have
gatekeeping
checks.
The
the
example
I
often
give
to
people
is.
Would
you
be
fine
if
a
dev
did
not
steal
money
from
your
savings
account
directly,
but
when
the
interest
is
computed,
they
reduce
ascent
from
what
was
o
to
you
and
they
took
it
away.
You
wouldn't
like
it
right,
so
you
would.
A
You
would
demand
that
someone
review
the
code.
That's
all
that's
required
just
for
people
to
review
the
code.
Let
people
understand
that
their
controls
are
in
place.
Have
the
various
gatekeepers
recognize
that
their
gatekeeping
checks
have
been
codified
and
you
know
it's
all
baked
into
the
system,
so
I
I
make
sure
that
I
show
people
that
and
that's
the
thing
different.
A
If
you
just
look
in
the
chat
window,
I've
given
the
link
to
the
slide
deck
on
the
segregation
of
duties
and
continuous
therapy,
and
I'm
able
to
talk
this
to
auditors
because
I'm,
I
also
became
an
accredited
auditor
right.
Any
other
questions
do
ask.
We
do
not
have
very
much
time
left
just
about
a
minute.
A
A
A
Right
code
has
been
scanned,
code
has
been
reviewed
and
that
the
right
checks
are
in
place
and
no
tests
got
undone
right
so
that
the
system
does
not
become
functionally
bad
or
instable
or
requests.
So
it
is
more
than
just
scanning
tools,
and
you
know,
security,
os
policies.
It's
also
making
sure
that
what
does
it
take
to
make
sure
that
the
app
is
correct,
your
you
must
have
to
work
kind
of
comprehensive
test
and
then
you're
ready
to
go
live
so
it
is,
it
is
scanning,
but
it
is
more
than
scanning.