Yesterday was our Dogfooding Sprint 8 review. For those that aren’t familiar, we use the SCRUM agile development methodology to run our efforts around dogfooding. Even though the work we do in our dogfooding sprints is heavily focused on internal adoption of MSBuild we’ve decided to share what goes on so you can learn more about the inner workings of our team.

 

The review meeting is where everyone gets together to look at demos of what was accomplished in the last sprint (our sprints are 30 days long). Here’s what we accomplished:

 

Completed converting an additional 3 trees of Visual Studio source to use MSBuild

 

This is part of our ongoing work to get 100% of Visual Studio building with MSBuild. These three trees represent roughly 13% of what needs to get converted.

 

Started conversion of 5 trees of Visual Studio source to use MSBuild

 

This is part of our ongoing work to get 100% of Visual Studio building with MSBuild. These five trees represent roughly 12% of what needs to get converted.

 

Created a conversion branch as part of our ongoing conversion effort

 

It’d take an entire blog to explain the build lab structure of Visual Studio, but in a nutshell we created a branch off our source control system. This branch enables teams within Visual Studio to convert their source trees to building with MSBuild in a contained environment

 

Updated the version of MSBuild in our tree 

 

First up was ensuring the conversion branch used the shipping verison of MSBuild. Then we checked in updates to our internal .targets files and tasks that we use for customizing the build process. These changes have been around for the last while on our dev boxes, but it's an entirely different beast to have these changes rolled out to the entire process that builds Visual Studio! We also turned on a utility we have to reduce the overhead of loading multiple instances of MSBuild during a complex build.

 

Merged QA and Dev tests

 

Historically we've used different tools to run tests created by our QA team and dev teams. As you can imagine this causes all sorts of problems. In this sprint we made huge strides in getting everything running under the same framework. This will allow devs to easily run QA tests, and vice versa.

 

Check-in validation tools running on the conversion branch

 

Just having a branch to check changes into isn’t enough. As part of the regular development processes within Visual Studio we have a host of tools that validate the check-in, run acceptance tests, etc. We got those running on our special conversion branch.

 

UI for a conversion validation tool

 

We have a tool that helps us validate that a converted tree is generating the same build commands before and after MSBuild conversion. It used to spit out log files that we read using Notepad. Reading them was unpleasant. Now the tool has a pretty UI interface, and even highlights things in red and yellow so Kieran is happy. We also made extensive use of paired development practices for this work item.

 

Brown bags

 

We prepared two brownbags and gave one of them for the Visual Studio team. These are geared towards teams in Visual Studio that are working on converting their source trees to build with MSBuild.

 

Distributed technology prototyping

 

Vlad has been investigating the myriad of technologies that are available to move work items between machines. This is long-lead work to help us understand what it will take to distribute builds. He showed off a prototype that distributed some portions of a build across machines, and helped us to understand the crazy complexities that lie ahead.

 

Parallel build design investigations

 

Sumedh has been investigating the different design possibilities for introducing parallelization into the MSBuild engine. This is necessary for both multi-processor and distributed build support. He pulled together a design doc with his ideas, which we will be sharing in the near future on this blog.

 

Process changes to streamline our sprints

 

We’re still debating whether the process changes actually made the sprints more productive. Hopefully Chris will be posting more about our sprint process to the blog.

 

Phew, that about does it. Hopefully you’re suitably entertained. Our backlog selection meetings for Sprint 9 are next week. We’ll keep everyone posted on how those go.

 

[ Author: Neil Enns ]