devops and agile release management

DevOpsAgile Release ManagementJez Humble, ThoughtWorks StudiosPresented at Agile Australia 2000, Melbourne

web 2.0

disrupting traditional businesses

http://code.flickr.com/

releasing frequently

feedback from usersCustomer

developent

Agile productdevelopment

Eric Ries, “The Lean Startup” http://bit.ly/8ZoX5F

releasing frequently

feedback from usersreduce risk of release

John Allspaw: “Ops Metametrics” http://slidesha.re/dsSZIr

releasing frequently

feedback from usersreduce risk of releasereal project progress

agile manifesto

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

http://www.flickr.com/photos/gematrium/4799027100/

Text

Production

CAB

Change = Risk

DevOps

Analysis Development QA Production

Customer VP dev director of testing

director of ops

IT

Business governance

(performance)

Line of business

Corporate governance

(conformance)

VALUE STREAM

GAPING CHASMOF DOOM

Measured on stability

Measured on delivery

Spend most of their time firefighting

Legacy apps, heterogeneous platforms

Crappy software thrown over the wall

80% of IT budget is spent on ops

Conservative, process-heavy (CM)

the pain of operations

The solution: clams

• Culture• Lean• Automation• Measurement• Sharing

CAMS model: John Willis and Damon Edwards: http://bit.ly/bMfh9p

Devs work in ops and carry pagers

Ops have requirements too!

Ops at inceptions, showcases, retros

Cross-functional delivery teams

Trust / access

culture

Database migrations

Provisioning and managing environments

Push-button deployments

automation

managing environments

If someone threw a server out of the window, how long would it take to recreate it?

BDD for environment changes

Cloud computing / virtualization

Puppet / Chef

managing environments

Technical metrics - TPS, response time, hits

Business metrics - revenue, # orders, # users

Ops metrics - changes, incidents, TTD, TTR, TBF

Root cause analysis - which changes break stuff?

measurement

http://www.flickr.com/photos/wwarby/3296379139/

Collaborate, don’t order

Open-source model for tools and knowledge

Big visible displays include ops data

sharing

Auditing - see who does what

Visibility and control over locking down

Compliance - automation over documentation

Make it easy to remediate outages

objections

agile release management

Production-ready software

Fast, automated feedback on the production readiness of your applications every time there is a change - to code, infrastructure, or configuration

value stream mapping

Product opportunity assessment

Product discovery Development Final testing

and approval ReleaseProduct

planning and estimation

Elapsed time

Value-added time3 days 1 week 10 days 7 weeks 1 week 2

hours

1 week 10 days 3 days 5 days 2 days

deployment pipelineDelivery team Version control Build & unit

testsAutomated

acceptance testsUser acceptance

testsRelease

Check in

Feedback

Trigger

Check in

Feedback

Trigger

Trigger

Check inTrigger

Trigger

ApprovalApproval

Feedback

Feedback

FeedbackFeedback

deployment pipeline

ask this question

• “How long would it take your organization to deploy a change that involved just one single line of code? Do you do this on a repeatable, reliable basis?”

• What gets in the way of getting software out of the door?

Mary and Tom Poppendieck, Implementing Lean Software Development, p59.

practices

• only build your binaries once

• deploy the same way to every environment

• smoke test your deployments

• keep your environments similar

• if anything fails, stop the line

different kinds of testing

Functional acceptance tests

ShowcasesUsability testing

Exploratory testing

Unit testsIntegration tests

System tests

Non-functional acceptance tests

(performance, scaling, ...)

Business facing

Technology facing

Critiq

ue p

roje

ct

Support

pro

gra

mm

ing

AUTOMATED

AUTOMATED

MANUAL

MANUAL / AUTOMATED

Diagram invented by Brian Marick

principles

• create a repeatable, reliable process for releasing software

• automate almost everything

• keep everything in version control

• if it hurts, do it more often, and bring the pain forward

• build quality in

• done means released

• everybody is responsible for delivery

• continuous improvement

Make it easy for everyone to see what’s happening

Get everyone together at the beginning

Keep meeting

Continuous improvement (kaizen)

people are the key

http://continuousdelivery.com/http://studios.thoughtworks.com/gohttp://thoughtworks.com/

thank you!