Continuous Delivery refers to the process of releasing high quality software quickly and with confidence through the use of build, test and deployment automation. By applying Lean techniques to the development, test and deployment of software, waste is reduced and staff are freed up to work on more important tasks. By following a continuous delivery model, release cycles shift from a matter of months to weeks or days. In this presentation, we will look at the key tools and processes involved in transitioning from a manual culture to one that embraces automation. We will look at real world examples, including the tools and architectural components. We will discuss organizational impacts, including the dramatic improvements in morale as team delivery commitments are met more easily through automation.

1. CONTINUOUS
DELIVERY
Will
Iverson,
CTO
Michael
McIntosh,
Dir.
Business
Development

2. Agenda
• Who
are
you?
• Who
is
Dynacron
Group?
• What
is
Con>nuous
Delivery?
• What
pains
does
this
solve?
• Why
It
Ma@ers
(By
Role)
• Drill
down
on
a
few
topics/examples
• Next
Steps
• Q
&
A

3. Who Are You?
• Technology
Manager
• Technology
Implementer

4. Who Are We?
• Dynacron
Group
• Based
in
Kirkland,
WA
• Founded
in
2010
• ~25
Consultants,
~30
Total
Staff
• www.DynacronGroup.com

5. What is Continuous Delivery?
• Con>nuous
Delivery
(CD)
is:
• a
set
of
principles
and
prac>ces
in
growing
use
in
soYware
development
to
improve
the
process
of
soYware
delivery.
• Techniques
such
as
automated
tes>ng,
con>nuous
integra>on
and
automated
deployments
allow
soYware
to
be
developed
to
a
high
standard
and
easily
packaged
and
deployed
to
test
environments.
• This
results
in
the
ability
to
rapidly,
reliably
and
repeatedly
push
out
enhancements
and
bug
fixes
to
customers
at
low
risk
and
with
minimal
manual
overhead.
* Wikipedia Definition

6. I want to
know about
continuous
Delivery
because…!
TODAY’S GOALS

7. Pain & Opportunities
• Tell
me
what’s
involved
in
doing
a
release?
• How
long
does
it
take?
• How
many
steps
are
involved?
• How
successful
is
the
process?
• How
oYen
do
you
do
them?
• Do
you
have
“heroes”?
• What
would
happen
if
a
par>cular
environment
disappeared/melted
down?
• Do
your
environments
match?
• How
quickly
can
you
build
an
environment?
• How
hard
is
it
to
do
a
patch?
A
major
release?

8. Current State of Affairs

9. Current State Problem Summarized
• Key
Pain
Points:
• Painful
releases
• Inability
to
predict
delivery
affec>ng
business
commitments
• Deployment
to
environments
• Code
quality
• Environment
configura>on
&
management
• Expensive,
>me
consuming
manual
QA
(unable
to
build
lab)
• Par>al
Agile
implementa>on
(Scrum
but
no
technical
processes)

10. Why?
• What
are
some
of
the
causes
of
these
pain
points?

11. Target State
• Commitments between teams & functional areas are automated
& tracked in systems
• Teams use fast automation instead of slow manual processes

12. So… Why Not?
• New
Tools
• Maven/MSBuild/etc,
N/JUnit,
Jenkins/Hudson/TeamCity/TFS,
Selenium,
SauceLabs,
Puppet/MS
Config
Mgr…
• New
Processes
• Where
do
I
get
builds?
• Organiza>onal
Impact
• Cross-­‐func>onal
manager
buy-­‐in
• New
Designs
• Stateless
systems
• Environments
from
tools,
not
manual
• Iner>a
• Comfort

13. Stuff To Learn
Project
QA/SDET Development IT/Ops/DevOps
Management
Agile (Scrum/Kanban/XP) u u u u
Unit Testing  u u 
Functional/Web Testing  u /u 
Test-Driven Development  u u 
Continuous Integration  u u 
Binary Repository  u u u
Distributed Version Control
 u u
(e.g. Git)
Stateless Architecture  u u
Environment (Cloud/
   u
Virtual)
 = Understand Concepts u = Understand Technical Implementation

14. Project Manager’s View
• Agile
• Itera>ve,
reduce
risk…
• Unit/Func>onal/TDD
• If
requirement
exists
in
a
test,
you
won’t
have
to
worry
about
regressions
• Full
regression
suite
run
in
minutes,
not
hours/days
• Con>nuous
Integra>on
• Solidifies
ongoing
work
meaning
of
“Done”
• Binary
Repository
• Radically
simplifies
release
meaning
of
“Done”

