A colleague once told me configuration management is to software development what oxygen is to a human. When the proper CM practices are in place, no one notices. When configuration management is non-existent or lacking, the development process chokes. The trick, as always, is to find the right level of process and auditing for the development task at hand.
Adam Barr gives us a look at what happens on the extreme end of the spectrum with the release of new Monad bits. Not only is Microsoft big (debug and release builds have to run a gauntlet of tests on 3 platforms x 3 architectures), but they are also understandably paranoid (you need three employees with cardkeys and PIN numbers to have an independent team sign bits with the Microsoft private key). Read the rest of the process in Adam’s post “Putting Out A New Release of Monad”.
One of the tools in the process that caught my eye was APIScan. APIScan ensures a product uses only publicly documented Windows APIs. This sounds crazy unless you remember the hidden API fiasco during the bubble years. The hidden APIs became a part of the anti-trust case, which added legal complexities to Microsoft’s CM process. A quick search finds this report on the website of the U.S. Department Of Justice. The report is an update on Microsoft’s compliance in the U.S. v Microsoft case, and mentions APIScan as a tool “to identify all APIs that must be disclosed in accordance with Section III.D”.
Aside: the report also documents that the Platform and Services division at MS offers quarterly ‘anti-trust’ training. Wow – that’s a triple shot espresso mocha session, if ever I heard one.
Next time I have to tweak a script for the build engine, I’ll remember things aren’t all that bad.