A great deal of confusion surrounds the concepts of release automation, continuous integration, continuous delivery, and continuous deployment. Even some industry experts are confused about the differences. How these concepts work progressively to achieve high quality software delivery is generating a lot of discussion and controversy. Bryan Linder defines the methodology, processes, and tools associated with release automation, as well as the differences between its maturity levels. Understand the benefits of more frequent, smaller releases, and the exponential risk generated by large, infrequent releases. Hear highlights of industry case studies that demonstrate the substantial speed, quality, and ROI gains of improving your release automation process. Acquire the insight and motivation needed to take the next step—from wherever you organization is now—toward full release automation. Takeaways include a glossary of terms, a continuous integration tools comparison chart, and a release automation maturity chart.

1. 4/23/15
1
Release Automation
Better Quality
Faster Deployment
Amazing ROI
Overview
METHODOLOGY
PROCESS
TOOLS

2. 4/23/15
2
DevOps = Release Automation
DevOps is
Methodology It’s a way of doing
things, not what
things to do.
DevOps with Agile
DEVELOPMENT
EXECUTIVES
BUSINESS
IT
OPERATIONS
AGILE
DEVOPS

3. 4/23/15
3
HP Case Study
> 3
year
transformaFon
Fme
(2008
to
2011)
> Overall
dev
costs
reduced
by
~40%
> AcFve
programs
in
development
up
~140%
> Dev
costs
per
program
down
78%
> Resources
freed
up
to
work
on
innovaFon
up
500%
They
went
from
Build
cycle
=me:
1
week
TO
3
hours
(10–15
builds
per
day)
Commits:
1
code
commit/day
TO
100
commits/day
Regression
test
cycle
=me:
6
weeks
TO
24
hours
How?
• Architecture
DirecFon
• All
LaserJet
code
in
main
trunk
• Design
to
fight
impediments
mid-­‐sprint
(put
out
fires/
phoenixes)
• Full
system
in
Dev
• Acceptance
test
in
non-­‐
integrated
environment
• IntegraFon
uses
“test
doubles”
• CI
to
CD
to
CD
• Test
AutomaFon
and
Process
AutomaFon
• Planning
Process
(Agile
and
DevOps)

4. 4/23/15
4
Economics
Puppet
Labs
2014
DevOps
Survey
DevOps
Users
30X
more
frequent
deployments
8,000X
faster
lead
Fmes
than
their
peers
50%
fewer
failures
Automation Maturity
Con=nuous
Deployment
CD
CI
Test
AutomaFon
CD
CDel
CI
Test
Automa=on
EFFORT
MATURITY

5. 4/23/15
5
CI Roadmap
• “Keep
a
single
place
where
all
the
source
code
lives
and
where
anyone
can
obtain
the
current
sources
from
(and
previous
versions)
• Automate
the
build
process
so
that
anyone
can
use
a
single
command
to
build
the
system
from
the
sources
• Automate
the
tes6ng
so
that
you
can
run
a
good
suite
of
tests
on
the
system
at
any
;me
with
a
single
command
• Make
sure
anyone
can
get
a
current
executable
which
you
are
confident
is
the
best
executable
so
far.”
-­‐Mar;n
Fowler
“Con;nuous
Integra;on”
(Essay)
September
2000
CI Process
Plan
IteraFon
• Review
and
EsFmate
Code
• Unit
Test
Build
• Unit
Test
• Unit
IntegraFon
Test
Deliver
• Acceptance
Test
Deploy
• Acceptance
Test
Performance
and
Security
TesFng
too!
Performance
and
Security
TesFng
too!
Performance
and
Security
TesFng
too!
Performance
and
Security
TesFng
too!

6. 4/23/15
6
CI in Action
Code
Unit
Test
Build
Integrate
Unit
IntegraFon
Test
Deliver
to
ENV
IntegraFon
is
just
pugng
units
of
code
together
and
tesFng
them
that
way.
ConFnuous
IntegraFon
is
doing
this
on
every
change.
Example:
3
team
members
code
new
components
and
unit
test
them.
They
pass.
Then
you
put
them
together
in
Dev
with
the
rest
of
the
system
and
something’s
broken
(Unit
IntegraFon
Test
fails).
CI in Action
Code
Unit
Test
Build
Integrate
Unit
IntegraFon
Test
Deliver
to
ENV
STOP!
OK,
so
the
new
code
didn’t
work
with
the
rest
of
the
system.
Then
what?
ROLLBACK.
Revert
your
exisFng
environment
to
the
previous
code
base
–
preferably
automaFcally
-­‐
and
go
fix
the
problem(s)
right
then
and
there.
Once
fixed,
THEN
you
can
try
again,
and
if
it
works
move
on
to
bigger
and
bener
builds.

7. 4/23/15
7
Why use CI?
• MarFn
Fowler,
in
his
September
2000
essay
on
CI
explained
that
integraFng
once
per
week
doesn’t
take
5x
as
long
as
once
per
day…
it
takes
25x
as
long.
• Why?
Risk
calculus:
• Maciej
Zawatzki,
Director
of
the
Deploy
and
Release
Product
Line
at
IBM
Urban
Code
explains
in
his
video
• YouTube:
hnps://www.youtube.com/watch?v=f9NAZmtxYJg
• IBM:
hnps://developer.ibm.com/urbancode/videos/
urbancode-­‐video-­‐blog-­‐1-­‐term-­‐devops/urbancode-­‐
video-­‐blog-­‐4-­‐risk-­‐calculus-­‐release-­‐management/
Automate Everything
• “Automate
the
build
process”
• “Automate
the
tesFng”…
and
all
that
supports
it
• Make
it
truly
automaFc.
Saved
a
client
75%
execuFon
Fme
doing
this
last
year.

8. 4/23/15
8
Code Change Demo
CD… and CD
• ConFnuous
Delivery
(CD)
• ConFnuous
Deployment
(CD)
• Both
processes
• Both
keystone
pieces
of
Release
AutomaFon
DELIVERY
DEPLOYMENT
Absolutely
required
for
successful
DevOps
projects!
Not
for
everyone.

9. 4/23/15
9
Delivery vs. Deployment
Unit
Tests
Unit
IntegraFon
Tests
Deliver
to
<Your
Pre-­‐
Prod
ENV>
Acceptance
Tests
Unit
Tests
Unit
IntegraFon
Tests
Delivery
to
<Your
Pre-­‐
Prod
ENV>
Acceptance
Tests
Deploy
to
Prod
Post-­‐Deploy
Tests
DELIVERY
DEPLOYMENT
“Con6nuous
Delivery
doesn't
mean
every
change
is
deployed
to
produc;on
ASAP.
It
means
every
change
is
proven
to
be
deployable
at
any
6me.”
-­‐Carl
Caum
Compile
Code
Run
Unit
Tests
Run
Unit
IntegraFon
Tests
Deliver
to
Pre-­‐
Prod
Environments
Run
Acceptance
Tests
Deploy
to
Prod
Run
Acceptance
Tests
Run
AddiFonal
Post-­‐Deploy
Tests
Massive Speed = Massive ROI

10. 4/23/15
10
Questions?
Thank You!

11. 4/23/15
11
Risk Calculus
Complexity
=
the
number
of
relaFonships
between
features.
(n2
–
n)
/
2
(n
=
number
of
features)
Going
back
to,
in
general,
1
out
of
3
items
being
defect
density,
this
tells
me
how
many
defects
to
expect
from
integra6on
itself.