►
From YouTube: Elisabeth Hendrickson - Using PaaS for Continuous Delivery (Cloud Foundry Summit 2014)
Description
Technical track breakout session presented by Elisabeth Hendrickson, Pivotal.
With continuous delivery, you release frequently and with very little, or no, manual intervention. That requires three things: fully automated tests; a continuous integration server that executes those tests and can promote successful deployments; and an automated deployment mechanism with zero downtime. PaaS's are a perfect fit for this. Cloud Foundry makes zero-downtime automated deployments straightforward. Further, cloud-based CI services such as Cloudbees work well with Cloud Foundry. In this talk, Elisabeth explains how to achieve continuous delivery with Cloud Foundry using one of our own applications (docs.cloudfoundry.org) as an example.
A
Furthermore,
the
hard
part
about
continuous
delivery-
probably
is
not
your
deployment
infrastructure
anyway.
That
said,
Cloud
Foundry
is
perfect
for
continuous
delivery.
So
before
we
talk
about
continuous
delivery,
let's
talk
very
briefly
about
continuous
integration,
partly
because
when
I
talk
to
people
about
continuous
integration
and
say
you
know,
talk
to
me
about
continuous
integration,
they
immediately
say:
oh
yeah
Jenkins
know
that
the
Jenkins
part
is
actually
the
most
boring
part
of
it.
You
could
do
this
with
a
bunch
of
cron
screw
cron
jobs
and
shell
scripts.
A
A
We
have
tests
right
people
tests
well
good,
good,
yeah
you're,
just
not
enthusiastic
cuz
you're
thinking
beer
me
in
between
yeah
anyway,
so
they
run
all
the
local
tests
make
sure
everything
is
working
well
before
it
even
checks
in
then
they
check
in
and
then
Jenkins
or
pick
your
favorite
flavor
of
continuous
integration
takes
over
and
runs
the
build
and
makes
sure
that
everything
is
green.
That
is
continuous
integration
by
Martin
fellers
definition.
The
thing
about
continuous
integration
is
that
Jenkins
is
not
the
hard
part.
A
Automated
system
tests
that
the
development
team
feels
no
sense
of
ownership
over
whatsoever
and
those
tests
start
failing
and
the
build
is
technically
red
and
it
will
stay
that
way
for
months,
because
nobody
cares
that
the
people
who
wrote
those
tests
don't
have
the
power
to
fix
it
and
the
people
who
do
have
the
power
to
fix
it.
Don't
think
that
those
tests
are
valid,
so
the
biggest
problem
with
continuous
integration
is
going
to
be
the
culture
change.
A
Now,
let's
talk
about
continuous
delivery,
you're
laughing
because
you
experienced
this
I,
don't
actually
know
you
so
I'm,
not
saying
this
because
I
know
him
I'm
saying
this
because
I
recognize
that
laughs
all
right.
So
let's
talk
about
continuous
delivery
hint.
It
is
not
just
a
whole
bunch
of
see
I
just
like
CI,
isn't
just
a
Jenkins
server,
continuous
delivery
by
Jess
humbles
definition
and
he's
the
guy
who
wrote
the
book
so
I'm
gonna
go
by
his
definition.
It
means
that
your
software
is
production
ready
from
day
one.
A
You
could
theoretically
put
this
thing
in
production
right
now.
It's
now
a
business
decision
about
whether
or
not
you're
going
to
and
the
way
you
know
that
you
could
put
it
in
production
right
now.
Isn't
because
there's
some
theoretical
notion
of
done
or
done
done
is
because
you
actually
put
it
in
something
that
looks
like
production
all
the
time.
A
So
that's
continuous
delivery.
You
have
some
preconditions
before
you
can
get
there.
First
of
all,
you're
gonna
have
to
have
fully
automated
unit
integration
system
tests
with
the
associated
sense
of
ownership
and
people
believe
that
those
tests
actually
test
useful
things,
and
none
of
this
nonsense
about
known
failures
do
any
of
you
have
tests
where
you
have
known
failures.
They
fail
and
you
oh
yeah,
that
yeah
none
of
that
you
do
need
to
have
your
continuous
integration
infrastructure
stood
up
whatever.
A
That
is
that
it
looks
like
I,
don't
actually
care
if
you
use
Jenkins
I,
where
we're
using
go
CD
and
we're
really
happy
with
go
CD
kind,
something
we're
also
using
Jenkins,
raising
lots
of
things.
So
anyway,
you
also
need
to
have
scripted
automated
deployments.
Yes,
we're
Cloud
Foundry
comes
in
the
last
one.
A
If
any
of
those
things
go
red.
If
any
one
of
those
tests
go
red
and
anyway
want
for
those
in
those
various
configurations,
then
your
pipeline
is
blocked
and
you're
gonna
need
to
clear
it,
which
means
that
you
have
to
have
the
culture
in
place.
That
says
Oh.
Something
is
red
I'm
going
to
clear
it.
So
culture
changes,
overcoming
resistance,
I
hear
these
kinds
of
things
all
the
time.
Why
would
we
even
bother
our
customers?
Don't
want
this
stuff
that
fast
that
one
drives
me
nuts
Automation
is
expensive.
This
sounds
really
hard.
A
What
do
you
mean?
There
is
no
QA
phase,
isn't
there
at
the
manual
regression
tests?
What
do
you
mean
you're
doing
away
with
those?
You
must
not
believe
in
quality.
Yeah
I
love
that
one
too,
as
though
that
assure
is
quality,
is
anybody
actually
ever
seen
a
really
really
long
manual,
regression
phase
a
sure
quality?
No,
anybody
any
really
we'll
talk
after
because
I'm
gonna
suggest
that
you're
confusing,
despite
in
because
anyway,
so
not
fair.
For
me
to
pick
on
you
I,
don't
know
you
either
I'm
really
sorry.
Moving
on
change
is
super
hard.
A
However,
each
one
of
those
excuses
has
a
really
good
reason
why
it's
not
a
valid
excuse
and
I'm
happy
to
talk
with
anybody
at
length,
because
I
live,
eat,
breathe
and
sleep
this
stuff,
so
I
would
say
catch
me
during
the
rest
of
the
conference,
but
this
is
kind
of
it.
Isn't
it
right
catch
me
on
Twitter
I'm,
at
test
obsessed,
so
moving
on
the
actual
reason
for
this
talk,
continuous
delivery
with
Cloud
Foundry,
and
why
is
Cloud
Foundry
perfect
for
this?
A
Well
remember
that
automated
deploy
thing,
Cloud
Foundry
has
some
super
cool
features
that
enable
that
automated
deploy
stuff
to
work
really
well
for
your
continuous
delivery
environment.
First
of
all
same
exact
code,
different
space,
now
there's
a
little
caveat
here,
because
I'm
not
in
marketing
and
so
I'm,
not
just
gonna
sort
of
say,
oh
look
promotion.
We
don't
actually
have
a
promotion
feature.
Yet
it's
kind
of
in
that
application
category
that
James
Bear
talked
about
in
the
roadmap
session.
However,
you
can
make
it
look
like.
A
Yeah,
the
guy
who's,
the
PM
for
the
CF
tool
by
the
way
is
looking
at
me
and
just
grinning
as
I
say
that
hi
Scott
right
ii,
awesomely
cool
feature
that
comes
with
a
little
itty-bitty
teeny.
I
tiny
asterisk,
as
james
bear
talked
about
in
the
roadmap
session.
We
don't
currently
have
a
feature.
That's
called
blue
green
deploys.
However,
you
can
totally
do
blue
green
deploys
with
cloud
foundry,
because
we
have
this
it's
in
the
documentation
and
contact
me
on
twitter
at
test
obsessed,
if
you
have
any
trouble
finding
it.
A
Actually,
if
you
just
google
blue
green
deploy
cloud,
foundry
you'll
totally
find
it
an
entire
set
of
steps
about
here's,
how
you
do
a
blue-green
deployment
with
cloud
foundry
so
that
you
end
up
with
zero
downtime
to
your
users.
If
you're
doing
continuous
delivery,
you
want
to
be
deploying
lots
and
lots,
and
if
you're
deploying
lots
and
lots
and
every
single
time
you
deploy,
there's
a
nonzero
probability
that
you
have
just
dropped
sessions
or
like
killed
your
users.
That
would
be
sad.
They
will
be
very
sad
about
that.
A
So
instead,
if
you,
if
you
do
a
blue
green
deploy,
then
they
will
be
happy
because
they
won't
even
notice
the
fact
that
you've
been
upgrading
the
code
out
from
under
them
until
you
change
the
entire
user
interface.
Don't
do
that
to
them,
so
moving
on
I
did
want
to
mention
our
own
example.
Internally.
I
also
run
that
so
you
know
I
with
the
squirrel.
I
totally
forgot
to
do
the
intro
and
explain
who
the
heck
I
am
I'm.
A
The
director
of
quality
engineering
for
cloud
foundry
happy
to
talk
about
how
we
do
build
quality
into
our
products
at
any
time
with
anybody
as
part
of
that
I
run
the
docs
team,
all
of
our
Doc's
run
as
apps
on
cloud
foundry.
So
we
do
continuous
integration
and
continuous
deployment
for
our
documentation
as
an
application.
So
it's
a
great
little
use
case
because
we're
using
our
own
stuff
to
deploy
something,
that's
very
much
production
and
that
we
very
very
much
care
about
all
of
our
documentation
is
modular.
A
We
have
a
whole
bunch
of
little
git
repositories
for
good
reasons.
That
I'll
explain
some
other
time
when
I'm
not
standing
between
you
and
beverage
of
choice,
but
as
soon
as
a
writer
checks
in
a
change
to
any
of
those
that
those
modules
it
kicks
off
three
to
five
builds
because
we
have
to
publish
three
different
versions
of
our
documentation
and
those
three
different
builds
that
kick
off.
It
might
sound
weird
to
build
Docs.
Well,
maybe
it
doesn't
depending
on
how
much
experience
you've
had
with
with
building
Docs.
A
But
in
our
case,
what
we
need
to
do
is
assemble
an
entire
docked,
set
and
publish
that,
and
in
doing
that,
we
want
to
make
sure
we
have
no
broken
links.
So
our
tests
aren't
tests
of
the
application,
which
is
just
a
little
Sinatra
thing,
serving
up
static
content.
Our
tests
are
to
do
link
checking
so
our
little
build
pipeline
for
our
production
documentation
involves
check-in,
something
to
the
to
one
of
the
modules
for
the
documentation
that
kicks
off
the
builds
that
assembles
everything
checks.
A
All
of
the
links
then
deploys
to
our
staging
site
where
we
can
do
a
review
so
that
people
can
look
at
it
and
then
we
can
automatically
very
very
quickly
I
turn
that
into
something.
That's
that's
live
on
the
site,
which
means
that
we're
actually
updating
our
it's
our
documentation
sites,
at
least
once
a
week,
frequently
more
often
than
that
yeah
once
a
week
sounds
like
it's,
not
continuous,
but
it
is
continuous
because
we
could
do
it
at
a
moment's
notice.
So
that's
my
example.
You
might
be
wondering
things
like
well.