DevOps and Agile Release Management

Uploaded on

Presentation given to Agile Australia 2010, Melbourne

Presentation given to Agile Australia 2010, Melbourne

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. DevOps Agile Release Management Jez Humble, ThoughtWorks Studios Presented at Agile Australia 2000, Melbourne
  • 2. web 2.0 disrupting traditional businesses
  • 3. releasing frequently feedback from users Customer developent Agile product development Eric Ries, “The Lean Startup”
  • 4. releasing frequently feedback from users reduce risk of release John Allspaw: “Ops Metametrics”
  • 5. releasing frequently feedback from users reduce risk of release real project progress
  • 6. agile manifesto Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
  • 7. Production CAB Change = Risk Text
  • 8. DevOps GAPING CHASM OF DOOM Business Corporate governance governance (performance) (conformance) Measured on Measured on delivery stability Line of IT business director of director of Customer VP dev testing ops Analysis Development QA Production VALUE STREAM
  • 9. the pain of operations Legacy apps, heterogeneous platforms Crappy software thrown over the wall Spend most of their time firefighting Conservative, process-heavy (CM) 80% of IT budget is spent on ops
  • 10. The solution: clams • Culture • Lean • Automation • Measurement • Sharing CAMS model: John Willis and Damon Edwards:
  • 11. culture Ops have requirements too! Ops at inceptions, showcases, retros Devs work in ops and carry pagers Trust / access Cross-functional delivery teams
  • 12. automation Provisioning and managing environments Push-button deployments Database migrations
  • 13. managing environments If someone threw a server out of the window, how long would it take to recreate it?
  • 14. managing environments Cloud computing / virtualization Puppet / Chef BDD for environment changes
  • 15. measurement Business metrics - revenue, # orders, # users Ops metrics - changes, incidents, TTD, TTR, TBF Technical metrics - TPS, response time, hits Root cause analysis - which changes break stuff?
  • 16. sharing Open-source model for tools and knowledge Big visible displays include ops data Collaborate, don’t order
  • 17. objections Visibility and control over locking down Compliance - automation over documentation Auditing - see who does what Make it easy to remediate outages
  • 18. agile release management
  • 19. Production-ready software Fast, automated feedback on the production readiness of your applications every time there is a change - to code, infrastructure, or configuration
  • 20. value stream mapping Product Product Product Final testing opportunity planning and Development Release discovery and approval assessment estimation 2 3 days 1 week 10 days 7 weeks 1 week hours Value-added time Elapsed time 1 week 10 days 3 days 5 days 2 days
  • 21. deployment pipeline Delivery team Version control Build & unit Automated User acceptance Release tests acceptance tests tests Check in Trigger Feedback Check in Trigger Feedback Trigger Feedback Check in Trigger Feedback Trigger Feedback Approval Feedback Approval
  • 22. deployment pipeline
  • 23. 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.
  • 24. 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
  • 25. different kinds of testing Business facing AUTOMATED MANUAL Showcases Support programming Functional acceptance Usability testing tests Critique project Exploratory testing Unit tests Non-functional Integration tests acceptance tests System tests (performance, scaling, ...) AUTOMATED MANUAL / AUTOMATED Technology facing Diagram invented by Brian Marick
  • 26. 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
  • 27. people are the key Get everyone together at the beginning Keep meeting Make it easy for everyone to see what’s happening Continuous improvement (kaizen)
  • 28. thank you!