devops and agile release management
DESCRIPTION
Presentation given to Agile Australia 2010, MelbourneTRANSCRIPT
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!