Microspeak: Spinning up or kicking off a build

Remember, Microspeak is not merely for jargon exclusive to Microsoft. It's jargon you can employ to sound more like an insider.

Most of the time, a fresh build of Windows is produced every day. When the product is nearing a release, train service gradually declines, with faraway branches losing service first. Eventually, the train stops running altogether, and the release branch remains stable for extended periods, not accepting any payload. This allows the test team to run their supersized test suites, the ones that take days to complete. (Known in the jargon as a Full Test Pass, or FTP. Sadly, this is easily confused with the File Transfer Protocol, also called FTP.)

Of course, the Full Test Pass may discover some problems, and if one of them is considered serious enough, a fix is applied to the release branch, and then a new build spins up.

The metaphor here is that the computers that produce the build have been sitting idle for so long that the imaginary turbines have stopped spinning. To build another release, the turbines need to get up to speed.

The Microspeak phrase spin up a build applies more generally to the concept of producing a one-time build from a branch that has not had a build in a long time. The branch may not have had a build because it has stopped accepting changes, like our release branch in the example above. Or it may not have had a build because it has intentionally been abandoned.

An example of the latter case is a special branch for experimental work that will never go into any official release. The build lab may be under instructions not to produce a build from this branch because the developers working in the branch can just rebuild the components they are experimenting with. Or because the branch is in a constant state of flux, so trying to produce a build will usually result in chaos. Or because the opportunity cost of producing a build out of this branch is denying a build to another branch due to limited hardware resources, and the people in the experimental branch are willing to take on some of the work themselves in order to free up resources for the other team.

If for some reason, the experimental branch would like the build lab to produce a build, they can ask the build lab to spin up a build for the experimental branch. (Presumably with a phrase like "when you get the chance" so that the build team can kick off the build at a time when demands for build machinery are low, like in the early afternoon.)

Kicking off a build is the jargon term for starting a build, presumably inspired by the kick-off which starts many sporting events.

Most regularly-scheduled builds occur overnight, and you might ask, "When does our build kick off?" This means "What time does the build lab start building our branch?" You would ask this if, for example, you want to know how much time you have left to get your fix signed off if you want the fix to go into tonight's build. If the build kicks off at 5pm, you might say, "There's no way I can get it done by then." But if it kicks off at 7pm, you might say, "Maybe I can convince my testers to drop what they're doing and test this fix, and then I can address the problems they find and get the fix signed off by 5pm. That leaves two hours for the change to make it through the gated check-in queue." (When a check-in successfully exits the gated check-in queue, it is said to have cleared the queue.)

Even if the build normally kicks off at 5pm, you can ask your branch manager, "Can you delay kicking off the build until 7pm? I have an important fix that we really would like to get into tonight's build, and there's no way it'll be ready by 5pm, but I think I can make it by 7pm." Of course, every hour you delay kicking off the build is an hour later the build becomes available in the morning, so the branch manager needs to balance the cost of delaying the release of the build with the benefit of picking up this fix.

That's a lot of build-related jargon for one day, but these are terms you need to know (because you will hear others use them), and if you dare, you can employ them yourself to sound more hip and with-it.

Comments (21)
  1. Joshua says:

    Well if you're willing to wait 20 hours MK insists a build can run on one workstation.

  2. Low-hanging fruit says:

    Yo dawg, I heard you like FTP. Well we made a comprehensive test suite for your file transfer protocol server so you can run your FTP through an FTP.

  3. Brian_EE says:

    @Joshua: "Just try that with an old piece of machinery."

    Or your own body…

  4. Andrei says:

    Given that you're talking about builds…

    Some eight or nine years ago, when I was fascinated by the history of Windows and researched much of it on the Internet, I was very frustrated that I couldn't find an exact definition for the terms "build" and "build number". Instead, everybody assumed they were already known and I had to guess their meaning from the context. Another thing that was missing from the Internet was the complete system of Windows build numbering, with all the idiosyncracies that have accumulated over time…

  5. sean says:

    I would argue that 'kicking off a build' is developer-speak, not microspeak.

  6. Gabe says:

    I assumed everybody "kicks off" a build. As for "spinning up", we use that for anything where there is some non-trivial initialization period. For example, we would "spin up a new VM" because there's some process involved in it.

  7. sean says:

    @Gabe – agree; likewise, 'fire up a new vm'

  8. Mark says:

    sean: "Remember, Microspeak is not merely for jargon exclusive to Microsoft"

  9. sean says:

    @Mark: geez – the very first line of the post. poor attention span?  i'll refrain from commenting…

  10. Myria says:

    How long does a build take to make?

  11. saveddijon says:

    In the chip design world we kick off regressions.

    Given today's design sizes, a regression may easily take up to a week, even on a multi-thousand node compute farm. Typically, it takes a day or two.

    Quite a bit of planning can go into determining which build version gets into the regression given those sizes.

  12. John Muller says:

    Spinning up a long idle build process does have risks. Things like digital certificates and domain account passwords expire; system updates may have been automatically installed that break the build, etc.

  13. cheong00 says:

    [The wonderful thing about "VM" is that they can usually go from sitting idly for months or years to working in mere moments with no maintenance required. Just try that with an old piece of machinery.]


    We had computer that sit in the warehouse office without anyone using it for 2 months, and then when flipped on again, it greeted us with white smoke.

    Apparently they're not so stable if sitting idle in dusty region for a long time.

  14. cheong00 says:

    Now I think again and thought VM doesn't make it either.

    In my last company, we have a client site that involves hardware SSO with IBM Websphere MQ.

    Even we resisted the pain to reduce the test suite to 2 VMs, every time we need to start it again from shutdown state to "functional" one would take experienced staff 2 days to reconfigure them. (The tricky part in this setup is that some of the components have circular library dependency hell on loading order, so the startup step involves loading a lower version one first to satisfy one component, then overwrite it with another version and start another component, then overwrite it back or the system will go defunct when the deamon forks. Unfortunately bash script is not possible because some component requires user input when it starts and they don't accept inputs from pipes)

    That's what I'd call "enterprisey".

  15. Neil says:

    @Joshua 20 hours? If it can be available in the morning even though it starts at 7pm then it can't be more than 16 hours. (I wonder whether this is for a full rebuild or just an incremental build.)

  16. Clipboarder Gadget says:

    So everytime you want to test some code your have to wait until the next day? Or is this just for the testers?

    I always assumed you just recompiled the dll you are working on and replace it live on the OS you are developing on.

    [This is not about testing your fix locally. This is about committing fixes to the tree so that when somebody asks, "Is this bug fixed in today's build?" you can say "Yes." -Raymond]
  17. Brian_EE says:

    @Neil: I think the difference is building on a single workstation vs a multi-node compute farm

    @Clipboarder: Individual developers probably do test their own changes locally… but at some point that code has to be pushed up the source tree towards the trunk. And you want a fully-clean build and install to regression test your changes and it's coexistence with everyone else's changes in the branch.

  18. Bob says:

    @savedijon:  I'm also in microprocessor design.  While it would take a while to run a full regression suite, that isn't quite what is being referred to.  This is more like the smoke test that is run (for us at least) on each build before it would go into any further regression.  

  19. Scott Brickey says:

    Just curious, what is the process (there at MS) for the gated checkins?

    Most cases I've seen simply require unit tests to pass. I do know that you have several review processes in place (code quality, security, etc), but I hadn't heard anything about that process being embedded within the TFS (gated) checkins.

    I welcome your thoughts :)



  20. 640k says:

    TFS, and its gated checkins, are too enterprisey to use if you want anyone to be productive.

Comments are closed.

Skip to main content