re: MSBuild Team Posts Status Publicly

AKipman — Sat, 19 Jun 2004 17:25:00 GMT

Yesterday Josh blogged about the MSBuild status which I posted earlier this week. His blog entry generated an interesting conversation which I felt I should comment on (hence this blog entry). The basic pushback was:

Status of internal projects may represent competitive information, may have legal consequences to contracts, expose security bugs before the fixes are deployed, and may represent excessive transparency. I work on something inside MSFT that would sink existing product lines. Should i post our build status information? <absolutely not>
Next they'll want us to start publishing checkin mail?

Interestingly enough I have heard this pushback three distinct times this week, and with exception of the above none were related to my little blog. The first time was when I read next week's business week article titled “Blogging with the Boss’s Blessing” which dives straight into this issue. I read the article because it features Sara Ford (who works a few doors down from me), and because we are all very proud of her :). The second time was in an unrelated meeting I was having with Lutz, Rob and company. There we were basically discussing how it only takes one irresponsible employee one blog entry to undo years of messaging and position from marketing.

All three conversations boil down to the same question: “when is transparency detrimental to a company”!

In my utopical world, I think the answer is very simply *NEVER*; as long as people use their common sense. People *should not* blog about things that they don't own. For example, I shouldn't sit here blogging about the cool demo I got of XYZ yesterday, even though it was the coolest thing I've ever seen, since I don't know how much of XYZ is public yet, I mean I have an idea and I think it is public... but I just don't know for sure. People *should not* just copy and paste internal things into the blog. For example, I shouldn't just copy and paste my status as is externally (and btw I haven't). Ultimately as Scoble says:

Before posting an entry in his personal weblog, Robert Scoble always pauses and considers how he would justify its contents to three people: his boss, his wife and Steve Ballmer.

Again just use common sense folks, and blogging is a win win win proposition. I won't be blogging about the status of converting the Windows Kernel to an MSBuild task. I won't be blogging about the status of adding the hyperspace feature to the MSBuild engine. I won't be blogging about things that don't make sense to be blogged about.

Lastly *I think we should be posting check-in mails* and I will be doing so in the future. I already do so internally every time we post an LKG (last known good) to our internal partners, and I will be posting the same list externally when we ship the beta of Whidbey. I think this is the single most valuable information a developer can have when he/she are trying to figure out what the delta is since the last technology preview, alpha etc. What has changed? What are the breaking changes? What are the new features I should be pounding on? I strongly recommend this to any feature team, as this is one piece of information our customers have to *discover* by trial and error, and this would give them a clear roadmap of a) what to look forward to, b) what to play with first and c) prepare them for what will break since the last time we did this.

And now I'm late for going to work (Ori is going to kill me)... since I woke up to just read a bit and ended up blogging (damn this thing is addictive). Cheers everyone... and happy blogging

001 - MSBuild status

AKipman — Tue, 15 Jun 2004 05:17:00 GMT

Status... status and more status. This is something new I'm trying, and I'd love to hear your feedback on the process. As most people at Microsoft (heck probably anywhere), I have to send weekly status internally to my peers, the big cahunas and other interested parties. My status covers MSBuild, and pretty much reports a pulse for the entire feature area. What's Dev up to... what's QA up to... is the PM *still* slacking off (<-- don't answer that). So if internal folks are generally interested in it... perhaps *you* are interested in it as well.

So the question for you is: Well are ya interested in it?

I will attempt to post these on a regular basis, and through it, you can know what's up in MSBuild land. Again we'll tweak the frequency and granularity of these as we go. The more feedback you give... the better I'll be able to optimize this experience for you... Onto status then:

Internal Stuff

MSBuild has finalized plans to speak at the Microsoft Global Briefing (MGB) this year:
- MSBuild will host 1 out of the 4 Instructor Led Hands on labs at MGB this year
- MSBuild will host 1 breakout session at MGB this year
MSBuild checked in a few high profile fixes into Longhorn which were blocking the Avalon team
<Insert XBox studio name here> is now building XBox, XBox 2 and Windows games from a single MSBuild project file. In their own words “I'm hoping the XBox Advanced Technology Group will get interested in MSBuild and offer tasks in addition to the VS integration they offer now“
New MSBuild last known good (LKG) was cut and released to our internal dogfooders
Internal wiki FAQ site has been created to better support our internal dogfooders.
Internal wiki site has been created to better track Longhorn / MSBuild long term issues

External Stuff

Jeff (JeffCal@microsoft.com) has started blogging about MSBuild. His blog is located at http://blogs.msdn.com/jeffcal
Alex (AKipman@microsoft.com) has started blogging about MSBuild. His blog is located at (ahem... you are on it :) )
Christophe Nazarre's “Overview of MSBuild, Part 2: From the Task Author's Perspective“ was posted to MSDN
MSBuild made the front page of http://msdn.microsoft.com/longhorn with Christophe Nazarre's second article
MSBuild had a good presence at TechEd in San Diego. Final trip report can be found here
Stefan Bodewig had another great blog entry. Full blog entry can be found here
We spoke with <insert large ISV name here> about integrating MSBuild in their overall build lifecycle. In the words of the person who organized the meeting “You guys blew <insert ISV name here> away, and they are very excited about the capabilities of MSBuild“
MSBuild made an appearance at the VSIP dev lab and we gave them a quick overview of MSBuild. 4 distinct customer who shall remain nameless have engaged with us after the DevLab and we are currently talking with them about using MSBuild in their environments