15. Example: Automated Traceability
• Story
wri@en
&
tracked
in
backlog
tool
• e.g.
Story
#25431
in
Rally
• Story
is
mapped
to
automated
tests
• Tests
are
roughed
out
as
WIP
automated
tests,
checked
in
with
Story
#25431
• Story
is
implemented
by
development
• Code
checked
in
with
Story
#25431
• Story
is
referenced
by
automa>cally
generated
release
notes
&
bundled
into
build
• Build
#456
has
Story
#25431
• Ready
for
release
–
just
send
an
email
“Promote
#456
to
shared
QA”
• Everything
automated
&
traceable

16. QA/SDET View
• Biggest
shiY
is
moving
from
manual
regression
to
automa>on
• New
tools
&
skills
• Vastly
improved
produc>vity
• Other
key
changes
• Automa>ng
produc>on
of
builds
vastly
reduces
stress
• Move
from
fire-­‐figh>ng

17. Example: Selenium

18. Example: SauceLabs
• Instant QA Lab
• 50-200 machine build?
• Video & screenshots for easy sharing
• Parallel Test Execution
• e.g. 200 tests x 5 browsers = 1000 tests
• Run 50 parallel threads = complete in 15
minutes

19. Developer’s View
• Spend
a
LOT
more
>me
wri>ng
GOOD
code
• Comfortable
refactoring
• Know
that
your
refactoring
is
not
breaking
things
• Know
that
you
can
fix
technical
debt
• Never
hear
“works
on
my
machine”
again
• Never
have
to
sit
wai>ng
for
a
build/release/manual
test
pass
• Clear,
established
standards
for
defini>on
of
done

20. Example: Binary Repository
Continuous Source
Integration Control
Server Source
All work
tracked,
The image cannot be displayed. Your computer
versioned
may not have enough memory to open the image,
or the image may have been corrupted. Restart
your computer, and then open the file again. If
the red x still appears, you may have to delete the
Reference
Build & Test QA
image and then insert it again.
Server
Source Runs tests
before Binary
committing Compiled Repository
Code
Applications Stage
to source
control. Stores all
Developers
release
artifacts
Prod
Libraries
All builds reproducible.
Code matches release. Vastly reduces wait time.
Enforces a standard build, test & release environment.
Broken builds notify developer immediately without breaking build. Standardizes work product.

21. IT/Ops View
• Releases
are
solid,
every
>me
• Releases
are
always
in
the
same
place
• Releases
have
excellent
documenta>on
• Most
of
which
is
machine
generated,
so
it’s
always
current
&
up
to
date
• Configura>on
systems
instead
of
tribal
knowledge
means
you
can
actually
go
on
vaca>on
• Solid,
stateless
releases
can
go
out
during
normal
business
hours,
so
you
can
enjoy
evenings
&
weekends

22. Example: Simplified Releases
Centralized Virtual Environments /
Private Cloud
Binary
Repository
Applications Applications Applications
Stores all QA Stage Prod
release
artifacts
Versioned Versioned Versioned
Configuration Configuration Configuration
Configuration Management System

23. NEXT STEPS
How
do
we
get
started?

24. Starting Points
• Plaoorm
Moderniza>on
• Incremental
Rolling
Upgrade
• Take
exis>ng
applica>on[s],
upgrade
to
new
plaoorm
• Pro:
No
requirements
churn
• Goes
much
faster
than
you
would
expect
• Con:
S>ll
need
to
>e
into
business
ini>a>ve
(new
L&F?)
• New
Applica>on[s]
• Pro:
Build
new
func>onality
with
a
clean
start
• Con:
S>ll
have
legacy
environment
to
maintain

25. Typical Engagement
• Assessment
• Gap
analysis
between
current
systems
and
target
state
• Applica>on
Inventory
• Tool
recommenda>ons
• Training
• Group
learning
• Execu>ve
&
Management
Baselines
Established
• Execu>on
• Combine
with
business-­‐value
project
for
paired
implementa>on
• Typically
a
replaoorming
or
new
project
• Best
bang
for
buck:
Clean
up
old
systems
&
code
first
• Convert
exis>ng
manual
tests
to
automa>on,
modernized
build/release,
convert
to
stateless

26. Partner Attributes
• Exis>ng
people,
process
&
tools
• Established
architecture
&
infrastructure
• Experience
with
hands
on
implementa>on
• Training
&
pairing
for
long
term
rela>onship
• Local,
hybrid
team
engagements
• Reference
accounts

27. Q&A