Skip main navigation

New lower prices! Get up to 50% off 1000s of courses. 

Explore courses

Case Study: Microsoft Developer Division Moves to DevOps

.

In the previous step, you discovered how you can be a change agent and advocate for implementing DevOps in your organisation. In this step, we will look at and learn from the Microsoft Developer Division’s DevOps implementation.

Over seven years, the Microsoft Developer Division (DevDiv) embraced Agile practices. The division achieved a 15-times reduction in technical debt through solid engineering practices, drawn heavily from XP. They trained everyone on Scrum, multidisciplinary teams, and product ownership across the division. They significantly focused on the flow of value to customers. By the time they shipped Visual Studio 2010, the product line achieved a level of customer recognition that was unparalleled.

After they shipped Microsoft Visual Studio 2010, the team knew that they needed to begin converting Team Foundation Server into a software as a service (SaaS) offering. The SaaS version, now called Visual Studio Online (VSO), would be hosted on Microsoft Azure, and to succeed with that they needed to adopt DevOps practices.

That meant that the division needed to expand their practices from Agile to DevOps. A tacit assumption of Agile was that the Product Owner was omniscient and could groom the backlog correctly. In contrast, when you run a high-reliability service, you can observe how customers are actually using its capabilities in near real-time. You can release frequently, experiment with improvements, measure, and ask customers how they perceive the changes. The data that you collect becomes the basis for the next set of improvements you do.

In this way, a DevOps product backlog is really a set of hypotheses that become experiments in the running software and allow a cycle of continuous feedback. DevOps grew from Agile based on four trends:

A larger loop demonstrating the DevOps lifecycle, with Development having its own internal sub-loop, and production on the other side of the loop with its own internal loop. An arrow labelled with collaboration is placed between these two sub-loops to connect them. In order, the outer loop has text explaining different advantages. Pointing at the Development loop is an arrow with text reading, “the agile methodologies are accelerating the construction process”. Next in the loop are some servers and cogs, with explanatory text stating, “an automated release pipeline is needed to deliver at the pace of development with full traceability”. Moving on to the Production sub-loop, the text states that “Availability and performance issues are hard to troubleshoot in this fast-changing world with distributed applications”. Continuing on with the greater loop, the last text states that “Usage should determine the next set of priorities and learn”; this final statement feeds to an image labelled ‘Backlog’ before the loop returns to the Development section

Unlike many ‘born–in–the–cloud’ companies, Microsoft did not start with a SaaS offering. Most of the customers were using the on-premises version of their software (Team Foundation Server). When VSO was started, the division determined that they would maintain a single code base for both the SaaS and ‘box’ versions of the product, developing cloud-first.

When an engineer pushes code, it triggers a continuous integration pipeline. At the end of every three-week sprint, they release to the cloud, and after four to five sprints, they release a quarterly update for the on-premises product, as illustrated below:

In the upper arm are cycles labelled, consecutively, “Update 1”, “Update 2”, and “Update n”. In the lower arm, which is labeled “VSO Service Updates”, there are five loops which overlap and cover the same amount of time as the three updates mentioned earlier. In between the two arms is a loop labelled “vNext”.

To learn more about specific aspects of this journey, from source control to live-site culture, and from branching to open source, to alignment, see Our Journey to Cloud Cadence: Lessons Learned at Microsoft Developer Division, a free e-book by Sam Guckenheimer.

In our next step, we will complete our first CloudSwyft Hands-On Learning Lab for Week 1.

Join the discussion

What most appeals to you about the idea of implementing DevOps? Do you have any real-world challenges that it could solve or improve?
Use the discussion section below and let us know your thoughts. Try to respond to at least one other post and once you’re happy with your contribution, click the Mark as complete button to check the step off, then you can move to the next step.
This article is from the free online

Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline

Created by
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now