Webinar: Demonstrating Business Value for DevOps & Continuous Delivery
8 likes•2,082 views
The document discusses DevOps and continuous delivery. It begins with an introduction and agenda. It then discusses transforming IT operations for greater business value, challenges for businesses and IT that DevOps addresses, what DevOps is in terms of people, processes, and tools. It discusses continuous delivery and provides examples of goals and metrics for DevOps initiatives like release frequency, throughput time, and idle time. Finally, it discusses how DevOps tools can work with other tools and processes.
Webinar: Demonstrating Business Value for DevOps & Continuous Delivery
- 1. Demonstrating Business Value for DevOps & Continuous Delivery Chandu Singh, OVUM Andrew Phillips, XebiaLabs | 23 April 2014
- 2. 2 Copyright 2014. Presenters ▪ Chandu Singh Senior Analyst, Software – IT Solutions Ovum ▪ Andrew Phillips VP, Product Management XebiaLabs
- 3. 3 Copyright 2014. Agenda ▪ Introduction ▪ Transforming IT Ops for Greater Business Value ▪ The ‘Why’ and ‘What’ of DevOps ▪ Continuous Delivery ▪ The BIG Picture ▪ Goals for DevOps & Continuous Delivery ▪ Measuring Business Value ▪ Q&A
- 4. 4 Copyright 2014. Using GoToWebinar Questions? Submit via the control panel at any time during the presentation.
- 5. 5 Transforming IT Operations for greater business value § Current State of IT Operations is chaotic § What can we expect in 2014 and 2015? § IT budgets stay flat § Process lag among Dev, QA, Ops continues § Release management remains a challenge § Reasons? § IT is always firefighting § Not enough automation § Fragmentation of ops
- 6. 6 Transforming IT Operations for greater business value § IT Ops requires a structural change § Traditional view of IT is about keeping the lights on § Ops teams spend a lot of time firefighting § The rate of change has quickened, ops teams are spread too thin § Traditional model of IT and Ops not sufficient § Agile and lean principles can help streamline operations § DevOps does just that
- 7. 7 Why DevOps? – Challenges for the Business § The changing business context § Exposure to multiple target platforms – Self hosted, Mobile, Public Cloud § Accelerated pace of development to cope with growing volumes § Businesses need a handle on development processes § IT needs to deliver value sooner, with constant or shrinking budgets § Need to ensure optimal performance and security of production apps § Business needs higher throughput from IT § DevOps brings Agile practices and thinking to operations § Helps remove slack from the value delivery chain
- 8. 8 Why DevOps? – Challenges for IT § The traditional separation between Dev and Ops not working § Defects caught in production take a long time to fix in development § Code in dev and production soon goes out of sync § Diminishing process visibility, need for better KM practices § High offshore attrition rate, lack of skilled resources § The rate of handoffs has increased § Operations can’t cope with the increased workload and ensure production stability simultaneously § Release automation solutions help make deployments more predictable § And provide diagnostic , troubleshooting information in case of failures § Increasingly operators are taking on development responsibilities and vice versa § A holistic approach to IT is needed, ITSM can serve as the glue between Dev and Ops § Also close the loop from the end user side by integrating defect tracking with the help desk
- 9. 9 What is DevOps? § DevOps is Agile Operations § DevOps goals § Better resource provisioning for production § Better collaboration between different teams § Better release management § Less production defects § More automation § Shorter release cycles § Continuous Delivery § Streamlined process from development to deployment – A pipeline! § Improved production performance management
- 10. 10 What is DevOps? § Dev is agile, operations needs to be agile too! § Integrated dev and ops § Invest in § People § Processes § Tools § Plan for Continuous Delivery § Reduce test backlog § Implement test automation earlier in the lifecycle § Templates & best practice guides § Increase accountability, reduce handoffs
- 11. 11 What is DevOps? – People § Organizational structure § Cross functional teams § Organize for micro agility § Move the ball together § Reduce handoffs § Skill development
- 12. 12 What is DevOps? – Process § Start early, plan ahead! § DevOps considerations should be incorporated at the requirements stage itself § A major chunk of the non functional requirements are indeed operational aspects of the system § Production monitoring § Transaction logging, metrics collection § Security § Target platform configuration management § Availability
- 13. 13 What is DevOps? – Process § After the requirements and design stage, DevOps is about automation and collaboration § Automate development activities such as § Builds § Tests § Deployment § Devs - Collaborate with Ops § Look at the application end to end § Post release § Monitor § Measure § Improve through iteration § Don’t forget – ITSM the glue! We need to close the loop from the end user side.
- 14. 14 What is DevOps? – Tools § What can be automated? § Builds – Build Management, Build Automation § Tests – Test Management, Test Automation § Deployments – Environment Provisioning and Deployment Automation § Release Coordination and Management § System Configuration and Roll-Out § Metrics Collection and Monitoring § Collate Metrics for capacity planning § Trend and Issue analysis § Share metrics among teams for better collaboration § Feedback helps improve performance § Performance Management § Organizations already have some pieces of the puzzle!
- 15. 15 What is DevOps? – Tools (Cloud) § Why DevOps in the cloud? § Clouds can be accessed through APIs and are therefore programmable § Infrastructure elements turn into programmable components and can be automated § Location transparency allows scaling or node failures to be handled more effectively § DevOps in the cloud is about automation and repeatable processes § Automation helps you scale effectively § Resources can be provisioned on demand § With DevOps + Cloud your resource requirements go down § Helps create self-healing systems § Dynamic Dev, QA, and Production Environments § Continuous Integration and Continuous Deployment
- 16. 16 Continuous Delivery § To automate the deployment of changes, new versions of software to production environments if they pass all quality checks. § DevOps is an idea, continuous delivery is an implementable process. § It’s a moving target for most organizations § Aim for continuous delivery and whatever you hit will be an improvement over the status quo § Design apps for continuous delivery – manage system state in config files § Do UAT in production!
- 17. 17 The BIG picture – DevOps Adoption § DevOps will not work with the ‘hole in the floor’ approach § Stakeholder buy-in is essential to DevOps success § It is easy to get bogged down with definitions and buzzwords § Understand what DevOps means in the context of your organization § Understand why it’s required, and the problem that you are trying to solve § Identify where the process bottlenecks are
- 18. 18 The BIG picture – The takeaway § To improve, you need feedback on what went wrong § To improve faster, you need faster feedback § Managing enterprise IT in the present context is about constantly improving/shortening the feedback loops § Agile is for business agility § Enabling IT to deliver sooner, and exploit opportunities within their value-frame. § Enable IT to correct course in-flight with shorter feedback loops § Shorter feedback loops are possible by dividing the work in manageable chunks § Atomic accountability
- 19. 19 Some Numbers on Release Mgmt. § Faulty releases account for 70% of all production failures; 30% is faulty code. § DevOps and CD help achieve faster time to market by avoiding big bang releases, and with the help of automation. Around 20% time saved. For greater benefits orgs need service virtualization during testing. § Avoid faulty releases by 70% (see above), more importantly minimize the business impact of a faulty release with automated rollback. Restore service 10-15x faster. § Release frequently in short increments 80-100% safer releases. NO more code freeze!
- 20. 20 Case Study – a large global financial services company § Company A was used to half yearly, big bang releases. Roughly 37-40% of all releases failed on first deployment. Invariably the error would be due to a manual error, such as missing config file entry, wrong path, wrong IP when moving to production from staging and so on, at times the defect would take a few hours time to locate and fix. In a few cases it would be a code error and it would take longer. § The devs and operations team were scared of releasing code, they ran through lengthy checklists, code reviews, the whole team spent 2-3 days preparing for the release. For a 15 member team it meant wasting around 300 person-hours per release. § With DevOps & CD (automation) the release prep time has come down to 20 minutes per release. They release more frequently, averaging 3 releases a month, an 18x increase. Faults due to manual error have been eliminated.
- 22. 22 Copyright 2014. Goals for DevOps & Continuous Delivery ▪ DevOps & Continuous Delivery are powerful principles, but they are not organizational goals ▪ We’ve just heard about some measurable goals companies have successfully defined for their DevOps & CD initiatives ▪ Ultimately, there’s only one metric that matters for most enterprises:
- 23. 23 Copyright 2014. Goals for DevOps & Continuous Delivery ▪ DevOps & Continuous Delivery are powerful principles, but they are not organizational goals ▪ We’ve just heard about some measurable goals companies have successfully defined for their DevOps & CD initiatives ▪ Ultimately, there’s only one metric that matters for most enterprises: The Bottom Line
- 24. 24 Copyright 2014. Goals for DevOps & Continuous Delivery ▪ DevOps & Continuous Delivery are powerful principles, but they are not organizational goals ▪ We’ve just heard about some measurable goals companies have successfully defined for their DevOps & CD initiatives ▪ Ultimately, there’s only one metric that matters for most enterprises: The Bottom Line − But it’s surprisingly hard to gain useful information about the impact of a new feature on the bottom line if changes are always Big Bangs − One important goal of DevOps & Continuous Delivery is thus to enable smaller changes to be made more regularly to allow for better analysis of the effectiveness of changes − Of course, we need to have the ability to monitor business value generated by our systems in order to make this possible!
- 25. 25 Copyright 2014. Goals for DevOps & Continuous Delivery ▪ So “frequency of releases to production” and “number of changes per release” are interesting metrics to track
- 26. 26 Copyright 2014. DevOps & Continuous Delivery Metrics ▪ Other common DevOps & Continuous Delivery goals that we see:
- 27. 27 Copyright 2014. DevOps & Continuous Delivery Metrics ▪ Other common DevOps & Continuous Delivery goals that we see: ▪ Availability and use of “self-service” functionality − Can be used to measure level of team empowerment and lack of dependency on specialists
- 28. 28 Copyright 2014. DevOps & Continuous Delivery Metrics ▪ Other common DevOps & Continuous Delivery goals that we see: ▪ Availability and use of “self-service” functionality − Can be used to measure level of team empowerment and lack of dependency on specialists ▪ End-to-end throughput time − Measures how quickly a feature or fix can get from idea to customer
- 29. 29 Copyright 2014. DevOps & Continuous Delivery Metrics ▪ Other common DevOps & Continuous Delivery goals that we see: ▪ Availability and use of “self-service” functionality − Can be used to measure level of team empowerment and lack of dependency on specialists ▪ End-to-end throughput time − Measures how quickly a feature or fix can get from idea to customer ▪ “Idle time” in the delivery process − Can be used to track how many time-consuming “handovers” still need to happen in the process
- 30. 30 Copyright 2014. DevOps & Continuous Delivery Metrics ▪ Other common DevOps & Continuous Delivery goals that we see: ▪ Availability and use of “self-service” functionality − Can be used to measure level of team empowerment and lack of dependency on specialists ▪ End-to-end throughput time − Measures how quickly a feature or fix can get from idea to customer ▪ “Idle time” in the delivery process − Can be used to track how many time-consuming “handovers” still need to happen in the process ▪ Duration of longest task(s) in the pipeline − Indicator of the current biggest pain point(s) that can be tackled next
- 31. 31 Copyright 2014. How Does XL Platform Work with Others? Change Management/ ITIL tools Build, Test, Deployment, Provisioning AutomaCon Planners, organizers & communicaCon tools Manage the change process Orchestrate, Deploy & Test Synchronize data Release team Business Owner DevOps team
- 32. 32 Copyright 2014. DevOps & Continuous Delivery Metrics ▪ Self-service cloud environment instantiations
- 33. 33 Copyright 2014. DevOps & Continuous Delivery Metrics ▪ Throughput time and release “scorecard”
- 34. 34 Copyright 2014. DevOps & Continuous Delivery Metrics ▪ Identifying “idle time”
- 35. 35 Copyright 2014. DevOps & Continuous Delivery Metrics ▪ Long-running tasks and phases
- 36. 36 Copyright 2014. Measuring Business Value ▪ Don’t forget to take a baseline before you start! − Value Stream Mapping is a useful technique here
- 37. 37 Copyright 2014. Measuring Business Value ▪ Don’t forget to take a baseline before you start! − Value Stream Mapping is a useful technique here ▪ Introduce changes incrementally and evaluate impacts one-by-one − Again, avoiding “Big Bang” helps identify which improvements are most effective
- 38. 38 Copyright 2014. Measuring Business Value ▪ Don’t forget to take a baseline before you start! − Value Stream Mapping is a useful technique here ▪ Introduce changes incrementally and evaluate impacts one-by-one − Again, avoiding “Big Bang” helps identify which improvements are most effective ▪ Give changes time to settle − There’s almost always an initial cost associated with a tooling or process change
- 39. 39 Copyright 2014. Measuring Business Value ▪ Don’t forget to take a baseline before you start! − Value Stream Mapping is a useful technique here ▪ Introduce changes incrementally and evaluate impacts one-by-one − Again, avoiding “Big Bang” helps identify which improvements are most effective ▪ Give changes time to settle − There’s almost always an initial cost associated with a tooling or process change ▪ “Both Dev and Ops are much more productive” ▪ “We reduced deployment times for weeks to minutes”
- 40. 40 Copyright 2014. Delivery Automation Platform App 1.0 App 2.1 App 2.0 App 1.2 Dev Test 1 Test 2 QA1 QA2 PROD Private / Public Cloud
- 41. 41 Copyright 2014. Next Steps ▪ Get started with XL Platform today! http://go.xebialabs.com/Try-XL-Platform ▪ Learn more about XL Platform: http://www.xebialabs.com/products/xl-platform/ ▪ More Information Products: www.xebialabs.com/products Blog: blog.xebialabs.com Twitter: @xebialabs Videos: vimeo.com/xebialabs
- 42. Thank You!