MSBuild Team Blog : Agile Development

Sprint 12 review

msbuild — Thu, 02 Feb 2006 01:31:00 GMT

This morning we had our review of work done during Sprint 12. As you hopefully recall we run two sprints simultaneously: one focused on our conversion effort and one focused on platform investments.

Sumedh got stuck in traffic on 520, so Faisal stepped in to drive the proceedings. Faisal handled it well, applause applause. And now, on to the review details...

Converting Visual Studio Builds (conversion): We converted three more trees, with one more currently under code review (we can't call the one under code review done because for us "done" means checked-in). At this point every team in Visual Studio is either done or in the process of converting except one.

Tool for Infering Project-to-Project References (conversion): As part of our conversion effort we want to ensure that all dependencies between trees are explicitly stated through project-to-project (P2P) references. Dan worked on a tool that will go and automatically add P2P references to converted projects. He gave a demo during the review, and it was super sweet!

Multi-Proc Development Work (platform): Vlad and Sumedh spent most of the sprint working on implementing the beginnings of multi-processor support in the engine. They did a demo of what they have working so far, and it's so cool to see the beginnings showing up. We're a long way from having something that's useful outside of concocted projects, but progress is being made. Here's a picture of what the demo looked like:

Fixing Bugs: This wasn't part of either sprint, but was something we had to do as part of a larger effort by Visual Studio. We need to keep our bugs at or near zero, and since we've been receiving new bugs through the MSDN Product Feedback Center we had some work to do.

[ Author: Neil Enns ]

Platform Sprint 11

msbuild — Thu, 05 Jan 2006 22:29:00 GMT

The new year got off to a good start for us with the MSBuild Platform Sprint 11 Backlog selection meeting. Platform Sprint 10 was focused mostly on getting our Compatibility story in place. All of the work from the last sprint in terms of compatibility has been checked in and is now in use.

This means that we can finally get to the good stuff in Platform Sprint 11. Our sprint goal for this sprint is to deliver a working version of multi-proc build capability. Needless to say, everyone on the sprint is excited about this and we are looking forward to the end of the month to see where we stand. I believe that we will have good parts of the multi-proc functionality working at the end of the sprint, and here's why:

Over the past sprints, we have been thinking a lot about the design of the system - like we discussed here and here. It is time now to start thinking in terms of real implementation milestones - and to that end we decided to think strictly in terms of "User Stories". So, everything that has to do with multi-proc that went on our backlog were real stories that would make sense to you from a customer standpoint, as opposed to items that are more closely aligned with the design or the implementation of the system. For instance, the simplest user story in our case was "Build two simple, independent projects in parallel, with no logging support, no disk-bound tasks". You can think of the simple projects as those that have a single target, and a single Message task. That really is our first customer story for multi-proc. We build successively on individual stories till we eventually get to a fully featured multi-proc build functionality.

Of course there are a lot of other activities going on in this sprint as well. We are working on handful of bugs that we could not get to during the tail end of Whidbey. We are also investing in QA work so that we are able to deliver at an even higher level of quality during Orcas.

I couldn't have asked for a better start with the new year. I am highly optimistic of everything that is to come in the following months. In the meantime, I encourage you to log any issues you run into with MSBuild via the MSDN Product Feedback Center so that we can consider them as bug fixes during the current Platform Sprint 11, or the subsequent one.

[ Author: Faisal Mohamood ]

A Note on Pair Programming

msbuild — Wed, 04 Jan 2006 19:49:00 GMT

Hi All -

My colleague Neil Enns wanted me to drop a note about the fact that we've been experimenting with pair programming on the MSBuild team on certain tasks, and found it generally useful. I finally tried it out last week, pairing with Sumedh on a relatively mundane task and blogged about it here. Definitely a worthwhile practice for many kinds of tasks.

[Author: Chris Flaat]

Sprint 10 Review

msbuild — Fri, 09 Dec 2005 20:55:00 GMT

Today we're holding our Sprint 10 review. If you recall we do sprints for both dogfooding support and platform work. Here's a recap of what we accomplished in the last month.

Dogfooding

Six more teams within Visual Studio completed converting to MSBuild
We completed our first integration of all the converted branches into the parent branch of our build process. If this sounds messy, that's because it is *grin*.
Prefix support is checked in!
Our dogfood builds now support IDL to TLB to meta assembly generation
Proper support for build phases natively with MSBuild .targets files (this was all done with pair programming)
Cleaned up build traversal and clean logic
Documentation for Managed C++ builds
Unit tests are now in place for dogfood .targets files

Platform

All compatibility tests are written! This includes targets, shipped tasks and loggers, source code/APIs, command-line build, and solution builds. Since this is all we set out to do for platform in this sprint, I'd say we did pretty well.
We started to engage with other teams such as FxCop, VB, and TeamBuild so we can understand our compatibility testing requirements there.

Sprint 11 will start in January when everyone is back from vacation.

[ Author: Neil Enns ]

Sprint 10 Backlog Items

msbuild — Mon, 28 Nov 2005 23:39:00 GMT

My bad for not getting this up sooner. We've actually been going on Sprint 10 for the last two weeks. As with Sprint 9 we've split it into one sprint for platform work and one for dogfood work.

We've made a shift in our platform work for Sprint 10. During this sprint we are solely focused on building automated compatibility tests to ensure backwards compatibility with what we shipped in .NET 2.0. This includes reviewing existing tests, writing a test spec, reviewing and finalizing the spec, and writing new tests for a host of different areas. Some of the specific areas we're focusing on are: target file compatibility; shipped tasks and loggers; command-line processing; solution files; and logger output.

On the dogfood side of things we are finishing up work on integrating prefast into our internal targets files; adding a framework and tests to unit test our internal .targets files; cleanup of the internal targets for building native source; and better support for build phases and interactions with build.exe.

[ Author: Neil Enns ]

Sprint 9 Review

msbuild — Fri, 11 Nov 2005 22:43:00 GMT

It’s been about a month since we last talked about Sprint 9, and it’s time for an update. If you recall, the MSBuild team was planning on two parallel sprints: one for platform investigations and one to support internal dogfooding efforts. Last Friday marked the end of the sprints, and on Monday we held our sprint review. Here’s a recap of what we accomplished.

Dogfooding Sprint

Managed C++ Targets: We completed the authoring of .targets files for building Managed C++ code that makes up Visual Studio, including support for managed resources and asmmeta generation.

Conversion Support: A large part of the sprint was supporting a very active internal conversion alias. With so many teams making forward progress on converting their builds to use MSBuild we wound up answering a lot of questions. We now have approximately 40% of Visual Studio building with MSBuild.

Platform Sprint

Multi-proc scenarios: We agreed on our key scenarios for enabling multi-processor support.

Core design docs: Design documents were written and reviewed for many of the core pieces of our multi-processor support.

Dogfooding roadmap: Since dogfooding MSBuild technology is critical to what we do, we’ve already prepared a plan for how we’ll roll out multi-processor support to our build lab once it’s usable.

Partner engagement: We met with a wide range of teams to discuss our multi-processor work, including teams that want the functionality as well as teams that have technologies that could help us in our implementation. As part of this engagement we also posted to our blog about some of our Visual Studio integration concerns.

Compatibility tests: We successfully reviewed and signed off on our compatibility test plan, and wrote compatibility tests for project, binary, and add-in compatibility verification. We also moved numerous test suites from our old test system to live directly in our developer code branches. This makes our tests vastly more portable between machines, and simplifies running them in conjunction with unit tests.

That’s a quick wrap-up of what happened in the last month. Our next sprints will also run in parallel, and planning starts today. The sprints start next Monday, the 14th, and we’ll post the backlog as soon as we have it.

[ Author: Neil Enns ]

Sprint 9 Backlog: Platform Sprint

msbuild — Tue, 04 Oct 2005 23:57:00 GMT

Here are the tasks we selected for the platform sprint. For those who aren't familiar, our platform work is about laying the foundation to enable multi-proc support.

Overall roadmap for multi-proc build (critical)

By roadmap we mean an outline of when we’ll have each of the sub pieces of multi-proc support implemented.

Authoring and team review/signoff of multi-proc design docs (critical)

No real additional description is necessary here, it’s two of our developers doing hard-core work on getting a proper design in place for multi-proc support. Note the addition of team review/signoff to the item: it’s not enough to have the document, we want it done and agreed to so we can start implementation in our next sprint.

Prototype of multi-proc builds (target)

Ideally we’d have some sort of a prototype of multi-proc builds done to illustrate key concepts. This would be similar to the type of prototype work that Vlad did for distributed builds in our previous sprint.

Team review/signoff of compatibility test plan (critical)

As a follow-up to work done in the previous sprint, we need to sign off on the complete test plan for MSBuild compatibility testing. As a team we are doing no new development work on MSBuild until we are convinced we have full compatibility testing in place. We’ll be posting more about what this means in the near future.

Fully automated testing of compatibility requirements that block multi-proc development (critical)

This goes along with the previous item. We need to have the tests implemented and running on developer machines for compatibility requirements that prevent us from doing development on multi-proc.

Fully automated testing of compatibility requirements blocking other development (target)

We obviously need full compatibility testing, but we’ve broken out the testing that doesn’t block multi-proc development.

[ Author: Neil Enns ]

Sprint 9 Backlog: Dogfooding Sprint

msbuild — Tue, 04 Oct 2005 23:56:00 GMT

Here are the tasks we selected for the Dogfooding sprint. For those who aren't familiar, our dogfooding work is all about converting all of Visual Studio's source code to build with MSBuild.

Provide .targets files for building Managed C++ targets (critical)

There’s a bunch of code in Visual Studio written using Managed C++, and right now we have no way to build it with MSBuild. This item is to write .targets files that can build Managed C++, and will complete our ability to build native, managed, and managed C++ projects within our build tree.

Convert representative samples for two Managed C++ trees (critical)

Our general approach to conversion is to do the first stab at converting a piece of a tree, and then give those to the teams that really own the source so they can use them as samples for the rest of the conversion. We’ll convert two pieces of Managed C++ trees in this sprint.

Ongoing conversion outreach (critical)

This covers things like brownbags for teams and support on internal aliases.

Fix bugs in our .targets files (critical)

As more people convert to MSBuild within Visual Studio, we inevitably find bugs in the internal .targets files we use. We’ve added time to the sprint to fix those issues.

Deploy updated tools and tasks into a division-wide directory (target)

We have several internal tools and tasks that we use as part of the conversion effort, and we need to get them checked into a division-wide directory so everyone can use them.

QA review of test coverage on auto-generated tasks (target)

We have an internal tool (that we’ll be publishing to the web shortly) that enables auto-generation of tasks that wrap command-line executables. We need to do a QA review of our coverage on this, so we can be sure that it works as expected.

Integrate prefast into our .targets (critical)

We use a tool called prefast quite heavily as part of our internal development process. Right now it doesn’t integrate with our internal .targets files for our build process. This does the necessary work to enable it to run as part of our build process through MSBuild.

[ Author: Neil Enns ]

Sprint 9 Backlog Selection Overview

msbuild — Tue, 04 Oct 2005 23:55:00 GMT

Today we held our second backlog selection meeting for Sprint 9. We’re running Sprint 9 as two separate sprints, one for internal conversion efforts and a second to lay the groundwork for multi-proc build* support. Since my original blog entry was getting rather long in the tooth I’m splitting it up into three parts. The next two blog entries will cover the backlog items selected for each sprint.

When looking at the two backlog lists, you’ll see some are marked as “critical” and others are marked as “target”. When we schedule our sprints we try and fill roughly 60% of our available resources with critical work items, and the remaining 40% goes to other work items that we’d like to see complete. This gives us some items that we can safely cut if the critical items go longer than we expected.

* When we say multi-proc build we really mean multiple threads, multiple CPUs, multiple cores, and multiple hamsters. It also has an impact on our longer-term plans for multi-machine (a.k.a. distributed) builds.

[ Author: Neil Enns ]

Sprint 8 Review

msbuild — Tue, 27 Sep 2005 21:55:00 GMT

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 ]