DevOps at Scale: A True Story

Download this episode

Download Video

Download captions

Description

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.
For more information, check out this course on Microsoft Virtual Academy:

Day:

2

Session Type:

Breakout

Code:

B846

Room:

Marriott Salon 7

Embed

Format

Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • User profile image
      samsmithnz

      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
      briankel

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

    • User profile image
      PhilBolduc

      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
      briankel

      @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
      dwatts6

      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!

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.