►
Description
Keeping your Cutting Edge Platform Cutting Edge: Continuous Delivery of Cloud Foundry - Cora Iberkleid & Kartik Lunkad, Pivotal
So you’ve set up Cloud Foundry. Awesome. Your devs have speed, self-service, agility, no downtime. Great! But wait, there's a platform update? How do you know? It's critical? Hurry and download that file, go patch that dev environment! Good? Great! Now patch your other four environments. Nice job! Time for coffee.
Oh wait - there’s another update? Better get back to your workstation…
Patching and upgrading your Cloud Foundry platform, be it the buildpack, a stemcell, a tile, or Ops Manager itself, is still a manual process. An operator must become aware of new updates, download the files from Pivotal Network, and initiate each update through Ops Manager. Rinse and repeat for each of your foundations. Manual processes are inefficient, cumbersome, and often postponed, leading to risk as potentially important updates are delayed or ignored.
Taking a lesson from the app dev community, we can use the principles and practices of Continuous Delivery to alleviate these challenges. Join us to see how you can set up Concourse pipelines to automate the patching and upgrading of Cloud Foundry itself, such that new releases on Pivotal Network trigger the automated application of updates to all of your foundations. Cuz everyone can use an extra coffee break.
About Cora Iberkleid
Cora Iberkleid is a Senior Cloud Application and Platform Architect at Pivotal, where she helps enterprises leverage modern technologies like Pivotal Cloud Foundry, Spring Boot, and Spring Cloud in order to deliver better quality software faster. Prior to joining Pivotal, she spent nearly a decade designing and building enterprise integration applications as part of the Professional Services organizations at Sun Microsystems and Oracle. She has previously spoken at Meetup events, including Cloud Native New York and New York City Spring User Group.
About Kartik Kushal Raj Lunkad
Kartik Lunkad is a Platform Architect at Pivotal Software Inc. and is currently focused on helping Pivotal’s top Fortune 100 enterprise customers increase their business agility by educating and transforming their technology teams to deliver software quicker with the help of cloud platforms like Cloud Foundry. Prior to joining Pivotal, he had a varied experience in building software pipelines as well as streamlining IT operations. Kartik also obtained his graduate degree from Carnegie Mellon in the field of cloud computing.
A
B
A
Gonna
talk
about
continuous
delivery
of
Cloud
Foundry
so
now
keeping
your
cutting
edge
platform
cutting
edge.
We
think
car
foundry
is
the
cutting
edge
platform,
of
course.
So
how
do
you
keep
it
that
way
once
you've
once
you
install
it
so
I'm
Cora,
Ivor,
Clyde
I
work
for
a
pivotal
out
of
New
York
I'm,
a
platform
architect
I'm.
A
So
ok,
so
the
objective
that
we
want
to
talk
about
is
improving
the
ease,
the
quality
and
the
consistency
of
your
platform
platform,
meaning
not
just
one
cloud
foundry
foundation,
but
all
of
your
foundations
that
compose
the
platform
for
your
enterprise.
So
this
is
what's
known
as
a
platform,
lifecycle,
management
experience
and
we're
gonna
talk
about
the
angle
of
continuous
delivery
so
from
we're
used
to
talking
about
continuous
delivery
from
an
application
delivery
perspective
for
software
development.
But
we
want
to
take
a
look
at
our
platform
with
cloud
foundry
as
from
an
Operations
perspective.
A
A
A
One
of
the
main
ones
is
a
consistent
configuration
and
there's
like
a
bubble
at
the
bottom.
A
consistent
configuration
in
version
parity
across
all
of
our
foundations,
so
there
are,
there
are
enterprises
that
are
running
tens
of
foundations
right
there,
some
that
report
over
30
or
over
40
foundations.
So
how
do
you
make
sure
that
they're
all
running
the
the
same
version
as
each
other
and
that
you
have
a
consistent
configuration
across?
So
that's
one
important
outcome,
also
quick
adoption
of
features,
security
updates.
A
If
you
go
through
all
the
trouble
is
it
meant
you
might
have
experienced
today,
installing
Cloud
Foundry
manually
or
even
trying
to
introduce
your
own
automation
once
you
do
that,
and
you
have
an
environment.
That's
working
well
and
that's
reliable
new
features
come
out
and
you
might
start
to
fall
three
months
behind
six
months
behind
and
you're
no
longer
offering
your
developers.
A
The
latest
features
of
the
platform
that
are
available
or
as
security
patches,
come
out
the
more
time
that
it
takes
you
to
install
the
security
patches,
the
wider,
the
gap
where
you
might
have
a
security
breach
right.
We
saw
recently
in
the
u.s.
Equifax.
There
was
a
struts
patch
that
they
didn't
install
quickly
enough
and,
and
they
were
hacked
exactly
so
by
freeing
up
our
platform
engineers
from
these
more
mundane
tasks.
That
really
can
be
automated,
we're
empowering
them
and
enabling
them
to
work
on
more
creative
activities.
A
C
So
so
that
that
was
the
outcome,
that's
the
outcome
we
think
can
be
achieved
through
through
pipelines,
through
continuous
delivery
of
your
of
your
platform.
What
I'm,
gonna
introduce
now
is
just
just
some
of
the
basic
concepts
around
pipelines
as
to
why
pipelines
and
then
we'll
go
into
talking
about
what
are
the
open
source
cf5
lines
which
are
well.
C
What
are
the
PCF
I
finds
available
and
then,
like
a
quick
summary
of
that,
so
that's
sort
of
the
overall
talk
we're
gonna
do
today,
so
so,
let's
take
an
example
of
an
organization
that
might
automate
their
CF
environment
where
they
would
be
like
really
focused
on
on
saying.
Alright
we're
not
going
to
deploy
CF
or
Bosh
manually
anymore.
We
are
going
to
write
some
automation
for
it.
We're
gonna
make
sure
that
we
have
automation
in
place
for
doing
those
tasks
right-
and
this
is
this
is
an
example
of
an
actual
customer.
C
So
so
what
they
did
was
like,
they
use
gate
gate
for
storing
all
their
manifest
files,
credentials
configuration
files,
so
an
example
could
be
bitbucket
repositories
or
or
something
else,
and
then
they
wrote
some
automation
scripts,
in
this
case
an
example
of
ansible
playbooks.
But
you
could
use
something
else
as
an
approach
to
write
to
install,
deploy
and
update
your
Posh
as
well
as
claw,
foundry
right,
and
then
it
was
doing
pretty
well
for
them
in
a
sense
that
they
were
able
to.
C
So
they
had
this
sort
of
workflow
I
don't
want
to
I,
don't
want
to
spend
too
much
time
on
it,
but
really
they
had
a
development
box,
and
then
they
had
their
production
or
development
environment.
They
would
make
some
changes
in
dev
box.
They
would
push
it
out
to
the
gate
to
bitbucket
and
then
that
would
update
their
matte
Bosch
manifest
and
ultimately
deploy
a
boss,
vector
CF
or
whatever.
The
Brookwood
release
that
were
all
worked
in.
The
sort
of
the
happy
path
scenario.
C
Also
here
in
the
smiley
face
is
the
manual
thing
and
then
the
the
current
is
like
the
automated
way
of
doing
in
alright.
But
what
happened
when
something
went
wrong?
What
happened
when
something
went
wrong
in
one
of
the
Bosch
deployed
deployments
or
maybe
in
at
wash
level
itself?
They
would
go
into
the
the
jump
box,
edit
those
ansible
scripts
or
playbooks
what
they
had
and
updated
their
and
triggered
another
set
of
generated
bosch
manifest.
So
it
would
update
the
bosch
manifest
and
then
do
a
bosch
deploy,
which
is
great.
C
It
fixed
the
problem,
but
but
now
I
got
to
make
sure
the
engineer
who
fix
the
problem
goes
back.
Updates
their
bitbucket
repositories
make
sure
that
they're,
updated
and
good
also
make
sure
that
this
is
not
just
for
this
environment,
but
all
the
other
different
environments.
They
have
it
consistently
configured
across
all
these
different
environments.
Right
now,
let's
use
a
concours
pipeline
based
workflow
I.
C
Definitely
bias
towards
concours
I
think
you
should
use
all
things
conkers
for
any
kind
of
pipelines
right,
not
just
for
laughs,
hungry
but
any
anything
be
from
app
development
to
operational
delivery
pipelines.
You
should
use
conkers,
but
what
is
concours
concours
is
a
pipeline
ci
more
than
CD
system,
but
it
provides
like
a
declarative
configuration
for
for
your
pipelines,
which
means
I
I
can
take
that
declaration,
fight
line
and
move
it
anywhere
if
run
it
on
any
concourse
in
the
world
it.
The
more
important
feature,
though,
is
the
repeatable
builds.
C
The
repeatable
builds
allow
you
to
see
all
right.
I'm
gonna
run
my
pipeline
once
I'm
gonna
run
my
pipeline
to
second
time
and
third
time
and
I
know
those
are
all
fresh
in
fresh,
deploys,
fresh
bills
and
I
know
that
there's
no
residue
from
the
previous
build
and
I
know
that
it
if
it
doesn't
work,
there's
a
particular
change
in
that
build
which
is
not
making
it
work
so
just
using
concourse
as
a
way
to
doing
it.
You
use
your
happy
path,
is
still
great
I
still
edit.
My
manifests
on
development
box.
C
I
trigger
I,
commit
those
changes
on
the
bit
bucket
and
that
triggers
the
whole
workflow,
where
it
runs
the
Concours
pipelines
and
then
updates
the
manifests
and
finally
does
a
Bosch
deploy.
But
what's
more
interesting
is
is
when
things
go
wrong
when
things
go
wrong,
I'm,
not
editing
that
particular
ansible
scripts
on
that
particular
jump
box,
but
I'm
really
editing
my
manifest
still
on
my
dev
box
I
execute
a
task
if
it
runs
fine
I
just
commit
it
right.
C
So
I
have
now
ensured
that
I'm
not
having
inconsistent
configurations
by
just
maintaining
one
place
where
I'm
running
things
off
and
triggering
things
off
so
I
just
want
to
be
like
give
you
a
quick
view
of
it:
I.
Don't
we
don't
I,
don't
expect
everyone
to
just
follow
the
workflow
right
now
and
get
it,
but
just
the
general
idea
of
using
pipelines
and
concourse
pipelines
for
automation.
Your
platform
is
the
key
message.
I
think
you
want
to
send
so
from
now.
I
think
now
we're
gonna
focus
on
first
the
open
source,
CF
pipelines.
A
A
We
have
to
configure
the
infrastructure
before
we
actually
deploy
Bosch
director,
so
there's
a
cool
tool
called
Bosch
bootloader
bubble
for
short
and
again
open
source
available,
so
but
the
command
bubble
up
will
actually
provision
the
infrastructure
for
you
and
deploy
Bosch
director.
So
literally,
as
simply
as
you
see
on
the
screen
by
calling
bubble
up
with
a
certain
set
of
credentials,
that's
what
you
need
for
AWS!
This
also
works
for
Google
Cloud,
and
it
will
work
soon
for
a
sure
as
well,
and
if
optionally,
you
can
create
load
balancers
as
well.
A
Just
by
running
this
command,
you
can
do
a
Bosch
login
when
it's
done
so
both
the
infrastructure
on
on
your
I
as
as
well
as
Bosch
director
things
that,
before
you
know,
involved
following
a
whole
bunch
of
documentation
and
a
whole
bunch
of
steps
bubble
up
that
command
will
output
a
file,
a
JSON
file,
our
bubble
state
JSON
file.
That
has
a
description
of
the
infrastructure
that
it
just
provisioned,
which
you
can
store.
A
You
know,
probably
in
a
private
repo,
would
be
a
good
place
for
it
and
that
bubble
state
JSON
has
all
of
the
information,
including
your
boss,
director
address
and
the
credentials
to
get
to
it.
So,
as
you
can
see
in
the
second
box
to
do
that,
Bosch
login
forever
for
the
values
of
all
those
parameters,
we're
using
the
bubble
command.
A
Assuming
that
that
bubble,
state
JSON
file
is
in
the
same
directory
that
we're
working
in
otherwise,
you
point
to
it,
but
you
can
simply
query
for
director
address
or
username
and
password
and
literally
just
by
following
those
steps.
You've
got
you've
logged
in
to
your
boss
in
your
new,
we
set
up
environment,
so
it
really
is
simple.
So,
in
terms
of
the
pipeline,
we
create
a
job,
a
concours
job.
That's
going
to
ultimately
call
this
bubble
up
command.
A
It's
gonna,
do
it
by
executing
a
task
so
that,
even
though
you
have
to
write
the
job,
the
task
is
provided
for
you
it's
available
and
also
in
a
community
repository
called
CF
deployment,
concourse
tasks
and
a
task
is
simply
a
the
execution
of
a
script
in
an
isolated
environment
with
all
the
resources
provided
to
it.
So
in
this
case,
we
want
to
run
that
bubble
of
command
that'll
be
provided
to
us
in
a
script.
The
isolated
environment
is
going
to
be
a
docker
file.
A
That's
provided
through
docker
hub
that
has,
for
example,
the
bubble
binary
and
so
that
task
dot
yamo
file,
which
is
what
concourse
is
going
to
interpret
the
actual
shell
script.
That
eventually
calls
the
bubble
up
binary
command
and
that
docker
file
are
all
provided
for
you
and
referenced
through
this
task.
Definition
in
CF
deployment,
concourse
tasks
repository
so
the
repository.
This
is
what
it
looks
like.
So,
on
the
left
hand,
side
you
can
see.
The
second
task
listed
is
the
bubble
up
task
so,
on
the
right
hand,
side
we're
digging
into
that
directory
directory.
A
So
it
has
the
Yama
file
for
concourse
to
read
and
the
shell
script
to
be
executed.
That
shell
script
is
what
calls
that
bubble
up
binary
command
and
the
yamo
file
is
pointing
to
that
docker
file.
That's
provided
through
docker
hub,
so
that's
the
whole
definition.
So
your
job
just
has
to
call
this
task
now
we
might
want
to
have
a
little
bit
of
configuration
right
because
well
blow.
As
you
can
see,
it's
quite
opinionated.
It
didn't
ask
us
anything.
It
just
set
up
our
infrastructure
and
deployed
boss
director.
A
So,
there's
an
opportunity
to
tell
the
bubble
up
tasks
to
reference.
Some
ops
files,
which
are
basically
llamó,
manifests
that
get
merged
into
your
boss
manifests.
So
you
supply
that
as
an
input
resource
pointing
it
to
a
directory.
There
are
some
sample
ops
files
inside
of
the
same
CF
deployment,
Concours
tasks,
repo
inside
of
an
operation
directory
things
like,
for
example,
scale
to
1az,
because
the
CF
deployment
that
that
we'll
talk
about
in
a
minute
by
default
follows
a
3
AZ
configuration.
A
So
if
you
want
to
scale
it
down,
you
simply
point
to
this
ops
file
and
it'll
deploy
a
single
AZ
foundation
for
you.
So
this
is
what
your
Bosh
definition
would.
The
job
definition
would
look
like
this
is
this
is
the
example
of
the
piece
that
you
might
have
to
add,
so
you
can
see
the
declaration
of
the
job.
The
first
job
in
our
in
our
three
job
pipeline
is
update,
Bosh,
and
you
can
see
that
it
references
the
obvious
at
the
near.
A
The
bottom
of
the
screen
is
the
obstacles
variable,
which
lists
exactly
which
ops
files
we
are
choosing
to
run
from
that
directory
of
available
operations.
Files,
you
can
also
point
that
to
your
own
operations
directory
and
write
your
own
variations
of
operations
files-
and
you
can
see
this
the
environment
variable-
is
that
previously
I'd
showed
you.
You
could
run
from
the
command
line
to
that
or
pass
to
the
bubble
up
command
itself
and
at
the
end
that
bubble
state
JSON
file
is
stored.
A
A
Script
is
going
to
call
the
actual
bubble
up
command
bubble
up
uses
terraform
under
the
covers
to
set
up
the
infrastructure,
either
on
AWS
or
Google
for
the
moment
as
you're
soon,
and
it
also
calls
Bosh
create
end
to
deploy
Bosh
director
all
by
just
executing
that
job
with
one
mouse
click.
So
that's
easy.
It's
predictable
and
it's
repeatable.
A
So
what
if
you
want
more
a
little
more
control
over
your
is
once
you
call
bubble
up,
you've
got
your
Bosh
cloud,
config
created.
So
you
could
export
that
cloud
config
you
could
edit
that
yamo
file,
and
then
you
could
update
that
cloud
back
up
to
your
boss
director.
That's
one
way
to
do
it.
If
you
want
more
control,
you
can
not
use
bubble,
just
create
the
infrastructure
yourself,
create
your
own
terraform
and
then
call
Bosch
create
em,
which
is
again
what
bubble
does
under
the
covers
right.
So
we
move
forward
to
our
job.
A
Our
pipeline
had
three
jobs.
The
second
one
was
upload
stem
cells,
so
assuming
that
runs
fine,
let's
focus
on
the
update,
CF
job
installer
update
CF.
So
how
do
you
decide
exactly?
You
know
which
components
are
which
sub,
which
elastic
runtime
sub
component
versions
were
running
our
sorry
cloud,
foundry
application,
runtime
components
were
running
so
previously
you
might
have
used
CF
release
to
define
that.
So
this
is
a
more
flexible
replacement
for
that
it
has
a
canonical
manifest
to
declare
the
different
versions
again
CF
deployment
as
an
open
source,
github
repo.
A
That
provides
this
for
you
and
it
it's
just
a
more
readable
and
it
emphasizes
security
and
production
readiness
by
default,
so
that
production
readiness,
for
example,
I
mentioned
that
by
default
you'll
get
a
3
AZ
deployment
and
you
can
use
the
obstacle
to
zingle
AZ
ml
to
scale
that
down.
But
by
default
you
do
get
that
production,
ready,
3,
AZ
deployment,
so
that's
all
defined
in
CF
deployment.
So
we
create
a
job.
That's
going
to
call
UCF
deployment
for
our
Bosh
manifests
to
deploy
the
the
runtime
again.
A
You
can
still
use
ops
files
as
a
way
to
configure
things
at
this
point
in
the
same
way
that
we
would
have
done
it
for
the
bubble
up
job.
You
can
declare
them
at
this
point
as
well
and
cost
custom
common
configurations
are
included
in
that
CF
deployment,
repo
and
finally,
for
a
credential
management.
This
is
also
leveraging
bosch.
2.0
constructs
that
allow
you
previously
all
the
credentials
were
sort
of
interpolated
in
the
manifest
file
and
Bausch
2.0
decoupled
that
the
credential
store
from
the
manifest
file.
A
C
Awesome
so
thank
you,
Cora,
so
that
that
was
about
the
open
source
pipelines.
I'm
gonna
quickly
describe
sort
of
what
the
PCF
pipelines
look
like.
There
are
two
sort
of
benefits
to
this.
Knowing
this
one
fear
of
PCF
customer,
it's
great,
you
know
what
pipelines
to
use,
but
the
other.
Are.
These
pipelines
have
been
used
by
several
customer
scenarios
at
this
point
and
they
have
a
level
of
maturity
that
you
cannot
adopt
those
patterns
even
in
the
open
source
world.
So
I
think
it
is
really
extremely
valuable
to
understand
them.
C
You
could
one
either
you
could
download
them
on
network
pebble
or
I/o.
You
can
sign
up
and
access
those
pipelines
there
or
you
could
access
the
PCI
pipelines
repo,
which
has
all
these
different
different
pipelines.
Well,
so
what
what
are
PCF
pipelines?
Pcf
pipelines
are
for
installing
and
upgrading
of
Posh,
as
well
as
publicly
Foundry,
as
well
as
as
well
as
the
other
data
services
like
RabbitMQ
readiness,
my
sequel,
whatever
that
be,
it
adheres
to
a
certain
reference
architecture.
C
That's
been
defined,
my
parallel
I
saying
things
like
as
as
Cora
mentioned,
like
multi,
easy
environments,
but
also
having
a
particular
number
of
instances
for
say
the
controller
or
the
router,
having
a
sort
of
a
more
si
configuration
for
that
it.
The
pipeline's
are
available
for
AWS,
GCP,
Shore
and
vSphere.
C
It
has
other
other
important
things,
but
really
for
me,
the
most
interesting
one
is
the
jobs
for
wiping
environments,
as
you
would
see,
as
I
will
go
through
the
the
pipeline
itself.
So
this
is
the
install
pipeline.
You'll
see
something
called
the
wipe
environment
job
which
is
which
is
almost
even
before
the
create
infrastructure
really.
But
what
the
wipe
environment
job
is
super
useful
for
is
that
Alright
I
create
my
infrastructure.
I
see
something
going
wrong
and
I
I,
don't
think.
C
That's
the
right
way
to
configure
I
can
use
the
wipe
in
ROM
and
it'll
just
wipe
out
your
environment
and
start
from
scratch
or
use
deployed
boss
director,
you
deployed
your
foundry
now,
you're
still
not
happy
with
it.
Abort
delete
deployment
will
do
a
bottlee
deployment
and
also
remove
the
infrastructure
again
for
you
I
think
it's
a
pretty
cool
pattern
to
have
as
part
of
a
pipeline.
C
It's
also
a
little
bit
risky
one,
so
not
really
expose
that
for
anyone
to
click
and
wipe
out
your
environment,
the
other,
the
other
jobs
here
are
kind
of
similar
to
what
we
had
in
our
open
source
pipeline.
The
one
additional
one
here
is
the
create
infrastructure.
The
pipeline
we
showed
in
the
open
source
one
one
had
like
update,
wash
update,
CA
SM
sells
and
update
CF.
C
Here
you
have
a
job
which
is
create
infrastructure
which
really
uses
terraform
for
say,
AWS
or
DCP,
to
use
this
terraform
to
bootstrap
all
your
infrastructure
required
for
for
setting
up
Porsche
and
Clair
foundry.
After
that,
it's
really
configure
and
deploy
director
jobs
are
just
setting
up
your
boss
and
then
upload
and
deploy
your
TR
just
about
uploading
and
setting
up
your
co-founder
your
own
time,
you,
you
can
have
sort
of
similar,
similar
patterns
for
installing,
say
rabbitmq
Redis,
my
sequel.
So
this
is
a
repeatable
pattern
which
you
can
use
across
other
deployments
as
well.
C
The
upgrade
pipelines
are
are
quite
simple:
the
release
is
something
called
the
upgrade
tile
pipelines
which
are
like
a
generic
upgrade
pipeline
style
is
just
nothing
but
a
Bosch
deployment,
but
converted
into
a
little
more
fancy
and
easier
to
use
sort
of
interface,
but
really
at
the
end
of
the
day.
These
are
each
of
them
are
like
rabbit
ERT
and
my
sequel
are
just
boss
deployments,
and
what
the
good
thing
here
is
that
I
have
something
called
a
regulator
which
is
really
a
way
for
me
to
say
all
right.
C
Every
30
minutes
run
for
something
new.
If
there's
a
new
version,
go
pull
it
up
for
me,
go
fetch
it
up
and
get
it
get
the
new
version
it
then
it
has
two
inputs,
so
it
has
like
the
tile
and
the
schedule
so
either
every
30
minutes
or
if
there
is
a
a
new
version
of
the
tile
again
it
does
the
upload
and
stage
style
and
then
the
apply
changes.
C
Really
the
box
deploy
the
additional
been
bit
about
apply
changes
is
that
if,
if
I
configure
all
my
say
three
deployments
say
RabbitMQ
ERT
and
my
sequel,
if
I
run
a
slight
changes
once
I
can
deploy
all
of
those
three
deployments
at
once.
So
that's
that's
pretty
interesting,
because
what
you
could
do
is
set
up
your
pipelines
in
a
way
where
everything
stops
at
the
second
job.
C
Once
it's
all
staged
and
ready
to
go,
you
click
one
apply
changes
and
all
your
sort
of
several
barge
deployments
will
go
update
all
the
different
components
at
once
and
then.
Lastly,
it's
the
upgrade
bill
pact
pipelines.
It
looks
extremely
complex,
but
it's
actually
pretty
simple.
It's
just
all
the
system
bill
packs
so
right
from
go
to
Java
to
Ruby.
To
binary,
all
of
them
follow
some
of
the
same
structure
from
a
regulator
to
staging
those
bill,
packs
and
then,
ultimately,
promoting
those
bill
packs
in
your
CF
environment.
C
Alright,
so
those
were
like
the
the
pipelines
we
talked
about
today,
the
open
source
ones
and
there's
a
PCF
ones.
Those
are
like
the
basic
starting
out
pipelines.
There
have
been
some
really
advanced
patterns
as
well
built
by
some
some
people
teams,
as
well
as
the
customers
in
pairing
with
the
customers.
The
first
one
is
really
the
Yammer
patch,
it's
kind
of
similar
to
Ops
files
without
yellow
patches.
C
Imagine
it
so
there's
a
team
which
maintains
PCI
pipelines,
they're
building
and
releasing
new
versions
of
the
pipeline's
but
you're
using
those
pipelines,
and
you
have
some
customizations
you
you
want
to
add
to
those
pipelines,
and
that
makes
them
your
own
sort
of
Cloud
Foundry
pipelines
right
now.
What
this
means
is
that
Wendy,
when,
when
the
team
was
building,
these
pipelines
originally
released
new
versions
of
these
pipelines.
C
What
what
really
you
can
do
is
you
can
have
these
yeah
Mel,
patches
or
similar
to
ops
files?
You
have
these
files
or
set
of
yeah
Milles,
which
describe
that
customization.
You
need
and
then
every
time
there's
a
new
version
of
the
pipeline.
You
apply
those
patches
to
your
to
that
version
of
pipeline
and
you
stay
in
sync
with
the
latest,
but
also
have
your
own
customizations
I
introduced
this,
because
I
think
this
is
useful
for
even
in
the
open
source
world,
where
you're
trying
to
say
alright.
C
I
have
these
set
of
environments,
the
development
environment
of
the
engineering
environment
that
maybe
have
the
production
environment
and
then
I
have
certain
customizations
from
production,
but
which
may
not
apply
to
my
dev
or
to
my
sandbox
environments
and
then
okay,
no
all
right.
So
the
the
second
advanced
topic
really
is
around.
Everything
we
spoke
about
today
was
about
single
environment.
What
about
how
do
I
build
pipelines
in
a
way
which
I
can
use
for
multiple
CF
environments?
And
this
could
be
for
different
reasons.
C
C
Those
all
go
to
my
sandbox
environment
I.
Try
everything
there
once
I
feel
confident
and
I
may
go
through
a
few
iterations
there,
let's
just
like
app
development
right
as
you
write
code
for
it,
you
might
have
new
changes
to
your
product.
You
test
those
out
in
development.
You
make
sure
they're
good
and
then
you
release.
Can
you
release
the
that
those
that
bill
of
materials
with
those
versions
do
your
dev
environments,
where
you
feel
great?
C
If
it's
all
gone
good,
then
I
can
go
ahead
and
do
that
same
thing
for
production
right,
this
is
actually
a
more
simpler
version.
They
add
a
little
more
there's
a
more
complex
version
of
this
as
well,
but
I
think
this
is
a
again
I,
say:
there's
an
advanced
topic
and
sets
that
it's
once
you
get
more
maturity
with
your
pipelines,
you
can
start
exploring
these
patterns
because
you're
definitely
gonna
need
them
for
sure.
I
think
that's
about
it.
Just
clicker
stopped
working
all
right
core
to
you.
A
Main
takeaways
from
this
talk
number
one
installing
an
update,
Cloud
Foundry,
has
become
really
easy,
take
advantage
and
enjoy
it.
It's
pretty
cool
and
it's
really
in
a
long
run,
especially
as
your
organization
grows
and
matures,
then
you
know
they're,
more
foundations,
you're,
maintaining
it's
really
the
only
way
to
ensure
that
you
are
providing
the
most
consistent,
secure
and
up-to-date
platform
for
your
organization
and
finally,
continuous
automation
of
Cloud
Foundry.
A
D
B
B
C
B
A
C
C
A
D
C
That
that's
a
really
good
point
and
there
are
some
ways
of
making
sure
that
your
one
way
is
you
when
you
make
smaller
changes
at
the
end
of
the
day,
it's
doing
a
Bosch
deploy
of
CF.
If,
if
you're,
making
smaller
changes,
it
made
us
go
through
the
rest
of
it
and
really
take
a
very
small
time
to
make
a
change.
The
other
way
is
what
we
haven't
mentioned
here.
Is
that
so
the
smoke
tests
part
of
it?
C
A
C
B
I
just
want
to
specify
the
new
versions
into
a
deployment
manifest
not
in
my
pipeline
I,
don't
want
to
update
the
pipeline
every
time.
I
I
have
something
new
to
test.
So
what
is
the
state
of
your
your
work,
your
presented?
It
are
the
the
versions
of
the
Bosch
releases
and
stem
cells
defined
in
the
pipeline
or
in
the
first
appointment.
I.
C
Think
the
the
pipelines
here
specifically
have
the
Concours
deployments
and
they
do
specify
like
the
Bosch
versions.
That's
in
the
actual
Bosch
manifest,
but
I
feel
those
can
be
abstracted
out
to
concourse
variables,
which
you,
which
you
update
whenever
your
parameters
file.
When
you
an
update
those
versions
and
that
that
can
trigger
your
concourse
pipelines,
which
could
trigger
the
deployments.
Basically,
you
could
permit
impairment.
Parameterize.
Your
Porsche
versions,
which
you
want
to
update,
was
that
no.