Microsoft's journey to DevOps and how it transformed their development process
•Download as PPTX, PDF•
0 likes•415 views
Microsoft struggled with long development cycles that did not allow them to quickly respond to customer feedback. They adopted a DevOps approach to break down silos between development and operations and allow for faster and more continuous delivery through automation, collaboration, and streamlining of processes. This enabled them to integrate feedback into new releases more rapidly and improve products incrementally based on customer usage data.
Recommended
Recommended
More Related Content
What's hot
What's hot (17)
Viewers also liked
Viewers also liked (16)
Similar to Microsoft's journey to DevOps and how it transformed their development process
Similar to Microsoft's journey to DevOps and how it transformed their development process (20)
More from Himanshu Desai
More from Himanshu Desai (10)
Recently uploaded
Recently uploaded (20)
Microsoft's journey to DevOps and how it transformed their development process
- 2. A Microsoft’s journey to DevOps VISUAL STUDIO
- 3. Introduction
- 4. Why DevOps?
- 5. Where the process came from Planning Beta ? RTM ? Code Test & Stabilize Code Test & Stabilize 2,5 years The development process Feedback was requested after each milestone – planning, Beta, RTM. With this process, bugs were found and they were fixed - no problems there. But Microsoft couldn’t react to anything customers using the product were telling us. For the most part, Microsoft would tell everybody “sorry”… and push things to the next release.
- 6. It’s Development and Operations collaboration It’s a job title It’s automation It means faster and smaller releases
- 7. Develop + Test Plan + Track Monitor + Learn Release Development Production
- 8. The DevOps conversation PEOPLE Collaborate more Share common goals Focus on improvement BRINGING PEOPLE TOGETHER PROCESS Eliminate waste Increase efficiency Streamline feedback DELIVERING VALUE FASTER TOOLS Enhance productivity Enable collaboration Facilitate experimentation EXECUTING THE DEVOPS STRATEGY
- 9. FLOW OF CUSTOMER VALUE AUTONOMY and ALIGNMENT BACKLOG improved by LEARNING EVIDENCE gathered in PRODUCTION MANAGED TECHNICAL DEBT PRODUCTION FIRST MINDSET INFRA as a FLEXIBLE RESOURCE
- 10. FLOW OF CUSTOMER VALUE AUTONOMY and ALIGNMENT BACKLOG improved by LEARNING EVIDENCE gathered in PRODUCTION MANAGED TECHNICAL DEBT PRODUCTION FIRST MINDSET INFRA as a FLEXIBLE RESOURCE Infrastructure as Code Cloud Dev/Test Automatic Scaling Sandboxing/Dev and Test Labs Containerization Microservices Architecture Testing in Production Usage Monitoring User Telemetry Stakeholder feedback Feature flags Experiments Scaled Agile Self-managing teams Feature crews Automated Testing Continuous Integration Continuous Deployment Release Management Usage Monitoring Telemetry Collection Testing in Production Stakeholder Feedback Peer Code Reviews Automated Testing Continuous Measurement Agile Documentation Shift-Left into the Inner Loop Application Performance Management Infrastructure as Code Continuous Delivery Release Management Configuration Management Automated Recovery
- 12. C O N T I N U O U S I N T E G R A T I O N C O N T I N U O U S D E P L O Y M E N T R E L E A S E M A N A G E M E N T A U T O M A T E D T E S T I N G
- 14. S E L F - M A N A G I N G T E A M S PLANNING CHATS F E A T U R E C R E W S SPRINT RITUALS SCALED AGILE T EAM RO O M S
- 16. U S E R T E L E M E T R Y U S A G E M O N I T O R I N G S T A K E H O L D E R F E E D B A C K A / B T E S T I N G I N P R O D U C T I O N
- 18. T E S T I N G I N P R O D U C T I O N STAKEHOLDER FEEDBACK U S A G E M O N I T O R I N G U S E R T E L E M E T R Y F E A T U R E F L A G S
- 20. S H I F T - L E F T C O D E M E T R I C S T E S T A U T O M A T I O N P E E R C O D E R E V I E W S C O N T I N U O U S I N T E G R A T I O N C O N T I N U O U S U N I T T E S T I N G
- 22. A P P L I C A T I O N P E R F O R M A N C E M A N A G E M E N T C O N F I G U R A T I O N M A N A G E M E N T I N F R A S T R U C T U R E A S C O D E A U T O M A T E D R E C O V E R Y C O N T I N U O U S D E L I V E R Y R E L E A S E M A N A G E M E N T
- 24. I N F R A S T R U C T U R E A S C O D E D E V E L O P E R S A N D B O X I N G C L O U D D E V / T E S T L A B S C O N T A I N E R I Z A T I O N M I C R O S E R V I C E S A U T O S C A L I N G F A I L O V E R
- 25. OLD WORLD Focus on planning Compete, not collaborate Static hierarchies Individual productivity Efficiency of process Assumptions, not data NEW WORLD Focus on delivering Collaborate to win Fluid and flexible teams Collective value creation Effectiveness of outcomes Experiment, learn and respond
- 26. stories.visualstudio.com | microsoft.com/devops DevOps at Microsoft Products and guidance based on our own learnings when moving to the cloud
- 27. The Microsoft DevOps Solution VISUAL STUDIO
- 28. Greater productivity for enterprise application development & delivery Plan, execute & monitor your entire testing effort Manage complexity and close the loop between Development & IT Ops Create mobile business applications for Android, iOS and Windows Visual Studio Enterprise An integrated, end-to-end DevOps solution for developers looking for high productivity and coordination across teams of any size. Leverage advanced tools and services to design, build, deploy and manage complex solutions, modern applications and services for Android, iOS, Windows, web, cloud and desktop.
- 31. 1 Plan
- 32. 2 Develop + Test
- 33. Release
- 34. Monitor + Learn
- 35. © 2016 Microsoft Corporation. All rights reserved.
Editor's Notes
- Since 1975, Microsoft has done development a certain way – the waterfall way. But 6 years ago, they saw grave danger appearing on the horizon. Our business was rapidly changing around us – we had to turn our ship around to survive. --------------------- Microsoft have an imperative called cloud-first, mobile first It is a different world and requires fundamentally different kind of development and operations process Customers expect more and more frequent deliver and realised that traditional roles cant get in the way of this new way. Microsoft realised that what had worked two decades ago, having separate engineering systems in separate groups, was now hurting them. IT was very challenging time for them, basically what they used to tell people is that products baked – Not a very satisfying experience for them and their customers They needed to apply the same things they learned from agile planning into the world of Devops They figure that developers and operations people work closely together throughout the entire phase of development all the way from design through deployment and production What DevOps brings to Agile is finishing that cycle and allowing them on this rapid cadence of not just build and test but actually release it to our customers and bring that feedback in, then help improve what we‘re building. It is about reducing the barriers between the teams even further. They are bringing what they called „Feature Crew Program management, Engineering & Ops It means that they will interact with their customers directly. There isnt there is not a barrier between what they do day to day basis and customers consumning that. That really close coupling between the individuals that are writing the code, and the individuals that are operating the service itself allows us to get capabilities into production much more rapidly. This is whwere they saw Devops playing a really critical role in helping companies keep up with the industry and being able to deliver a t this incredible rapid pace and incredibly high expectations that customers have for continous innovation. This allows them to be very nimble. It allows them to react to changing trends in the technology in the industry, remaining innovative and stay competitive in the market Today they ship every 3 weeks, overtime, they are going to ship every day. If you‘re in the business of software and you‘re not operating your software, you are on a oneway street of irrelevance and there is no questiosn about it.
- It was – and still is - the time of Agile and DevOps. We had to formulate a DevOps strategy for our entire organization. But what is DevOps? It can mean radically different things for different people!
- For us, DevOps means the merging of two previously isolated lifecycles – development and IT operations. A converged DevOps lifecycle gives us the ability to execute on ideas quickly and iterate on feedback rapidly, with minimum friction.
- We quickly realized that our DevOps transformation will have broad organizational impact. Every DevOps conversation needs to focus on people, processes and tools equally, otherwise the transformation will fail.
- Our DevOps journey began with the definition of seven DevOps habits, habits that we have refined over time. DevOps habits are broad mindset changes that everybody in our organization has to actively embrace and live every day. Let‘s look at them individually.
- Our DevOps journey began with the formulation of seven DevOps habits, refined over time. DevOps habits are broad mindset changes that everybody in our organization has to actively embrace and live every day. Let‘s look at them individually. How to get customer feedback from within VSTS? https://www.visualstudio.com/en-us/docs/work/connect/get-feedback
- Flow refers to an organization’s ability to move software from initial idea through creation and validation into the hands of customers and users, without impediments or rework loops. Reduced rework allows teams to focus on delivering more value. Shorter cycle times support increased responsiveness, in turn fostering customer and user satisfaction and trust.
- DevOps practices make DevOps habits actionable. Our DevOps practices are well documented and can easily be implemented by individual teams. Here are some of the practices that are related to improving flow of value.
- Our main goal is responsiveness. Being responsive relies on flexible scheduling, short iterations, and close team collaboration. This eliminates wasteful handoffs. Each team has the freedom to self-organize their work with full autonomy.
- We have multidisciplinary feature teams working from a common product backlog, delivering work ready to deploy at the end of each sprint. We don‘t tell our teams how to do their work or what rituals to embrace, all that counts are results.
- We treat our backlog as a set of hypotheses, which are turned into experiments, and for which we collect data. We also constantly engage with stakeholders and track their feedback. Based on data and feedback we plan our next move and persevere or pivot.
- We have implemented practices that help us collect information from different sources. All of this information helps us continuously keep our backlog in sync with business goals and re-align with sudden changes in the environment.
- Good experiments provide actionable data. We measure everything - health, availability, performance, and other quality of service metrics, but also usage - to collect evidence that proves or disproves each backlog hypothesis.
- We rely heavily on experimentation to fine-tune our products and services. At any point in time, we run hundreds of experiments in production. We then contrast usage data among cohorts, for example weekday and weekend users, to hypothesize ways of improving the experience for each.
- Technical debt are problems that negatively impact flow and progress. Technical debt lowers productivity, makes code fragile and causes bugs that create unplanned work. We aim to zero out our technical debt in each sprint to limit long-term negative impact.
- Keeping technical debt down starts with high-quality code. We have implemented practices to increase code quality at an individual developer level. After that, we rely heavily on test automation. Every team has a goal of reducing technical debt to zero in each iteration.
- Production lies at the heart of our software delivery organization. Production is every team member’s #1 job in every role, not just IT operations. We continuously track live site status, immediately remediate any live site issues, and proactively identify outliers in performance.
- We don‘t use pre-production environments, we deploy directly to production in each iteration. We have implemented DevOps practices that enable us to recover quickly, facilitate root cause analysis of issues and an architecture that fails gracefully with minimum impact.
- We use the flexible infrastructure of the public cloud and continually improve our architecture to refactor into independent, discrete services. Cloud infrastructure provides scale on demand and makes it easy to stand up services for continuous feedback from constant usage.
- Cloud infrastructure allows us to provision infinite resources on-demand, something that is impossible with traditional on-premises infrastrucuture. This has enabled us to implement many innovative DevOps practices wit minimal capital outlay.
- Software development has changed – old prerogatives and priorities have shifted and every software delivery organization must address these changes in order to survive. The question is not if it will hit you – the question is when. Are you ready for DevOps?