DevOps at Scale: A True Story

Play DevOps at Scale: A True Story
Sign in to queue


DevOps represents a transformational shift in the way the software industry produces and delivers software. While the benefits are many, the road to DevOps for an established organization can be a long one filled with surprises and challenges. Microsoft’s Developer Division, responsible for producing software projects such as Team Foundation Server and Visual Studio Team Services, has been on a multi-year journey to become more agile and accelerate from shipping once every two years to shipping multiple times per year in a true DevOps fashion. This session will provide insights into the changes and investments made along the way, demonstrations of how the team makes use of Visual Studio Team Services to manage their software development projects, and practical lessons you can apply to your own team’s journey.



Session Type:





Marriott Salon 7



Right click to download this episode

Download captions

The Discussion

  • User profile image

    This was, in my opinion, the best session of the conference for me. Definitely worth watching if you want to get a better insight into how Microsoft manages their internal devops process around VSTS.

  • User profile image

    @samsmithnz:Thank you for the very kind words! We're glad you enjoyed it.

  • User profile image

    I am interested in know more about how users are creating their own user branches.  For example at 33:11, you say "he created a branch under his user name space.".  It seems this is just a convention where users create branches using users/username/description   I would assume it is up to the user to clean up his own branches after his pull requests are merged?  What about security? It doesn't appear to be an easy way to secure those branches. Or do you handle that more on a policy such as never change anything in someone else's repo without permission.  

  • User profile image

    @PhilBolduc: Good question Phil! This is primarily just a naming convention as you described. We recently added a feature in VSTS whereby you can check a box to delete the topic branch when you complete a PR. (When you click "Complete Pull Request" you'll see it on the next dialog)

    While the option to secure a branch/repo exists in VSTS/TFS, we don't typically lock things down. Topic branches are wide open, and there are valid reasons where you might be collaborating with somebody on a change that you might need to go edit their topic branch contents. I can't think of a time when somebody accidentally or maliciously changed somebody else's topic branch contents, but since all these changes are ultimately logged in VSTS/TFS there isn't much of a concern here.

    Where we DO enforce security (by way of branch policies) is in the master branch. Note that we don't apply ACL's to the master branch, but instead we rely on the branch policies screen (which I showed in the demo) to define the quality gates whereby changes need to flow into main. This implicitly guarantees security because there are specific reviewers who have to approve changes into main.

    Hope that helps!


  • User profile image

    I agree, this was in fact one of the best sessions in the conference for both techies and business people alike. I thought Brian and Lori were telling the story of my company, except they know the ending already.

    We've been on this journey for awhile now and we are slowly drawing all the same conclusions that MS has but we're not building tools that solve the problems, we just want to build our software. Hats off to the MS team who not only had to deal with this evolution but also had to build and use the ALM software that provides the scaled devops experience organizations really need to be effective. Well done!

  • User profile image

    I wish there was more actual technical substance. This presenter is absent of any deep technical useful skills, barring used car sales.

  • User profile image
    Efrain Flores

    Is it possible to create build definitions that have sources in two different team projects in VSTS?

Add Your 2 Cents