Beta 1 Progress

MSBuild docs were reviewed and are ready for Beta 1

596 out of 596 MSBuild nighlies¹ are passing at 100%.
70 out of 70 MSBuild OGFs² have been issued as “Meets Expectations“ for beta 1
10 out of 10 MSBuild handshakes³ have been issued as “Meets Expectations“ for beta 1

Beta 2 Progress

The following Beta 2 design change requests (DCRs) have gone through VSCore management approval and are now on our list:
- Improve whitespace preservation in MSBuild project files
- Allow OutputPath / OutDir / IntermediaryOutputPath properties to support both full-path as well as relative or UNC paths
- Fully support project to project (P2P) references that have manifests associated with them. This is required for RegFree COM support in ClickOnce applications
- Expose functionality that allows Visual Studio flavored⁴ projects to execute any arbitrary target within MSBuild
Our new intern, Jeff Vaughan (t-jeffv@microsoft.com), started working on MSBuild. He'll be with us until the end of August. WELCOME Jeff!

Performance

MSBuild perf scenarios are ready to run as Pri1 performance tests in the pef lab. Our current P1 scenarios consist of:
- Small - Individual / Small feature team (eg MSBuild itself with ~10 leaf node projects)
- Medium - Entire feature team (eg Visual Studio solution and project systems ~50 leaf node projects)
- Large - Entire product unit (eg Visual Basic ~500 leaf nodes)
- X-Large - Entire division at Microsoft (eg All of Visual Studio ~4500 leaf nodes)
Work has started to integrate MSTV Server (~75 leaf projects) as one of our performance scenarios. Based on this work we've been able to:
- Isolate performance issues around our Resolve Assembly Reference (RAR) task.
- Improved overall load time by 10% (5 seconds).
Recent perf numbers on MSBuild compared to Build.exe / nmake:
- Build.exe / nmake⁵ building the MSBuild tree (1 CPU) - 55.25 seconds
- MSBuild.exe building the MSBuild tree (1 CPU) - 36.60 seconds!!
MSBuild peak size reduced from 55 megs to 15 megs. Total allocations (ie GC pressure) went from 280 megs to 170 megs. This ginormous improvement is mostly due to:
- MSBuild now cache's imported project xml to prevent re-parsing
- MSBuild now uses case insensitive hash keys to prevent storing upper case copy of all MSBuild property and item keys

So that concludes the status... you are now UP TO DATE <-- in msbuild speak that means you will be skipped next time we build you :) (ok dorky joke but I couldn't resist)

Useful? More of it? Less of it? Inquiring minds want to know :)

¹Nightlies - we have ~2100 distinct automated tests for MSBuild. Some more important than others. Nightlies are some of the most fundamental tests we run. As their name implies we run these on a daily (ahem nightly) basis and they are meant to test critical customer scenarios. Breaking or regressing a nightly is really bad. Nightlies are a great indicator of our overall product stability.
²OGFs - Overall Good Feeling or Overall Goodness Factor (I can never remember). A few times per milestone our awesome QA organization tests end-to-end scenarios (both manually as well as automated). Based on the end-to-end experience they issue an OGF for the scenario. The collection of these OGFs isused as an indicator of our overall product quality. Example of an OGF for MSBuild would be “Logger Initialization and Shutdown“
³Handshakes - A collection of cohesive OGFs bubbles up into a Handshake. If all OGFs within a handshake pass then a passing handshake is issued. If at least one OGF does not meet expectations the entire Handshake fails. An example of an MSBuild handshake would be “MSBuild Logging Handshake“ which would contain all MSBuild OGFs.
⁴Flavored Project - these are project that build ontop of our core VB/C#/J# project systems and tend to optimize for a given technology. Examples of these “flavored“ projects are the Smart Devices, VSTO or Yukon projects.
⁵Note - This is build.exe as we run it internally within our build labs. Number may vary if you hand author your makefiles from scratch.

_*_*_*_ Update: Swapped the 4th and 5th footnotes. Thanks goes to David Cumps for pointing that out. _*_*_*_

AKipman's MSBuild blog : MSBuild Status

re: MSBuild Team Posts Status Publicly

001 - MSBuild status