DevOps at Microsoft

Author: Sam Guckenheimer

Last Update: 8/8/2017

Moving Microsoft to Visual Studio Team Services under One Engineering System (1ES)

Microsoft is a very large software company. As of March 2017, we have more than 68,000 engineers active on Visual Studio Team Services. For a great discussion of how the transformation has affected multiple divisions, we held an open-mic Q&A at Build 2017 with engineering leaders from across the company.

In addition to this panel, you can read a great experience report on how the Universal Store Team adopted Continuous Delivery over the course of 12 months. One stunning example is an 8000x improvement in build frewuency!

How We Work with Visual Studio Team Services (VSTS)

One of our principles is to learn from our own usage. We try practices and tools to see what works, and then we productize. Of course, we open source a lot too. This video from DevOps Enterprise Summit 2017 describes our move to One Engineering System at Microsoft and demonstrates how we work.

This video describes our move to One Engineering System at Microsoft and demonstrates how we work.

For more detail, take a look at How we transitioned to DevOps in Microsoft’s Developer Division

Architecture for the Cloud

Controlling exposure through feature flags in VS Team Services is covered in this great blog post. (https://blogs.msdn.microsoft.com/buckh/2016/09/30/controlling-exposure-through-feature-flags-in-vs-team-services/)

This video is a complementary discussion of features flags, circuit breakers and other architectural patterns that we have applied to scale.

Software Test Improvement

Software testing at scale to increase velocity

Test while building to maximize test effectiveness and minimize cost

Is 100% Code Coverage Worth the Cost?

Getting the Noise Out of Test Runs

Improving software security with stack traces from bug reports

Researching software practices

We like to be informed by data. Measuring how well practices work is key. We’re sharing our research and learning, so that you can be informed too.

Code reviews are not (primarily) for finding bugs

Using a simple code churn metric to find software bugs

Code ownership and software quality

Boosting your code reviews with useful comments