DevOps and Agile Release Management


Published on

Presentation given to Agile Australia 2010, Melbourne

Published in: Technology

DevOps and Agile Release Management

  1. 1. DevOps Agile Release Management Jez Humble, ThoughtWorks Studios Presented at Agile Australia 2000, Melbourne
  2. 2. web 2.0 disrupting traditional businesses
  3. 3. releasing frequently feedback from users Customer developent Agile product development Eric Ries, “The Lean Startup”
  4. 4. releasing frequently feedback from users reduce risk of release John Allspaw: “Ops Metametrics”
  5. 5. releasing frequently feedback from users reduce risk of release real project progress
  6. 6. agile manifesto Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
  7. 7. Production CAB Change = Risk Text
  8. 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. 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. 10. The solution: clams • Culture • Lean • Automation • Measurement • Sharing CAMS model: John Willis and Damon Edwards:
  11. 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. 12. automation Provisioning and managing environments Push-button deployments Database migrations
  13. 13. managing environments If someone threw a server out of the window, how long would it take to recreate it?
  14. 14. managing environments Cloud computing / virtualization Puppet / Chef BDD for environment changes
  15. 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. 16. sharing Open-source model for tools and knowledge Big visible displays include ops data Collaborate, don’t order
  17. 17. objections Visibility and control over locking down Compliance - automation over documentation Auditing - see who does what Make it easy to remediate outages
  18. 18. agile release management
  19. 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. 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. 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. 22. deployment pipeline
  23. 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. 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. 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. 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. 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. 28. thank you!