A Continuous Delivery Maturity Model

Continuous Delivery
Maturity Model

InfoQ.com: News & Community Site
• 750,000 unique visitors/month
• Published in 4 languages (English, Chinese, Japanese and Brazilian
Portuguese)
• Post content from our QCon conferences
• News 15-20 / week
• Articles 3-4 / week
• Presentations (videos) 12-15 / week
• Interviews 2-3 / week
• Books 1 / month
Watch the video with slide
synchronization on InfoQ.com!
http://www.infoq.com/presentations
/continuous-delivery-model

Presented at QCon New York
www.qconnewyork.com
Purpose of QCon
- to empower software development by facilitating the spread of
knowledge and innovation
Strategy
- practitioner-driven conference designed for YOU: influencers of
change and innovation in your teams
- speakers and topics driving the evolution and innovation
- connecting and catalyzing the influencers and innovators
Highlights
- attended by more than 12,000 delegates since 2007
- held in 9 cities worldwide

UrbanCode Inc. ©2013
Who is that guy?
 Techie at UrbanCode
- (now IBM)
 Working on CI & CD
tools for the last 10
years.

IMVU’s Extreme CD: 1 App to Prod, 50 times / day
Build
Run thousands of tests
Deploy to some servers
Monitor
Deploy to remaining servers

Mature or crazy?

Why a maturity model?
How awesome is my team?
Winning!

Why a maturity model?
 Where are we now?
 What are other people doing?
 Where do we want to be?
 How do we get there?
The future is here. It’s just not evenly distributed yet.”
- William Gibson

The Model

Credit Where Due

5 Levels
Base
Beginner
Intermediate
Advanced
Extreme

Four categories, held together with culture

Dependencies are the hard part

Deploying

Big question: how do we coordinate components?
 Build Pipeline Tool
- Pressure development to adapt to this model
 CI tool + Application Deployment Automation Tool
- Add a tool that pulls from the various build systems

When is each approach appropriate?
Pipeline
 Simple apps
 Low coupling between
components / services
 Tests validate ONE version
of ONE thing
 Shared tool ownership ok
Build + ADA
 More complex applications
 Higher coupling between
components / services
 Tests validate that the larger
system is working
 Dev wants to own build,
Ops wants to own deploy

Most people fall into the Build + ADA pattern
Pipeline here

Measure & Test

Communication & Reports

There are inter-dependencies

Standard Target
Based on this model, the standard target is:
 Continuous builds on a distributed grid using
dependency management
 Auto-deploy to the first environment
 Extensive testing of multiple types
 Test results and trends are widely visible
 Self-service deployments to other environments
- Production style deployments everywhere
- Deployments coordinate tiers/services as appropriate

We’re not all the same

Applying the Model

Basic Plan
 Audit where you are
 Understand the pain points & bottlenecks
 Agree on where you want to be
 Prioritize

Example Persona: El Emeno Investments
 Securities trading is a key profit center
 Fast updates desired
- Exploit transient opportunities
 Strict legal requirements & audits
♫
Audit RulesDelivery TeamBusiness
Faster!
Slow
down, be
careful!

Make it safe to go fast

Audit for El Emeno
 Build
- Continuous integration (each team has own tool)

Audit for El Emeno
 Build
 Deployment
- Some scripts, mostly manual
- Hand-offs by email
- Coordination of components based on dev oral history

Audit for El Emeno
 Build
 Deployment
 Measure & Test
- 20% unit test coverage
- Almost no functional tests
- Security scanning tool run manually

Audit for El Emeno
 Build
 Deployment
 Measure & Test
- Security scanning tool run manually
 Communicate
- Silo’d and emailed with hand-off requests

Bottlenecks for El Emeno
• Manual regression tests are too
slow
• Never allocated enough time
• Environment outages problematic
Measure
• Manual / semi-scripted
deployments are slow
• Cost of compliance is high
• Errors in deployment are risky
Deployment

Bottlenecks for El Emeno
• Mostly okBuild
• Need easy audit trail for
approvals and deployments
• Shared reporting a“nice-to-have”
Communicate

Desired state
Today
 Build
- Continuous integration (each team
has own tool)
 Deployment
- Coordination of components based
on dev oral history
 Measure / Test
- Security scanning tool used& run
manually
 Communicate
- Silo’d and emailed with hand-off
requests
Future
 Build
- Good artifact management key
 Deployment
- Consistent self-service deploys in
all environments
- Integrated with approvals & good
audit trails
- Coordinate tiers & services
 Measure / Test
- Need regression testing of core
functionality
- Security scanning should happen
automatically
 Communicate
- Produce test, security scan, and
approval logs for releases

Scoring current vs future
0
1
2
3
4
5
Build Deploy Testing Reporting
Current
Future
Base
Beginner
Intermediate
Advanced
Extreme

Prioritization: observations
 Deploy & Test are biggest weaknesses
- Development responsiveness is a strength
 Testers are spending time de-bugging bad
deployments

Prioritize: Plan of attack for El Emeno
1 Get deployments decent.
- Ensure we have an artifact repo for builds
2 Invest Dev & QA time savings into regression tests
3 Re-evaluate in 6-12 months

A simple maturity model
Urbancode.com/resources

What are you doing Monday?
Download the Maturity Model and talk your team
Are we where we need to be?

What are you doing in two months?
 Implementing updates to your Continuous Delivery
capabilities

Thank you!
@EricMinick
Urbancode.com/resources/

A Continuous Delivery Maturity Model

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (19)

More from C4Media

More from C4Media (20)

Recently uploaded

Recently uploaded (20)

A Continuous Delivery Maturity Model